Personalizaciones de Salesforce Sin Código: Guía Práctica para Principiantes

¿Sabes qué me fascina de Salesforce? Lo mucho que puedes construir sin escribir una sola línea de código. Automatizaciones, validaciones, interfaces personalizadas — todo con clics. ¿Alguna vez te detuviste a pensar en el poder que eso pone en tus manos?

Esta filosofía tiene hasta nombre: "Clicks, Not Code". Y no es solo un eslogan. Salesforce invirtió mucho en herramientas declarativas que permiten que profesionales sin formación en programación creen soluciones poderosas. En la práctica, un Admin habilidoso resuelve el 80-90% de las necesidades de negocio sin tocar código.

En esta guía, te voy a mostrar las personalizaciones más importantes que puedes hacer sin código — y que son exactamente lo que cobre el examen de certificación Admin. Si estás estudiando para la cert o quieres mejorar tus habilidades de Admin, este contenido es para ti. ¿Hacemos una duck debugging session declarativa?

¿Por qué Salesforce prioriza las herramientas declarativas?

Tres razones prácticas:

Mantenimiento: Las configuraciones declarativas son más fáciles de mantener y documentar que el código. Cualquier Admin puede entender y modificar un Flow. Un trigger en Apex, en cambio, necesita un Developer — y si ese Developer se va de la empresa, otro Developer necesita entender el código antes de modificarlo. Con la configuración declarativa, el mantenimiento es más democrático.

Actualizaciones: Cuando Salesforce lanza una nueva versión (3 veces por año — Spring, Summer y Winter releases), las herramientas declarativas se actualizan automáticamente. El código personalizado puede romperse y necesita mantenimiento en cada release. Empresas con muchas personalizaciones en código pasan semanas probando y ajustando en cada release. Las que tienen personalizaciones declarativas pasan horas.

Velocidad: Crear un campo personalizado lleva 2 minutos. Escribir la misma funcionalidad en código puede llevar horas (incluyendo pruebas unitarias). Para la mayoría de las necesidades, lo declarativo es simplemente más rápido.

La regla de oro es: usa código solo cuando la herramienta declarativa no resuelve. Y en la práctica, las herramientas declarativas resuelven la gran mayoría de las necesidades. Antes de pedir ayuda a un Developer, pregúntate: "¿se puede hacer esto con clics?" Explícame como si fuera un pato... ¿qué exactamente necesitas que suceda? Muchas veces, al describir el problema en voz alta, te das cuenta de que la solución declarativa existe.

Custom Fields: los tipos que necesitas conocer

Los campos son la unidad básica de datos en Salesforce. Cada campo tiene un tipo que define qué tipo de información almacena. Elegir el tipo correcto es fundamental — cambiarlo después puede ser complicado.

Text: Texto libre. Hasta 255 caracteres para Text simple, hasta 131.072 para Long Text Area. Usa Text para nombres, descripciones cortas, identificadores. Usa Long Text Area para notas y observaciones detalladas. También existe Rich Text Area que permite formato (negrita, cursiva, enlaces).

Number: Números enteros o decimales. Define los decimales al crear. Úsalo para cantidades, scores, ratings. Atención: si el número es un identificador (como un DNI, RUT, CUIT), usa Text — no Number — porque los números no preservan los ceros a la izquierda.

Currency: Valores monetarios. Hereda la moneda de la org o del registro (para orgs multi-currency). Úsalo para precios, presupuestos, valores de contrato. No uses Number para valores monetarios — Currency formatea automáticamente con el símbolo de moneda y separadores.

Date / Date-Time: Fechas con o sin horario. Date para fechas simples (fecha de nacimiento, fecha de vencimiento). Date-Time para cuando el horario importa (fecha y hora de una reunión, plazo exacto de entrega). Atención con los zonas horarias: Date-Time almacena en UTC y convierte a la zona horaria del usuario.

Picklist: Lista de opciones predefinidas. Single select (elige una) o multi-select (elige varias). Excelente para estandarizar datos y evitar errores de tipeo. Úsalo para Estado, Categoría, Prioridad, Región. Las Picklists pueden ser restringidas (solo acepta valores de la lista) o no restringidas (acepta valores fuera de la lista vía API).

