Todo lo que hacemos realmente cuando implementamos, configuramos y conectamos un org de Salesforce, escrito al completo. Arquitectura de la plataforma y objetos, configuración de Sales Cloud y Service Cloud, desarrollo personalizado con Apex y Lightning, Flow automation, migración de datos, integraciones con el resto de tu stack, informes y adopción real. Sin tópicos genéricos sobre buenas prácticas. El método concreto.
Salesforce se vende como una plataforma que lo hace todo de serie. No es así. La configuración por defecto no encaja con casi ningún negocio real, y la brecha entre lo que se entrega y lo que tu equipo realmente necesita es exactamente donde fracasan las implementaciones. Esta guía cubre esa brecha al completo: cómo está estructurada la plataforma, cómo modelamos los datos, cómo automatizamos sin crear una pesadilla de mantenimiento, cómo migramos limpiamente y cómo conectamos el resto de tu stack sin crear una red frágil de llamadas API.
Salesforce es una plataforma cloud multi-tenant construida sobre una arquitectura metadata-driven. Todo lo que configuras, desde objetos y campos hasta Flows y page layouts, vive como metadato en tu org. Eso es lo que hace posibles los despliegues y el control de versiones: estás moviendo metadatos entre sandboxes y producción, no código en el sentido tradicional.
La plataforma se divide en clouds, cada uno orientado a una parte diferente del negocio. Los dos que implementarás con más frecuencia son Sales Cloud, que gestiona pipeline, cuentas, contactos, oportunidades y leads, y Service Cloud, que añade Casos, routing Omni-Channel, una base de conocimiento y herramientas para contact center. Comparten la misma plataforma subyacente y pueden coexistir en el mismo org.
Por encima de los clouds está tu personalización: los objetos y campos custom que modelan tu negocio específico, la capa de automatización (Flow y Apex), la capa UI (page layouts Lightning y Lightning Web Components) y la capa de integración que conecta Salesforce con tus otros sistemas. La secuencia importa porque las decisiones tomadas en la capa del modelo de datos se propagan hacia arriba por todas las demás capas.
Cada proyecto empieza con una auditoría porque el estado de un org existente (o los requisitos para uno nuevo) determina todo lo demás. Para los org existentes nos conectamos mediante una Connected App de solo lectura y ejecutamos un health check estructurado. Para las nuevas implementaciones conducimos un taller de requisitos antes de tocar la plataforma.
La auditoría cubre cinco áreas:
El resultado es una hoja de ruta priorizada. Cada elemento tiene el impacto de negocio cuantificado, el esfuerzo para corregirlo y si puede abordarse de forma declarativa o requiere desarrollo. Lo recibes antes de firmar ningún contrato.
El modelo de objetos es la base. Si lo haces mal, acabas con soluciones provisionales sobre soluciones provisionales, informes que requieren SOQL complejo para ser útiles y automatizaciones que se rompen cada vez que los datos cambian de forma. Aquí es donde fallan la mayoría de las implementaciones mal especificadas.
Salesforce proporciona objetos estándar para las entidades más comunes: Account, Contact, Lead, Opportunity, Case. Son buenos puntos de partida. La pregunta es cuándo extenderlos frente a cuándo construir un objeto custom. La regla es sencilla:
Las relaciones entre objetos en Salesforce son de tipo lookup (débil, el hijo puede existir sin el padre) o master-detail (fuerte, eliminar el padre elimina el hijo, los rollup summaries son posibles). Elegir incorrectamente significa no poder ejecutar los informes de rollup que necesitas, o perder datos cuando los registros padre se fusionan o eliminan. Documentamos el tipo de relación y el comportamiento de cascade-delete para cada relación que creamos, porque afecta a cómo puedes consultar los datos y qué ocurre en producción.
Una configuración de Sales Cloud bien hecha elimina la fricción entre cómo vende tu equipo y lo que el sistema espera de ellos. El mayor punto de fricción en casi todas las configuraciones por defecto es el ciclo de vida del lead: cómo un nuevo nombre se convierte en un contacto cualificado y cuándo pasa a ser una oportunidad.
Abordamos la configuración de Sales Cloud en cuatro partes:
El routing de leads asigna los nuevos leads al rep, territorio o cola correctos. El scoring de leads (mediante campos custom, reglas de scoring o una plataforma de marketing automation conectada) pone de relieve los leads que vale la pena llamar ahora. La conversión mapea los campos del lead sobre el Contact, Account y Opportunity resultantes, para que no se pierda ningún contexto original. La mayoría de las configuraciones por defecto pierden datos en la conversión porque el field mapping nunca se configuró.
Las etapas de las oportunidades deben reflejar cómo el equipo cierra realmente los tratos, no una metodología de ventas genérica. Entrevistamos al equipo, mapeamos las etapas reales sobre las probabilidades que Salesforce usa para el forecasting y escribimos criterios de entrada y salida para cada etapa para que el forecast sea significativo. Un pipeline con etiquetas de etapa arbitrarias produce previsiones en las que nadie confía.
El Collaborative Forecasting en Sales Cloud puede agregar los ingresos esperados por rep, manager y familia de producto en tiempo real. Hacerlo funcionar correctamente requiere que las probabilidades de las etapas estén calibradas, que la jerarquía coincida con la estructura real de reporting y que los registros de cuotas estén cargados. Rara vez se configura correctamente de serie porque requiere que la configuración y los datos estén en su sitio simultáneamente.
Los reps no registrarán llamadas y correos manualmente de forma sistemática. Einstein Activity Capture o una herramienta de terceros como Ebsta o Groove pueden sincronizar correo y calendario desde Gmail u Outlook automáticamente. La contrapartida es el volumen de datos y los costes de almacenamiento. Configuramos esto con retention policies que mantienen los datos útiles sin disparar los costes de almacenamiento.
Service Cloud está construido en torno a los Casos: la unidad de trabajo para una solicitud de soporte. Las preguntas de configuración son cómo llegan los casos, cómo se enrutan, cómo los trabaja el equipo y qué ve el cliente.
Los casos pueden originarse desde email-to-case, formularios web-to-case, llamadas telefónicas (mediante integración CTI), chat, redes sociales y portales de autoservicio. Cada canal tiene diferentes requisitos de configuración y diferentes posibilidades de enriquecimiento de datos. Configuramos primero los canales que tu equipo realmente usa y luego añadimos complejidad a partir de ahí.
Omni-Channel enruta los elementos de trabajo (casos, chats, llamadas) a los agentes en función de disponibilidad, capacidad y habilidad. El modelo de routing debe reflejar cómo está realmente organizado tu equipo. Una configuración de routing escrita para una estructura de equipo idealizada que no coincide con la realidad pondrá los casos en las colas equivocadas desde el primer día.
Los entitlements definen qué soporte se le debe a un cliente y antes de cuándo. Los milestones definen las acciones que deben ocurrir dentro de esos SLA. Es una de las funcionalidades más infrautilizadas de Service Cloud, porque configurarla correctamente requiere que tus contratos de soporte estén mapeados y tu lógica de escalado acordada. Cuando está configurada, Salesforce muestra en tiempo real qué casos corren el riesgo de incumplir el SLA, que es la única forma de gestionar un equipo de soporte de manera proactiva en lugar de reactiva.
La automatización es donde llegan los verdaderos aumentos de productividad. También es donde se acumula la mayor parte de la deuda técnica, porque la automatización añadida con el tiempo sin un patrón de diseño se vuelve imposible de entender o mantener.
El error más común que vemos en los Flows es un único Flow que intenta hacer todo desencadenado por un cambio de registro. Empieza con dos nodos de decisión y en tres años se convierte en algo que nadie entiende. Separamos las responsabilidades: un Flow por proceso, cada Flow hace una sola cosa, cada uno documentado con un campo de descripción que dice qué hace y cuándo se revisó por última vez. Las versiones de Flows se acumulan rápidamente; activamos solo una versión por Flow y limpiamos las versiones inactivas durante el proyecto.
Salesforce impone governor limits para proteger la infraestructura compartida de procesos desbocados. Los límites que se alcanzan con más frecuencia son el límite de consultas SOQL (100 consultas por transacción) y el límite DML (150 sentencias por transacción). Apex que hace consultas dentro de un bucle alcanza el límite SOQL casi inmediatamente con cualquier volumen de datos real. Escribimos todo el Apex con la bulkification en mente desde el principio: consultas fuera de los bucles, colecciones procesadas como conjuntos. Flow también está sujeto a límites, aunque son diferentes y la plataforma gestiona más automáticamente la bulkification en las versiones recientes.
La migración de datos es el paso que la mayoría de las implementaciones subestima. El trabajo no es mover registros; es decidir qué mover, limpiarlo antes de que llegue y verificarlo después. Los datos sucios migrados a un org nuevo no mejoran con el tiempo. Empeoran a medida que se acumulan más registros.
El Duplicate Management de Salesforce usa reglas de matching para identificar near-duplicates antes de que se creen y reglas de duplicado para bloquearlos o alertar al guardar. Esto previene futuros duplicados pero no hace nada con los existentes. Usamos los Data Quality Analysis Dashboards o una herramienta dedicada (DemandTools, CRMFusion) para sacar a la luz el conjunto de duplicados existentes, luego trabajamos con una estrategia de fusión: fusiones automáticas para pares de alta confianza, cola de revisión manual para casos ambiguos y una regla de supervivencia que define qué campos de qué registro ganan al fusionar.
Los campos de los datos fuente rara vez se mapean limpiamente sobre los campos de Salesforce. Los valores de picklist difieren, los números de teléfono están en formatos diferentes, las direcciones necesitan dividirse y los registros relacionados deben resolverse a IDs de Salesforce. Documentamos cada transformación en un migration spec antes de escribir una sola línea de código y validamos el spec con una carga de muestra antes de ejecutarlo a pleno volumen.
Salesforce rara vez vive en aislamiento. La pregunta no es si integrar sino cómo, y la respuesta es diferente según el volumen, la latencia y la criticidad de los datos que fluyen por la conexión.
Las opciones, en orden creciente de complejidad y coste de mantenimiento:
Para integraciones en tiempo real donde la latencia importa, los Salesforce Platform Events permiten a los sistemas externos suscribirse a los cambios en el org sin hacer polling. El Change Data Capture publica los cambios en los registros de Salesforce como eventos, que los sistemas downstream pueden consumir de forma fiable sin consultar la API según un schedule. Usamos estos patrones para escenarios de alta frecuencia y baja latencia como actualizaciones de estado de pedido o notificaciones de escalado de caso.
Los informes de Salesforce por defecto son un punto de partida, no un producto terminado. Los informes que tu equipo realmente usa deben construirse a partir de los datos que tu equipo realmente registra, visualizados al nivel de acceso de la persona que los lee e integrados en los workflows en los que ya están.
Abordamos los informes en tres niveles:
La implementación más completa fracasa si el equipo no la usa. La adopción no es un problema de formación; es un problema de diseño. Si el sistema es más difícil de usar que la hoja de cálculo que ha reemplazado, la gente usará la hoja de cálculo.
Las decisiones que impulsan la adopción se toman en la fase de diseño, no en la de formación:
La formación cubre la mecánica, pero lo que realmente eleva la adopción es la combinación de un sistema bien diseñado, un momento de go-live con una comunicación clara sobre qué ha cambiado y por qué, y una persona nombrada a la que llamar cuando algo parece incorrecto. Programamos una llamada de go-live, un check-in a las dos semanas y una retrospectiva a las cuatro semanas como parte de cada proyecto.
Cada proyecto es de alcance fijo y precio fijo. El alcance se redacta antes de que empiece cualquier trabajo, basándose en los hallazgos de la auditoría gratuita, y nada se expande sin una orden de cambio firmada.
Llevamos a cabo las implementaciones en tres fases con puntos de entrega claros:
Un solo punto de contacto. Tienes una persona que gestiona la relación, el calendario de entrega y cualquier escalado. Las especificaciones llegan con criterios de aceptación que tu equipo puede verificar. Todos los documentos fuente, mapas de datos y scripts de migración son tuyos al hacer el handover.
Una lista breve y honesta de lo que no hacemos, porque malgasta dinero:
Este es el método completo. Cuando quieras aplicarlo a tu org, el siguiente paso es una auditoría gratuita: un verdadero health check sobre tu org en producción, con una hoja de ruta priorizada, en aproximadamente una semana, sin ningún compromiso.
Un health check gratuito sobre tus datos reales de Salesforce, los hallazgos cuantificados y un alcance fijo para arreglar lo que importa. Resultados en una semana.
Solicita una auditoría Salesforce gratuita