Arquitectura Salesforce para empresas: cómo diseñar un sistema escalable

La respuesta corta

Una buena arquitectura de Salesforce no se mide por la cantidad de componentes construidos, sino por la capacidad de la organización para incorporar un nuevo negocio, producto o mercado sin desmantelar lo que ya funciona. El problema más común que observamos no es una elección tecnológica incorrecta, sino la ausencia de una capa de decisiones documentada: quién es el propietario de cada objeto, por qué se eligió Flow en lugar de Apex, y por qué existen cinco integraciones separadas en lugar de una única capa de Middleware.

Este artículo desglosa la arquitectura en seis capas que deben planificarse en conjunto y no de forma aislada: modelo de datos y objetos, Sharing y permisos, automatización, integraciones, estrategia de Org y DevOps con Scalability. Una explicación ampliada sobre el manejo de errores de integración se encuentra en Monitoreo de integraciones de Salesforce.

Modelo de datos y objetos: la base sobre la que todo se apoya

Un error recurrente en muchas organizaciones: se crea un nuevo Custom Object para cada requisito que proviene del negocio, sin verificar si se puede usar un campo adicional en un objeto existente o un Record Type. El resultado después de dos o tres años es un Org con 80-120 objetos personalizados, algunos de ellos duplicados en significado, sin documentación que explique el propósito de su creación.

El principio rector es preguntar antes de crear cualquier objeto: quién es el propietario del negocio, cuál es la fuente de la verdad (Salesforce o un sistema externo), y qué sucede cuando un registro se elimina o se duplica. Las empresas que gestionan un catálogo de productos complejo, por ejemplo, suelen crear un Object separado para cada categoría en lugar de usar Record Types en Product2, lo que genera una carga de mantenimiento innecesaria en cada actualización.

Tabla útil para evaluar la madurez del modelo de datos:

Sharing y permisos: la capa que se rompe silenciosamente

Un modelo de permisos laxo no se detecta de inmediato; se revela cuando alguien ve un dato que no debería ver, o cuando un informe de gerencia muestra menos filas de lo esperado porque una Sharing Rule bloquea el acceso. La elección entre Role Hierarchy, Organization-Wide Defaults, Sharing Rules y Permission Sets debe derivarse de la estructura organizativa real, no de la estructura jerárquica oficial en el organigrama.

Un anti-patrón común: otorgar "View All" o "Modify All" a nivel de perfil para "resolver" un problema de permisos bajo presión de tiempo, sin luego volver y restringirlos. Esto funciona a corto plazo y crea una amplia exposición de información a largo plazo, especialmente en regulaciones como finanzas o salud. Permission Set Groups permiten construir permisos modulares que se pueden agregar y quitar sin tocar el perfil base, y esta es la forma más segura de abordar una organización en crecimiento.

Las Criteria-Based Sharing Rules en objetos con millones de registros requieren una prueba de carga antes de Production; hay casos en los que una regla de Sharing aparentemente inofensiva provoca una Recalculation que dura horas y bloquea los procesos nocturnos.

Automatización: Flow vs. Apex

La pregunta "Flow o Apex" no es una cuestión de gusto, sino de complejidad, volumen y ciclo de vida. Flow es más legible para un equipo operativo, se construye y mantiene rápidamente, y es adecuado para la lógica de negocio cambiante. Apex es necesario cuando hay Bulk Processing en miles de registros en una sola transacción, cuando se requiere un control preciso del orden de ejecución frente a otros Triggers, o cuando se necesita una prueba automática (Test Coverage) para fines de regulación o gestión formal de cambios (Change Management).

Un anti-patrón común en organizaciones en crecimiento: cadenas de Flow que se llaman entre sí (Flow que activa Flow que activa Flow), sin un mapa central que muestre el orden de ejecución. Cuando algo falla, nadie sabe qué Flow se ejecutó primero. Un ejemplo del mundo real: una organización con 14 Flows activos en Opportunity, tres de ellos con la misma lógica de actualización de estado, escritos en diferentes épocas por diferentes personas sin verificar lo que ya existía.

Regla general práctica: si hay más de 5-6 condiciones complejas en una lógica de negocio, o si se requiere una llamada externa dentro de un bucle, es preferible Apex. Fuera de eso, Flow es preferible porque es accesible para el mantenimiento incluso cuando el desarrollador original ya no está en la empresa.

Integraciones: de Point-to-Point a una capa gestionada

Una organización que comienza con dos conexiones externas (ERP y sistema de pago, por ejemplo) generalmente las construye directamente, Point-to-Point, y esto es razonable en esta etapa. El problema comienza cuando se agrega una tercera, cuarta y quinta conexión, cada una con su propia lógica de Retry, manejo de errores y mapeo de campos, sin un estándar común. En esta etapa, cualquier cambio en un sistema de origen rompe una o más conexiones sin que nadie lo sepa de antemano.