Checkbox: Verdadero o falso. Útil para indicadores y controles. "¿Activo?", "¿VIP?", "¿Envió contrato?". Simple y eficiente. El valor predeterminado siempre es "unchecked" (falso).

Formula: Campo calculado que toma datos de otros campos. No es editable directamente — el valor se calcula automáticamente en tiempo real. Extremadamente poderoso. Ejemplos: calcular edad a partir de la fecha de nacimiento, calcular margen de ganancia a partir del costo y el precio de venta, mostrar "Vencido" o "En plazo" basado en la fecha de vencimiento.

Lookup / Master-Detail: Relaciones entre objetos. Lookup es una referencia simple — como una clave foránea opcional. Master-Detail crea una dependencia fuerte (si el padre se elimina, los hijos también se eliminan, y el campo es obligatorio). La elección entre Lookup y Master-Detail impacta el comportamiento de sharing, roll-up summaries y cascade delete.

Roll-Up Summary: Solo disponible en Master-Detail. Suma, cuenta, calcula mínimo o máximo de los registros hijos. Ejemplo: en un objeto Pedido (padre) con Ítems de Pedido (hijos en Master-Detail), un Roll-Up Summary puede sumar automáticamente el valor total de todos los ítems. Es automático y en tiempo real.

Buenas prácticas de naming

El nombre del campo en Salesforce genera automáticamente un API Name. Buenas prácticas que separan a los profesionales organizados de los amateurs — y Quack ya vio orgs con naming tan desordenado que daban ganas de llorar:

• Usa nombres descriptivos: "Fecha de Vencimiento" en lugar de "FV" o "Fch_Venc"
• El API Name usa guiones bajos: Fecha_de_Vencimiento__c
• Incluye el sufijo __c en campos personalizados (esto es automático, no lo agregues manualmente)
• Mantén la consistencia: si un campo es Fecha_Creacion__c, no crees otro como Fch_Actualizacion__c o fechaFinal__c. Elige un estándar y síguelo para todos los campos
• Usa Help Text en todo campo personalizado — explica qué significa el campo y cómo debe completarse. Eso reduce tickets de soporte y capacita a los usuarios naturalmente
• No crees campos que no vas a usar. Cada campo adicional es complejidad. Menos campos bien pensados es mejor que muchos campos "por si acaso"

Custom Objects: cuándo y cómo crear

Los objetos son las "tablas" de Salesforce. Cada objeto almacena un tipo de dato. Account, Contact, Opportunity, Case, Lead son objetos estándar que vienen con la plataforma.

Cuándo crear un Custom Object:

• Necesitas rastrear algo que ningún objeto estándar hace
• Ejemplo: Proyectos, Equipos, Eventos, Reclamos, Contratos, Productos Internos
• La información tiene su propio ciclo de vida (se crea, se modifica, eventualmente se archiva)
• Necesitas reportes específicos sobre ese tipo de dato

Cuándo NO crear un Custom Object:

• La información cabe como campos adicionales en un objeto existente
• Ejemplo: agregar "Segmento" en Account es mejor que crear un objeto "Segmentos" con un registro por cuenta
• Estás duplicando funcionalidad que un objeto estándar ya ofrece

Cómo crear:

1. Ve a Setup → Object Manager → Create → Custom Object
2. Define el Label (nombre visible para el usuario) y el Plural Label
3. El Object Name (API name) se genera automáticamente — revísalo para asegurarte de que esté limpio
4. Activa la opción "Allow Reports" (casi siempre útil) y "Allow Activities" (si tiene sentido tener tareas asociadas)
5. Elige el tipo de Name field: Text (nombre libre como "Proyecto Alpha") o Auto Number (PRY-0001, PRY-0002...)
6. Configura el Deployment Status como "Deployed" cuando esté listo para que los usuarios lo vean

Standard vs Custom Objects:

• Standard: vienen con Salesforce (Account, Contact, Opportunity, Case, Lead). Ya tienen campos, relaciones y funcionalidades preconfiguradas
• Custom: los creas según la necesidad. Totalmente flexibles
• Los objetos estándar no pueden eliminarse, pero pueden personalizarse extensamente (nuevos campos, layouts, automatizaciones)
• Los objetos custom terminan con __c en el API name: Proyecto__c

Page Layouts y Compact Layouts

