Org (Salesforce)

Una org (abreviatura de "organización") es la instancia individual y aislada de Salesforce que pertenece a una empresa. Es el contenedor lógico que agrupa todo lo de ese cliente: sus registros de datos, sus usuarios, su configuración, sus objetos personalizados, su código y sus integraciones. Cuando alguien dice "lo cambié en la org" o "tenemos dos orgs", se refiere a este espacio único y delimitado.

Aunque Salesforce funciona como una plataforma multitenant (muchas empresas comparten la misma infraestructura física), cada org está lógicamente separada del resto: ningún cliente ve los datos de otro. Esa frontera es la unidad básica sobre la que se implementa, gobierna y mantiene una solución sobre Salesforce. Cada org tiene un Org ID propio (un identificador de 15 o 18 caracteres) que la distingue de cualquier otra en el mundo.

Entender qué es una org importa porque define el alcance de casi todo: los límites de la plataforma se cuentan por org, los permisos se asignan por org, y una migración o un despliegue siempre apuntan a una org concreta.

Qué incluye una org

Una org no es solo "la cuenta de Salesforce": es el universo completo de una empresa dentro de la plataforma. En la práctica, una org contiene:

• Los datos: cuentas, contactos, oportunidades, casos y todos los registros de los objetos de Salesforce, tanto estándar como personalizados.
• Los usuarios con sus licencias, perfiles y conjuntos de permisos que definen qué puede ver y hacer cada persona.
• La configuración y personalización: campos, layouts, automatizaciones con Flow, código en Apex, componentes y reportes.
• Las integraciones y la mensajería: conexiones con sistemas externos vía API, paquetes instalados desde AppExchange y los límites de cómputo (las governor limits).

Todo eso convive bajo un mismo Org ID. Si una empresa borra un objeto en su org, ese cambio no afecta a ninguna otra org del planeta.

Por qué importa el concepto de org

La org es la frontera de gobierno de cualquier proyecto Salesforce. Cuando un consultor habla de "la estrategia de orgs" de un cliente, está decidiendo algo estructural: cuántas instancias va a tener la empresa y cómo se relacionan. Esa decisión condiciona el costo, la complejidad de mantenimiento y la velocidad con la que se pueden hacer cambios.

También es clave para la seguridad y el cumplimiento. Como el aislamiento es por org, una empresa con operaciones en varios países a veces evalúa si conviene una org única (single-org) para todo el grupo o varias orgs separadas por unidad de negocio o región. No hay una respuesta universal: depende de cuánto comparten los procesos y los datos.

Tipos de org que vas a escuchar

No todas las orgs son iguales. Conviene distinguir las principales:

La distinción más importante en el día a día es producción versus sandbox: nunca se prueba algo nuevo directamente en producción; primero se valida en un sandbox, que es una org de prueba derivada de la real.

Single-org vs. multi-org: el dilema típico

Una pregunta frecuente en empresas medianas y grandes de la región es si conviene concentrar todo en una sola org o repartir en varias. La diferencia es real y conviene tenerla clara antes de implementar:

La tendencia general en proyectos nuevos es preferir la org única cuando los procesos de negocio se parecen, porque acerca a la única fuente de verdad y simplifica el gobierno.

Ejemplo concreto en Argentina

Pensemos en una empresa de Consumo Masivo argentina que vende a supermercados y también exporta a Uruguay y Chile. Si elige una org única, su equipo comercial ve en un mismo lugar las cuentas locales y las de exportación, comparte los mismos tableros y aplica las mismas automatizaciones. Si en cambio cada filial pidió una org separada en su momento, el reporting consolidado del grupo se vuelve un dolor de cabeza: hay que extraer datos de cada org y unificarlos por fuera. Por eso, antes de implementar, el primer trabajo del consultor es definir bien el modelo de orgs.

Errores comunes

• Confundir org con usuario o con licencia: una org tiene muchos usuarios; un usuario pertenece a una org. No son lo mismo.
• Probar en producción: hacer cambios directamente en la org real en vez de validar primero en un sandbox.
• Crear orgs nuevas sin estrategia: terminar con varias orgs sin haberlo planificado, y después no poder consolidar la información.
• Ignorar las governor limits por org: olvidar que los límites de cómputo se cuentan por org y diseñar integraciones que los rozan.

En resumen, la org es la pieza estructural que todo proyecto Salesforce define primero. Saber qué contiene, qué tipos existen y cuándo conviene una o varias es la base para una implementación ordenada y para que la empresa termine con una sola fuente de verdad y no con islas de datos.