La transición a una capa de Middleware (MuleSoft, o una capa de Integration Layer personalizada) no tiene por qué ser un proyecto masivo; se puede comenzar con la conexión más frágil o más costosa de mantener y hacer la transición gradualmente. Principios a adoptar en cada nueva integración: Idempotency (una llamada duplicada no crea un registro duplicado), External ID para una identificación certera, y un log que permita reproducir exactamente lo que sucedió en cada llamada. Una ampliación sobre los patrones de integración se encuentra en Conectando Salesforce a un ERP y Patrones de integración de Salesforce.

Estrategia de Org: Single Org, Multi-Org o segmentación por unidad de negocio

Esta es una de las decisiones más costosas de cambiar a posteriori. Un Single Org con segmentación por unidad de negocio (utilizando Record Types, Sharing y Permission Sets para la separación lógica) es adecuado para la mayoría de las organizaciones, ya que mantiene una única fuente de verdad y métricas de informes unificadas. Un Multi-Org es apropiado cuando las unidades de negocio requieren modelos de permisos fundamentalmente contradictorios, cuando hay una fusión o adquisición que trae un Org existente, o cuando la carga real de permisos afecta el rendimiento.

La transición entre modelos una vez que la organización ya está construida es un proyecto pesado: fusión de datos, redefinición de permisos y, a menudo, pérdida de historial. Un desglose completo de los criterios de decisión se encuentra en Salesforce Multi Org.

DevOps y Scalability: Cómo mantener la capacidad de cambio

Una organización que desarrolla directamente en Production, sin un Sandbox ordenado y sin herramientas de CI/CD (como Copado, Gearset o SFDX), llega rápidamente a una situación en la que cualquier cambio es arriesgado. Un proceso de DevOps adecuado incluye al menos un Sandbox para desarrollo, un Sandbox para pruebas, control de versiones para Metadata y un proceso de Deployment automático con pruebas de regresión.

Tabla de decisiones arquitectónicas clave y sus implicaciones a largo plazo:

Caso de ejemplo organizacional

Una empresa de distribución con tres unidades de negocio trabajó durante cuatro años en un único Org, donde cada unidad añadió sus propios objetos, Flows e integraciones según la necesidad inmediata. Cuando la gerencia decidió añadir una cuarta unidad, se descubrió que no existía un documento que explicara quién era el propietario de cada objeto, y tres integraciones diferentes sincronizaban clientes con el sistema contable con lógicas contradictorias.

El equipo arquitectónico realizó un mapeo completo: identificó 23 objetos sin un Owner claro, seis cadenas de Flow superpuestas y dos integraciones que creaban registros duplicados debido a la falta de un External ID consistente. La solución no fue una reconstrucción, sino una documentación gradual, la unificación de la lógica de Sharing bajo Permission Set Groups y la migración de integraciones críticas a una única capa de Middleware. En dos trimestres, el tiempo para agregar una nueva unidad de negocio se redujo de varios meses a aproximadamente seis semanas.

Anti-patrones comunes en organizaciones en crecimiento

• Custom Object para cada solicitud - Se crea un nuevo objeto sin verificar si ya existe uno similar.
• Permisos amplios "temporales" - Se otorgan bajo presión y nunca se restringen nuevamente.
• Flow-in-Flow sin mapeo - Cadenas de automatización sin un diagrama de ejecución central.
• Point-to-Point sin Governance - Cada nueva conexión se construye por separado sin un estándar común.
• Desarrollo en Production - Cambios directos sin un Sandbox, pruebas o control de versiones.
• Ausencia de External ID - Sincronización por nombre o correo electrónico que crea registros duplicados.

Lista de verificación para evaluar la madurez arquitectónica

• ☐ Cada objeto personalizado tiene un propietario de negocio documentado.
• ☐ El modelo de Sharing se prueba bajo una carga de datos real.
• ☐ Existe un mapa central de todas las cadenas de automatización.
• ☐ Cada integración tiene un External ID, Retry y registro de errores.
• ☐ Existe un proceso ordenado de Sandbox a Production con pruebas de regresión.
• ☐ Se ha decidido explícitamente entre Single Org y Multi-Org con una justificación escrita.
• ☐ Los Governor Limits se verifican frente a la previsión de crecimiento de tres años.

Cuando la arquitectura de Salesforce requiere acompañamiento profesional y no solo un marco de trabajo independiente, este es el ámbito de Servicio de Arquitectura CRM.

Recursos profesionales

• Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
• Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
• HPI Pro – Arquitectura CRM — https://hpi.pro/crm-architecture
• HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data