Los Page Layouts controlan qué campos aparecen en la página de un registro, en qué orden y con qué organización visual. Es la interfaz que ve el usuario cuando abre un registro.

Consejos para Page Layouts eficientes:

• Pon los campos más importantes arriba — el usuario no debería tener que hacer scroll para ver información esencial
• Agrupa campos relacionados en secciones con títulos claros: "Información Básica", "Datos Financieros", "Fechas Importantes"
• Usa columnas de 2 (el estándar) para aprovechar el espacio horizontal
• Usa el campo "Read-Only" en el layout para campos que el usuario no debe editar (pero sí puede ver)
• Elimina los campos que no se usan — menos contaminación visual = más productividad del usuario
• Pon related lists relevantes al final de la página (Contactos relacionados, Actividades, Historial)

Compact Layouts: Definen qué campos aparecen en la "tarjeta" resumen del registro — la que aparece en la parte superior de la página y en los lookups (cuando pasas el cursor sobre un enlace de registro). Pon solo 4-5 campos esenciales: los que el usuario necesita ver de un vistazo rápido sin abrir el registro.

Record Types + Page Layouts: Puedes tener diferentes page layouts para diferentes tipos de registro. Ejemplo: una Oportunidad de "Venta Nueva" muestra campos diferentes a una Oportunidad de "Renovación". Esto se hace combinando Record Types con Page Layout Assignments.

List Views: organizando tus datos

Las List Views son listas filtradas de registros. Todo usuario puede crear las suyas, y los Admins pueden crear vistas públicas para todo el equipo.

Cómo crear una List View útil:

1. Ve a un objeto (ej.: Oportunidades)
2. Haz clic en el engranaje → New
3. Define filtros (ej.: "Stage equals Negotiation" AND "Amount greater than 50000")
4. Elige qué columnas mostrar — menos es más, muestra solo lo esencial
5. Define la visibilidad (solo para ti, para un grupo específico, o para todos)

Consejos:

• Crea vistas por escenario: "Mis Oportunidades Abiertas", "Cierres Este Mes", "Oportunidades Paradas hace 30+ días"
• Usa filtros combinados (AND/OR) para refinar resultados
• Ordena por campos relevantes (fecha de cierre, monto, prioridad)
• Usa inline editing para actualizar campos directo desde la list view sin abrir cada registro
• Los Charts en la list view (ícono de gráfico) dan visualización rápida de los datos filtrados

Validation Rules: garantizando la calidad de los datos

Las Validation Rules impiden que datos inválidos se guarden. Son esenciales para mantener la calidad de la información — y son uno de los temas favoritos del examen de certificación.

Una Validation Rule funciona así: defines una fórmula que devuelve TRUE o FALSE. Si devuelve TRUE, el registro no se guarda y el usuario ve el mensaje de error que configuraste. ¿Parece contra-intuitivo, no? Piénsalo así: la fórmula describe la condición de error. Si la condición de error es verdadera, Salesforce bloquea.

Ejemplos prácticos:

Campo obligatorio condicional: Si el Stage es "Closed Won", el campo "Motivo de la Victoria" debe estar completado:

AND(
  ISPICKVAL(StageName, "Closed Won"),
  ISBLANK(Motivo_Victoria__c)
)

Mensaje de error: "El campo 'Motivo de la Victoria' es obligatorio cuando el Stage es 'Closed Won'."

Formato de email:

NOT(REGEX(Email_Secundario__c, "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}"))

Consejo: esta validación solo debe ejecutarse si el campo no está vacío. Usa AND con NOT(ISBLANK()) para evitar bloquear registros con el campo vacío.

Valor mínimo: El descuento no puede ser mayor al 30%:

Descuento__c > 0.30

Fecha en el pasado: La Fecha de Entrega no puede ser anterior a hoy:

Fecha_Entrega__c < TODAY()

Fórmulas útiles en Validation Rules:

• ISBLANK() — Verifica si el campo está vacío
• ISPICKVAL() — Verifica el valor de una picklist (necesario porque las picklists no se pueden comparar con =)
• REGEX() — Valida patrones (email, teléfono, código postal)
• AND(), OR(), NOT() — Combinación lógica
• TODAY() — Fecha actual (útil para "la fecha no puede estar en el pasado")
• $User.ProfileId — Perfil del usuario actual (útil para excepciones: "esta regla no aplica para Admins")
• PRIORVALUE() — Valor anterior del campo (útil para impedir cambios: "el Status no puede volver de Cerrado a Abierto")

