Búsquedas frecuentes
Tutoriales actualizados
Un conjunto de permisos agrupa, bajo un nombre, los accesos que hacen falta para una tarea concreta.
Se asigna a las personas que tienen que hacer esa tarea y se retira cuando dejan de hacerla.
El perfil es el piso de acceso de cada usuario y solo puede haber uno por persona.
El conjunto de permisos es una capa que se suma encima, y una misma persona puede tener varias.
De esa diferencia sale la regla práctica: los conjuntos de permisos otorgan, nunca restringen.
Cuando hay que sacarle un acceso a alguien, el cambio va en el perfil o en el conjunto que se lo estaba dando.
Dentro de un mismo conjunto conviven cuatro clases de acceso.
El caso más común es el acceso temporal: alguien necesita una función durante un proyecto y después deja de necesitarla.
El segundo es evitar la multiplicación de perfiles, que aparece cuando cada combinación de accesos exige crear un perfil nuevo.
Con un perfil base y varios conjuntos encima, la misma matriz de accesos se arma combinando piezas en vez de duplicándolas.
Y el día que la persona cambia de puesto, el ajuste consiste en quitar y asignar conjuntos, sin rehacer su perfil.
Crear, modificar, asignar y eliminar conjuntos de permisos es tarea del administrador de la Plataforma.
El usuario no los ve como una pantalla propia: los percibe como funciones que aparecen o desaparecen de su interfaz.
El hub de Seguridad, permisos y acceso a datos ubica este concepto dentro de un proceso empresarial.
En Claudeforce: qué cambia cuando el CRM vive dentro de Claude vemos cómo se aplica a decisiones y tareas concretas.
Motor de Automatización de la Plataforma muestra cómo se refleja dentro de la Plataforma.
Y Seguridad de la Plataforma EGA Futura lo muestra desde otra parte del sistema.
En la Plataforma de EGA Futura ERP, el conjunto de permisos es la forma de ampliar el acceso de una persona sin tocarle el perfil.
Esa es toda la gracia: el perfil de usuario fija la base que comparte un equipo entero, y el conjunto suma encima, uno por uno.
La persona no encuentra una pantalla llamada conjunto de permisos: encuentra funciones que aparecen.
Una aplicación más en el Iniciador de aplicación (Waffle), un campo que pasa a ser editable, un botón de exportar que antes no estaba.
Por eso mismo dos personas con el mismo perfil pueden terminar con accesos distintos, sin que ninguna de las dos vea por qué.
Un pedido del tipo "que Juan también pueda ver los costos" casi nunca se resuelve con un perfil nuevo.
Se resuelve nombrando tres cosas: a quién se le habilita, sobre qué objeto o campo, y por cuánto tiempo.
Ese tercer dato es el que más se olvida y el que más cuesta después, porque un acceso que se abrió para un proyecto puntual queda abierto mientras nadie lo revise.
La pregunta previa es si la necesidad es de una persona o de un puesto.
Cuando le pasa a todo el equipo a la vez, lo que está corto es el perfil. Cuando le pasa a una persona, a un reemplazo o a un proyecto, el camino es el conjunto de permisos.
Y conviene decir desde el principio qué acceso alcanza para la tarea, porque los conjuntos se acumulan y lo que se concede de más también hay que retirarlo. El detalle campo por campo se ajusta con la seguridad a nivel de campo.
Los conjuntos de permisos suman accesos sobre lo que ya trae el perfil, y esa lógica de suma explica casi todas las dudas. Repasamos las diferencias con el perfil, cuántos se asignan a la vez y quién los crea.
Sirve para ampliar el acceso de una persona sin modificar el perfil que comparte con el resto de su equipo.
Es la vía para habilitar algo puntual, y también para retirarlo cuando deja de hacer falta.
El perfil fija el acceso base y cada usuario tiene uno solo.
Los conjuntos de permisos se suman a ese acceso base y una misma persona puede tener varios asignados.
No: los conjuntos de permisos solo otorgan.
Para restringir hay que ajustar el perfil o retirar el conjunto que estaba concediendo ese acceso.
Prevalece el permiso más amplio y el usuario obtiene ese acceso.
Los conjuntos de permisos siempre se acumulan sobre los del perfil.
Sí, y es el uso habitual: cada conjunto cubre una tarea o responsabilidad distinta.
El acceso final es la suma del perfil más todos los conjuntos asignados.
Solo el administrador de la Plataforma EGA Futura, que además es quien los elimina cuando quedan sin uso.
Sí: un conjunto puede incluir el acceso a aplicaciones y pestañas concretas.
Eso permite abrir un módulo a un grupo reducido sin habilitarlo para todos los que comparten su perfil.
Esta ficha es para quien escribe requerimientos de acceso sobre la Org y necesita nombrar lo que pide.
Un conjunto de permisos se arma en cinco bloques: objetos, campos, permisos de sistema, aplicaciones y pestañas, y clases de Apex y páginas.
Nombrar el bloque correcto es la mitad del trabajo, porque cada uno se concede y se retira por separado.
El bloque de objetos define qué se hace con los registros de una tabla completa.
Son seis niveles independientes, y activar uno no arrastra a los demás.
| Nivel | Nombre en inglés | Qué habilita |
|---|---|---|
| Leer | Read | Consultar los registros del objeto a los que la persona ya llega |
| Crear | Create | Dar de alta registros nuevos |
| Modificar | Edit | Cambiar los registros que ya ve |
| Eliminar | Delete | Enviar registros a la Papelera de reciclaje |
| Ver todos | View All | Ver todos los registros, sin importar el propietario |
| Modificar todos | Modify All | Modificar y eliminar todos los registros del objeto |
Los dos últimos conviene pensarlos dos veces, porque pasan por encima de la colaboración y alcanzan al objeto entero.
El bloque de campos ajusta el detalle dentro de un objeto al que la persona ya entra.
Tiene dos niveles, y el de modificación incluye al de lectura.
| Nivel | Nombre en inglés | Qué habilita |
|---|---|---|
| Acceso de lectura | Read Access | El campo se ve en el Detalle, en la Vista de lista y en un informe |
| Acceso de modificación | Edit Access | El campo además se edita, desde la pantalla y por API |
Un campo calculado ofrece acceso de lectura solamente, porque su valor sale de una fórmula.
Cuando el pedido habla de ocultar un dato puntual y no una pantalla entera, lo que se pide es seguridad a nivel de campo.
Es la familia que más aparece en los pedidos, porque casi todo requerimiento que empieza con "quiero ver" termina siendo un informe.
La columna en inglés importa: es el nombre con el que el permiso figura en las herramientas de metadatos.
| Permiso | Nombre en inglés | Qué habilita |
|---|---|---|
| Ejecutar informes | Run Reports | Correr informes y paneles ya existentes |
| Crear y personalizar informes | Create and Customize Reports | Armar informes en carpetas personales |
| Modificar mis informes | Edit My Reports | Editar los informes propios en carpetas compartidas |
| Gestionar informes en carpetas públicas | Manage Reports in Public Folders | Administrar informes públicos y su colaboración |
| Ver informes en carpetas públicas | View Reports in Public Folders | Acceder a los informes de carpetas públicas |
| Exportar informes | Export Reports | Usar Exportar detalles y Vista imprimible |
| Suscribirse a informes | Subscribe to Reports | Programar el envío automático de un informe |
| Suscribirse a informes: Establecer el usuario que ejecuta | Subscribe to Reports: Set Running User | Definir con los datos de quién se calcula lo que llega |
| Crear y personalizar paneles | Create and Customize Dashboards | Armar paneles en carpetas personales |
| Modificar mis paneles | Edit My Dashboards | Editar los paneles propios en carpetas compartidas |
| Gestionar paneles en carpetas públicas | Manage Dashboards in Public Folders | Administrar paneles públicos y su colaboración |
| Ver paneles en carpetas públicas | View Dashboards in Public Folders | Acceder a los paneles de carpetas públicas |
| Gestionar paneles dinámicos | Manage Dynamic Dashboards | Crear paneles que se calculan con los datos de quien mira |
| Ver los paneles de Mi Equipo | View My Team's Dashboards | Ver los paneles de quienes están por debajo en la jerarquía |
Un pedido de tablero gerencial se traduce casi siempre en tres de estos: ejecutar, ver en carpetas públicas y suscribirse. El concepto general vive en el término informe.
Acá entran los pedidos que suenan operativos y en realidad son permisos de sistema.
| Permiso | Nombre en inglés | Qué habilita |
|---|---|---|
| Crear y personalizar Vistas de lista | Create and Customize List Views | Armar Vistas de lista propias |
| Gestionar Vistas de lista pública | Manage Public List Views | Administrar las Vistas de lista que ve todo el equipo |
| Modificaciones masivas desde listas | Mass Edits from Lists | Editar varios registros a la vez desde una Vista de lista |
| Transferir registro | Transfer Record | Cambiar el propietario de la mayoría de los registros |
| Importar objetos personalizados | Import Custom Objects | Cargar datos con el Asistente de importación |
| Ver todos los nombres de registros de búsqueda | View All Lookup Record Names | Ver el nombre del registro relacionado aunque no lo alcance la colaboración |
| Ver datos cifrados | View Encrypted Data | Leer en texto plano los campos cifrados |
| Modificar clasificación de datos | Modify Data Classification | Marcar la sensibilidad de cada campo |
| Acceder a actividades | Access Activities | Entrar a tareas, eventos, calendario y correo |
| Modificar eventos y Modificar tareas | Edit Events / Edit Tasks | Crear, editar y eliminar eventos y tareas |
Los dos más delicados son Ver datos cifrados y Transferir registro, porque uno abre información sensible y el otro cambia de manos la responsabilidad.
Un requerimiento de comunicación saliente casi nunca es uno solo de estos permisos.
| Permiso | Nombre en inglés | Qué habilita |
|---|---|---|
| Enviar correo electrónico | Send Email | Escribirle a un contacto o candidato desde el registro |
| Correo electrónico masivo | Mass Email | Enviar un mismo mensaje a muchos contactos |
| Permitir envío de Correos electrónicos de lista | Allow sending of List Emails | Enviar correos a partir de una Vista de lista |
| Gestionar Plantillas de correo electrónico Lightning públicas | Manage Public Lightning Email Templates | Administrar las plantillas de la carpeta pública |
| Enviar notificaciones personalizadas | Send Custom Notifications | Disparar avisos propios desde un flujo o desde Apex |
Esta familia aparece cuando el requerimiento involucra a otro sistema y no a una persona frente a la pantalla.
| Permiso | Nombre en inglés | Qué habilita |
|---|---|---|
| API activada | API Enabled | Acceder a la Plataforma desde afuera, por cualquiera de sus API |
| Servicios REST de Apex | Apex REST Services | Llamar a los servicios REST escritos en Apex |
| Enviar mensajes salientes | Send Outbound Messages | Avisar a un servicio web externo cuando algo cambia |
| Modificar credenciales nombradas y externas | Allows users to modify Named Credentials and External Credentials | Cambiar las credenciales con las que la Org se conecta afuera |
El de credenciales merece un párrafo aparte en cualquier pedido, porque cambia la llave con la que la Org habla afuera.
Este bloque decide qué ve la persona al abrir el Iniciador de aplicación (Waffle).
Cada pestaña tiene tres estados posibles y solo uno a la vez.
| Estado de la pestaña | Nombre en inglés | Qué significa |
|---|---|---|
| Predeterminada activada | Default On | Aparece sola en la Barra de navegación |
| Predeterminada desactivada | Default Off | Existe, y la persona la suma cuando la necesita |
| Oculta | Tab Hidden | No aparece ni se puede agregar |
Y sobre la navegación general actúan estos permisos de sistema.
| Permiso | Nombre en inglés | Qué habilita |
|---|---|---|
| Usar funciones de identidad | Use Identity Features | Acceder al Iniciador de aplicación (Waffle) |
| Ver encabezado global | View Global Header | Cambiar de aplicación desde el encabezado |
| Acceder a aplicaciones móviles personalizadas | Access Custom Mobile Apps | Abrir desde el móvil las aplicaciones de tu empresa |
| Ver funciones y jerarquía de funciones | View Roles and Role Hierarchy | Consultar el organigrama, que define quién ve datos de quién |
El quinto bloque, el de clases de Apex y páginas, se completa cuando el pedido toca una función a medida: ahí se habilita la clase que la ejecuta.
Hay tres cosas que ninguna tabla explica y que deciden cómo se resuelve un requerimiento.
La primera es la diferencia entre perfil y conjunto. El perfil de usuario es la base, es uno solo por persona y describe un puesto entero.
El conjunto de permisos es una capa que se agrega encima, y una misma persona puede tener varios a la vez.
La segunda es que los conjuntos suman y nunca restan. Cada conjunto solo agrega acceso sobre lo que ya trae el perfil.
Una consecuencia es que dos personas con el mismo perfil pueden terminar con accesos distintos, según qué conjuntos acumuló cada una.
La otra es que para sacarle un acceso a alguien no alcanza con darle otro conjunto: hay que quitarle el que se lo daba. Si el acceso viene de dos conjuntos, se retiran los dos.
La tercera es cómo se traduce un pedido a un conjunto. Un requerimiento del tipo "que Juan también pueda ver los costos" casi nunca se resuelve con un perfil nuevo.
Se resuelve nombrando cuatro datos: quién, sobre qué objeto o campo, con qué nivel de los que figuran en las tablas, y hasta cuándo.
El último es el que más se olvida, porque un acceso abierto para un proyecto sigue abierto mientras nadie lo revise.
Y conviene mirar antes si la necesidad es de una persona o de un puesto: cuando le pasa al equipo entero, lo que quedó corto es el perfil.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
Quiero llevar mi Empresa a la Nube
