Perfiles, roles y uso compartido en una organización REDA

REDA te entrega los conjuntos de permisos — pero ¿qué pasa con los perfiles, la jerarquía de roles y las reglas de uso compartido? Esos tres son mecánica pura de la plataforma Salesforce, que REDA no posee ni incluye, así que el cómo hacerlo en cada caso remite a la propia documentación de Salesforce. Lo que este artículo deja claro es la división del trabajo: REDA controla qué funciones puede usar una persona, mientras que los perfiles, los roles y el uso compartido controlan el acceso base y quién ve los registros de quién — y esos los diseñas tú. Al terminar de leer, sabrás exactamente qué te entrega REDA frente a lo que aún debes construir.

Dos trabajos distintos

Ayuda nombrar las dos capas con claridad, porque REDA es dueño de una y tú de la otra:

• Acceso a funciones — ¿esta persona puede usar arrendamiento, facturación, reservas, inspecciones? REDA lo entrega por completo mediante sus conjuntos de permisos (ver Creación de usuarios y concesión de acceso a REDA).
• Acceso base y visibilidad de registros — ¿esta persona puede siquiera abrir Cuentas y ejecutar informes, y de quién puede ver los registros? Esto proviene de los perfiles, la jerarquía de roles y la configuración de uso compartido — que REDA no incluye. Tú los construyes.

Los perfiles en una organización REDA

Un perfil es la capa base del acceso de un usuario — rige el inicio de sesión, los objetos estándar, los informes, los flujos y la visibilidad predeterminada de la app y las pestañas. En una organización REDA, el perfil lleva una carga específica y deliberada, porque los conjuntos de permisos de REDA dejan el acceso base enteramente al perfil. Ese acceso base incluye:

• Objetos estándar — acceso a Account, Contact, Task y Event. Ningún conjunto de REDA otorga nada de esto.
• Informes, flujos y edición de tareas — las capacidades de ejecutar informes, ejecutar flujos y editar tareas están desactivadas en todos los conjuntos de REDA, así que el perfil debe otorgarlas.
• App y pestañas predeterminadas — tanto la app REDA como REDA Admin se incluyen; el perfil decide qué app se abre de forma predeterminada y qué pestañas ve un usuario.

La recomendación práctica: mantén los perfiles mínimos — un acceso base limpio — y coloca encima los conjuntos de funciones de REDA.

Por qué REDA usa conjuntos de permisos y no perfiles

REDA no incluye perfiles personalizados ni grupos de conjuntos de permisos. Cada capacidad de REDA llega como un conjunto de permisos individual que asignas por persona. No existe un perfil "rol de arrendamiento" preempaquetado para repartir, ni un grupo que combine de antemano varios conjuntos de REDA en uno solo. Si quieres un paquete, construyes tu propio grupo de conjuntos de permisos del lado de la organización — pero nunca supongas que un perfil ya "incluye" una capacidad de REDA. No es así.

La jerarquía de roles

La jerarquía de roles es la estructura de Salesforce para el roll-up gerencial: permite que un gerente vea los registros que son propiedad de las personas debajo de él. REDA no incluye ninguna jerarquía de roles — tú la diseñas. En una organización REDA, su función principal es exactamente ese roll-up: permitir que un gerente de oficina vea los negocios, propiedades y tickets que son propiedad de su equipo. La mecánica de construir roles es de Salesforce; la razón para querer uno aquí es la visibilidad gerencial.

Uso compartido: valores predeterminados de toda la organización y reglas de uso compartido

Los valores predeterminados de toda la organización (OWD) fijan el piso de quién puede ver los registros de cada objeto; las reglas de uso compartido reabren el acceso para grupos específicos. REDA no incluye ninguno de estos — sin OWD, sin reglas de uso compartido, sin sharing sets. El diseño del uso compartido es enteramente tuyo.

Los objetos de REDA donde las decisiones de uso compartido realmente importan son los objetos basados en propietario, un registro por transacción — el registro de negocio o de arrendamiento (Oportunidad), Property, Inquiry, Ticket, y sus hijos (Invoices, Charges, Commissions). Esos tienen un propietario, así que quién-puede-ver-a-quién es una decisión real. Los datos de referencia y datos maestros de REDA — Regions, Charge Codes, Rules — normalmente son visibles para todos y se controlan mediante el acceso de lectura del conjunto de permisos, no mediante uso compartido.

REDA no prescribe un OWD específico. El patrón a seguir: para los registros transaccionales visibles por propietario, decide entre Privado y Lectura/Escritura pública según si los agentes deben ver los negocios de los demás; mantén abiertos los datos de referencia. La mecánica está en la documentación de Salesforce más abajo.

La división del trabajo

Una tabla, para que quede sin ambigüedad qué viene de REDA y qué construyes tú:

Ejemplo resuelto: accesos para una oficina de seis personas

Meridian Properties opera una oficina pequeña — un gerente y tres agentes de arrendamiento, más un contador y un auditor. Diseñar sus accesos toca las tres capas:

Si más adelante la oficina prefiere paquetes de un solo clic, puede envolver los conjuntos de REDA que más usa en su propio grupo de conjuntos de permisos — REDA no incluye ninguno, pero nada te impide construir el tuyo.

Qué sigue

1. Creación de usuarios y concesión de acceso a REDA — crea el usuario y asigna los conjuntos de REDA.
2. Cómo entender los conjuntos de permisos de REDA — el modelo de 31 conjuntos en detalle.
3. El modelo de acceso de REDA — busca qué conjunto necesita una tarea dada.
4. Protección de tu organización REDA — asegura la autenticación y las sesiones.
5. Ediciones: OEM vs. ISV — qué objetos viven en cada edición.

Preguntas frecuentes