Buenas prácticas para Validation Rules:

• Siempre escribe mensajes de error claros y orientadores — dile al usuario qué necesita hacer, no solo qué está mal
• Prueba todas las combinaciones posibles antes de activar en producción
• Documenta la lógica en anotaciones o help text
• Cuidado con las Validation Rules que entran en conflicto con Flows o data loads — se aplican a TODAS las formas de creación/edición de registros

Flow Builder: automatización sin código

El Flow Builder es la herramienta más poderosa del arsenal declarativo. Con él, automatizas prácticamente cualquier proceso. Si Quack pudiera elegir UNA habilidad para que un Admin domine, sería Flows. Sin lugar a dudas.

Tipos de Flow más usados:

Record-Triggered Flow: Se dispara cuando un registro se crea, actualiza o elimina. Es el sustituto de los antiguos Process Builders y Workflow Rules.

Ejemplo: cuando se crea un Case con prioridad "Alta", enviar una notificación al gerente y crear una tarea de follow-up para el analista.

Subtipos importantes:

• Before Save: Se ejecuta antes de que el registro se guarde. Más rápido y eficiente. Ideal para fast field updates (actualizar campos en el mismo registro sin usar DML).
• After Save: Se ejecuta después de que el registro se guarda. Necesario cuando necesitas el ID del registro o cuando necesitas crear/actualizar OTROS registros.

Screen Flow: Crea formularios interactivos para los usuarios. Es como construir un wizard o un formulario multi-paso.

Ejemplo: un wizard de onboarding que recopila información del nuevo empleado en etapas: datos personales → dirección → documentos → equipo. Al final, crea los registros necesarios automáticamente.

Los Screen Flows se pueden agregar a Lightning Pages, Quick Actions, Experience Cloud pages o ejecutarse como standalone.

Scheduled Flow: Se ejecuta en horarios programados. Es como un cron job visual.

Ejemplo: todos los días a las 8h, verificar oportunidades sin actividad hace 30 días y crear una tarea de follow-up para el owner. O: todos los lunes, enviar un email con el resumen de las métricas de la semana anterior.

Autolaunched Flow: Ejecutado por otro proceso (otro Flow, Apex, Process Builder, API). No tiene pantallas — es lógica pura de backend.

Cuándo usar Flow vs proceso manual:

• Si la acción ocurre siempre de la misma forma → Automatiza con Flow
• Si la acción requiere juicio humano → Mantén manual (o usa Approval Process)
• Si la acción involucra más de 3 pasos repetitivos → Flow ahorra tiempo
• Si el error humano es frecuente y costoso → Flow elimina el riesgo

Las herramientas de Setup que necesitas dominar

Object Manager: Central de configuración de objetos, campos, layouts, triggers y validaciones. Es donde pasas la mayor parte del tiempo como Admin. Aprende a navegar aquí con los ojos cerrados.

Schema Builder: Herramienta visual que muestra objetos y relaciones como un diagrama entidad-relación. Excelente para entender la estructura de datos de la org y para presentar a stakeholders no técnicos. También permite crear objetos y campos directamente en el diagrama.

Lightning App Builder: Constructor drag-and-drop de páginas. Permite crear home pages, record pages y app pages personalizadas sin código. Es como un "Wix para Salesforce" — arrastras componentes, configuras propiedades y publicas. Componentes disponibles incluyen: listas, gráficos, rich text, flows embebidos, reportes, componentes personalizados.

Setup Menu: El corazón de la administración. Aprende a navegar por Setup usando la barra de búsqueda (Quick Find). Es mucho más rápido que hacer clic en los menús. ¿Quieres encontrar la configuración de email? Escribe "Email" en Quick Find. ¿Quieres ver los Profiles? Escribe "Profiles". Domina Quick Find y serás 3 veces más rápido en Setup.

Ejercicio práctico: construye un rastreador de proyectos

Para poner todo en práctica, aquí tienes un ejercicio que combina todas las personalizaciones que vimos. Hazlo en tu org de Developer Edition — es hora de quack it out y poner manos a la obra:

