Usuarios y permisos
Esta página es para quien administra el acceso al workspace. Lo que un usuario puede hacer lo definen sus permission sets: tiene de cero a N y sus permisos se suman (nunca se restan). No hay licencias ni cupos por tipo de usuario. Todo vive en Configuración → Acceso y seguridad.
Qué registros concretos ve dentro de una entidad lo decide otra capa, Sharing.
Invitar un usuario
Necesitás manage_users (y manage_permission_sets para asignar permission sets).
- Configuración → Acceso y seguridad → Usuarios → Invitar.
- Nombre y email.
- Permission sets: uno o varios (buscador con etiquetas). Se pueden cambiar después. Para un usuario de solo consulta alcanza con Read Only.
- Enviar invitación ahora (marcado por defecto): el usuario recibe un email con un link para crear su contraseña. Si lo desmarcás, la cuenta se crea y podés mandar la invitación más tarde desde su detalle (Enviar invitación).
Hasta que acepta, figura como Invitación pendiente. Si el workspace exige 2FA a usuarios nuevos, lo va a configurar en su primer ingreso (ver Seguridad).
La cantidad total de usuarios depende del plan del workspace (ver Configuración → Uso y límites).
Dos reglas fijas
- El propietario del workspace tiene siempre el permission set System Admin: no se le puede quitar ni se lo puede desactivar.
- Los usuarios externos (los clientes finales que se registran en una app tuya a través de External Identity) nunca reciben permisos de sistema ni el acceso total a entidades, aunque un permission set los marque: sólo el acceso a entidades de sus permission sets. No entran al CRM ni cuentan como usuarios internos. Ver External Identity.
Permission sets
Un permission set es un paquete de permisos con nombre que asignás a usuarios. Se administran en Configuración → Acceso y seguridad → Permission Sets con manage_permission_sets.
Cada workspace nace con tres del sistema, que no se pueden borrar ni renombrar:
| Permission set | Qué otorga | A quién |
|---|---|---|
| System Admin | Todos los permisos de sistema (incluye los que se agreguen en el futuro) y acceso total a todas las entidades | Al propietario, automáticamente |
| Standard User | Crear / ver / editar / eliminar en las entidades standard; sin permisos de sistema | Asignación manual |
| Read Only | Solo ver en las entidades standard | Asignación manual |
Crear uno
- Nuevo → un Label (nombre visible); el nombre técnico se genera solo y queda inmutable.
- Se crea vacío y se abre su detalle, organizado en cuatro categorías con un contador de permisos activos cada una: Entities, Access & Administration, Entity & Data, Automations & Integrations.
- Entrá a cada categoría, marcá lo que corresponde y guardá con el único Save del encabezado.
- Asignalo desde el detalle de cada usuario (Asignar) o desde la pestaña de usuarios del propio permission set.
Qué define un permission set
Permisos por entidad (categoría Entities). Una tabla entidad × acción:
| Permiso | Habilita |
|---|---|
| Crear / Leer / Editar / Eliminar | Las operaciones sobre registros de esa entidad |
| Pestaña visible | Que la entidad aparezca en la barra lateral y pueda anclarse como pestaña. Es independiente de Leer: podés dar lectura (para listas relacionadas, búsqueda, API) sin “ensuciar” la navegación |
El atajo Acceso total a entidades (all_entity_access) marca todo en todas las entidades, también en las que se creen después, y saltea el sharing por registro. Úsalo solo para administradores.
Permisos de sistema (las otras tres categorías). Los más usados:
| Permiso | Habilita |
|---|---|
access_settings | Entrar a Configuración (sin esto, el engranaje no aparece) |
configure_entities | Entidades, campos, Record Pages, App Pages, Home Page, tipos de registro |
manage_users / manage_permission_sets | Usuarios e invitaciones / permission sets y su asignación |
tenant_settings | Configuración del workspace: moneda, seguridad (2FA), sharing por defecto, acceso de soporte |
manage_list_views | Crear y editar list views |
manage_automations / manage_steppers / manage_schedules | Automations / Steppers / tareas programadas del workspace |
manage_integrations / manage_endpoints | Integraciones HTTP y connectors / Public API (API keys, endpoints, logs) |
manage_email_inboxes / manage_email_templates / send_email / view_all_emails | Bandejas de email / plantillas y defaults / componer y enviar / ver emails sin pasar por el sharing del registro |
manage_import_export | Importar y exportar registros |
view_reports / manage_reports / manage_report_folders | Ver reports / crearlos y editarlos / administrar carpetas |
view_field_history | Ver el historial de cambios de los registros |
view_file_audit | Ver la auditoría de archivos |
manage_pdf_templates / render_pdf | Diseñar templates PDF / generar PDFs |
manage_public_forms / manage_public_links | Formularios públicos / links públicos de registros |
install_packages | Instalar y actualizar paquetes del Marketplace |
manage_metadata | Retrieve / deploy de metadata con la CLI |
create_sandbox | Crear sandboxes (solo desde el workspace productivo) |
login_as | Entrar como otro usuario — equivale a admin, ver Login As |
Pulse agrega los suyos (manage_channels, manage_skills_queues, view_all_conversations, assign_conversations, bulk_close_conversations, view_agent_presence, summarize_conversations) — ver Pulse → Operaciones y permisos. Los paquetes instalados pueden sumar permisos propios (por ejemplo, aprobar descuentos en CPQ) y aparecen en la misma lista.
Cómo se combinan
- Si un usuario tiene dos permission sets con permisos distintos sobre la misma entidad, vale el más permisivo por cada acción.
- Un usuario sin permission sets solo puede iniciar sesión: no ve ninguna entidad.
- Un permission set se puede desactivar (botón en su detalle) sin quitarlo de nadie: deja de otorgar cualquier cosa al instante y se puede reactivar. Sirve como freno de emergencia, incluso para los que instaló un paquete.
- Los permission sets instalados por un paquete son de solo lectura: Clonar crea una copia editable.
Ejemplo. Un usuario con los permission sets “Ventas” (leer + editar Contactos, leer Oportunidades) y “Soporte” (leer + crear Casos, leer Contactos) termina con: Contactos leer y editar; Oportunidades solo leer; Casos leer y crear; nada de eliminar. Como ninguno le da configure_entities, no puede configurar entidades.
Permisos por campo
Cada permission set puede tener permisos por campo: Visible (sin él, el campo no viaja: ni en el detalle, ni en listas, ni en la API) y Editable. Sin nada definido, un campo hereda el acceso a la entidad: lo ve quien puede leerla y lo edita quien puede editarla.
Desde Configuración se definen al crear el campo: el paso Permisos del asistente lista los permission sets con las casillas marcadas según lo que cada uno ya tiene sobre la entidad. Destildá Visible para ocultárselo a ese set, o sólo Editable para dejarlo de solo lectura; tildar en un set que no tiene la entidad le da además lectura de la entidad. Los permission sets de sistema o de un paquete no se modifican (clonalos). Los permisos de un campo ya creado todavía no se editan desde Configuración: se cargan con la CLI de metadata. Si un usuario tiene dos permission sets y uno restringe el campo, la restricción vale salvo que el otro lo otorgue explícitamente.
Para ocultar un campo sólo de una pantalla (sin tocar el acceso), usá una Record Page propia para esa audiencia (ver Record Pages).
Roles
Los roles (Configuración → Acceso y seguridad → Roles) forman una jerarquía (CEO → Gerente → Vendedor) que se usa para el sharing por registro: quien está arriba ve los registros de quienes están debajo. No otorgan permisos por sí mismos; cada usuario tiene un rol como mucho y se asigna desde su detalle. Ver Sharing → Jerarquía de roles.
Editar o desactivar un usuario
Desde Configuración → Acceso y seguridad → Usuarios → (usuario) → Editar: nombre, email, rol y estado Activo / Inactivo. Las pestañas del detalle muestran sus permission sets (asignar / quitar) y, si tenés login_as, el botón Ingresar como este usuario.
- Desactivar: no puede ingresar; sus registros, notas y actividad se conservan y el dueño sigue figurando. Libera un lugar del cupo de usuarios. El propietario del workspace no se puede desactivar.
- Desactivar 2FA de un usuario que perdió su dispositivo: ver Seguridad.
- Los usuarios no se eliminan: se desactivan. Así nada de lo que crearon queda huérfano.
La pestaña Usuarios externos (si tu workspace usa External Identity) lista los clientes finales registrados desde tu app; se administran aparte y nunca entran al CRM.