1. Crea un Custom Object llamado "Proyecto" con campos: Nombre (Text), Estado (Picklist: Planificación, En Progreso, Pausado, Completado, Cancelado), Fecha Inicio (Date), Fecha Fin (Date), Responsable (Lookup para User), Presupuesto (Currency), Prioridad (Picklist: Alta, Media, Baja)

2. Agrega campos de fórmula: Duración (Fecha Fin - Fecha Inicio en días), Color de Estado (devuelve "🟢" para En Progreso, "🟡" para Pausado, "🔴" para Atrasado)

3. Agrega una Validation Rule: Fecha Fin no puede ser anterior a Fecha Inicio. Mensaje: "La Fecha Fin debe ser igual o posterior a la Fecha Inicio."

4. Configura el Page Layout: Organiza los campos en secciones: "Información del Proyecto", "Fechas", "Estado y Prioridad". Agrega related lists relevantes.

5. Crea List Views: "Mis Proyectos Activos" (Estado = En Progreso, Responsable = yo), "Proyectos Atrasados" (Fecha Fin < hoy AND Estado ≠ Completado), "Todos los Proyectos"

6. Crea un Record-Triggered Flow: Cuando el Estado cambia a "Completado", actualiza la Fecha Fin con la fecha actual automáticamente (before save)

7. Arma reportes y dashboard: Proyectos por Estado (gráfico de torta), Línea de tiempo de proyectos (gráfico de barras por mes), Presupuesto total por estado (summary report)

Si completas este ejercicio, ya tienes material para portafolio, una comprensión práctica de las herramientas más importantes de la plataforma, y una base sólida para el examen de certificación.

El poder de Salesforce está en transformar procesos complejos en soluciones simples — y no necesitas una sola línea de código para lograrlo. Quack check final: si entendiste los conceptos de este post y practicaste el ejercicio, estás mucho más preparado de lo que crees. Ahora ve y construye.

---

Preguntas Frecuentes (FAQ)

Si los Flows hacen todo, ¿por qué existe Apex?

Los Flows resuelven la mayoría de los escenarios, pero tienen limitaciones. Las integraciones complejas con APIs externas (HTTP callouts con lógica sofisticada), el procesamiento masivo con reglas de negocio intrincadas, las personalizaciones avanzadas de interfaz (Lightning Web Components) y las operaciones que necesitan rendimiento extremo todavía requieren código. La regla es: empieza con lo declarativo y ve al código solo cuando lo declarativo comprobadamente no resuelve. En la práctica, un buen Admin resuelve el 80-90% de los escenarios sin código.

¿Puedo romper mi org con las personalizaciones?

En la Developer Edition, puedes experimentar libremente — es tu laboratorio personal. Quack ya rompió muchas cosas en Developer Edition y sobrevivió para contarlo. En orgs de producción, siempre prueba primero en sandbox. Las Validation Rules pueden bloquear operaciones legítimas si no están bien pensadas (ej.: una validación que impide que los data loaders funcionen), y los Flows mal configurados pueden crear bucles infinitos o actualizar datos incorrectamente. Pero nada que una buena práctica de pruebas no resuelva. Regla: nunca pongas nada en producción sin probarlo extensivamente en sandbox.

¿Cuántos campos personalizados puedo crear?

Salesforce tiene límites (governor limits). En orgs Enterprise Edition, el límite es de 500 campos personalizados por objeto. En la práctica, si estás llegando a los 200+ campos en un solo objeto, probablemente necesitas replantear tu arquitectura de datos — quizás dividir en objetos relacionados. Menos campos bien planificados es siempre mejor que muchos campos innecesarios. Cada campo adicional es complejidad de mantenimiento, confusión para los usuarios y potencial contaminación de datos.

¿Flow Builder reemplazó a Process Builder y Workflow Rules?

Sí. Salesforce recomienda oficialmente usar Flow Builder para todas las automatizaciones nuevas. Process Builder y Workflow Rules todavía funcionan en orgs existentes, pero ya no reciben actualizaciones ni nuevas funcionalidades. Salesforce incluso ofrece una herramienta de migración ("Migrate to Flow") para convertir automatizaciones antiguas. Si estás aprendiendo ahora, enfócate 100% en Flows — no pierdas tiempo con herramientas obsoletas.