Los usuarios y permisos de GoHighLevel son la parte que nadie configura con cuidado hasta que pasa algo: un miembro del equipo que ve datos de clientes que no debería, un cliente al que le diste acceso y ahora anda tocando workflows, un empleado que se fue y su acceso sigue vivo. Los permisos no son burocracia: son la línea entre un equipo que trabaja tranquilo y un incidente de datos esperando fecha. Este artículo monta usuarios y permisos con criterio Y con ejecución: los tipos de acceso, cómo crear un usuario paso a paso, la matriz de roles, tres escenarios reales de configuración, y la regla del privilegio mínimo que lo gobierna todo.
El principio que ordena todo, prestado de la seguridad informática y válido aquí sin excepción, es el privilegio mínimo (least privilege, el corazón de cualquier control de acceso basado en roles o RBAC): da a cada persona el MÍNIMO acceso que necesita para su trabajo, ni uno más. No por desconfianza, sino porque el acceso que no se usa solo puede hacer daño: el error accidental, la fuga, el ex-empleado olvidado. El privilegio mínimo no ralentiza a nadie que trabaje bien; solo limita el radio del error de cualquiera.
Respuesta rápida
- Los niveles: usuarios de agencia (operan a través de subcuentas) y usuarios de subcuenta (limitados a una), cada uno con un rol que define qué ve y qué hace.
- Los roles: administrador (control total de su ámbito) y usuario limitado (solo su función: sus contactos, ciertas herramientas, sin tocar la configuración).
- Crear un usuario: desde la configuración de equipo, añadir usuario, sus datos, su nivel, su rol y las subcuentas o funciones a las que accede.
- La mejor práctica: privilegio mínimo. Cada persona con el acceso justo de su función, el administrador reservado para quien administra, y el acceso retirado en cuanto deja de necesitarse.
- La higiene innegociable: revisar accesos periódicamente y retirar de inmediato el de quien se va. El acceso vivo de un ex-miembro es deuda de seguridad pura.
| Rol típico | Ve contactos | Edita workflows y config | Gestiona facturación | Alcance | Ideal para |
|---|---|---|---|---|---|
| Admin de agencia | Sí | Sí | Sí | Todas las subcuentas | Dueño / socio |
| Usuario de agencia (gestor) | Sí | Según se configure | No | Las subcuentas asignadas | Gestor de cuentas |
| Admin de subcuenta | Sí | Sí (solo esa cuenta) | No | Una subcuenta | Responsable del cliente |
| Usuario limitado | Sus asignados | No | No | Una subcuenta | Comercial / atención |
Esa matriz es el mapa del privilegio mínimo: cada persona en la fila cuyo acceso coincide con su función, ni una columna de más. Ahora, cómo se monta.
¿Cómo se gestionan los usuarios y permisos en GoHighLevel?
Los usuarios en GoHighLevel se dividen en usuarios de agencia (operan a través de las subcuentas) y de subcuenta (limitados a una), y cada uno recibe un rol (administrador o limitado) que define qué ve y qué hace. La mejor práctica es el privilegio mínimo: dar solo el acceso necesario para cada función y retirarlo en cuanto deja de usarse.
Crear un usuario paso a paso
La ejecución concreta, a nivel de acción (la ubicación exacta de cada botón la ves en tu cuenta, y la interfaz evoluciona, pero la secuencia es estable):
- Entra a la gestión de equipo: en el nivel de agencia, desde la configuración de la agencia; en una subcuenta, desde los ajustes de esa subcuenta, en la sección de personal o equipo. Si aún no tienes subcuentas creadas, el paso previo es crear la subcuenta donde vivirán esos usuarios.
- Añade el usuario: la opción de agregar usuario abre el formulario con sus datos básicos (nombre, email, teléfono). El email será su acceso, así que ponlo bien.
- Elige el nivel: decide si es usuario de agencia (verá a través de subcuentas) o de subcuenta (limitado a una). Esta es la primera decisión de seguridad: define el alcance de todo lo demás.
- Asigna el rol: administrador (control total de su ámbito) o usuario limitado (solo su función). Aquí aplicas el privilegio mínimo: ¿esta persona necesita CONFIGURAR el sistema o solo OPERAR dentro de él?
- Acota el acceso: a qué subcuentas (si es de agencia) y a qué funciones y contactos (todos o solo los asignados). Cada límite que pones aquí es un riesgo que eliminas.
- Guarda e invita: al guardar, el usuario recibe su invitación por email para establecer su contraseña y entrar. Qué ocurre después: desde ese momento opera dentro de los límites que definiste, y toda su actividad queda ligada a su cuenta, lo que te da trazabilidad de quién hizo qué.
Los niveles y roles, explicados
Usuarios de agencia vs de subcuenta
La primera distinción es el ALCANCE. Un usuario de agencia opera a través de tus subcuentas (según su rol, todas o las asignadas): es para ti, tus socios y tu equipo que gestiona varios clientes. Un usuario de subcuenta vive limitado a UNA subcuenta: es para el personal de un cliente concreto, o para el propio cliente. Dar acceso de agencia a quien solo trabaja un cliente es abrirle la puerta a los datos de todos los demás (staff que ve subaccount users que no le tocan), exactamente lo que el privilegio mínimo prohíbe. El aislamiento entre clientes es tan crítico que en sistemas propios sobre la plataforma lo reforzamos con arquitectura multi-tenant; en la interfaz, los permisos son su primera línea.
Administrador vs usuario limitado
Dentro de cada nivel, el ROL define qué puede hacer. El administrador (agency admin o admin de subcuenta) tiene control total de su ámbito: crear, editar, borrar, configurar. El usuario limitado accede solo a lo que su función requiere: sus contactos asignados, ciertas herramientas, sin tocar workflows ni configuración. La pregunta práctica por persona: ¿necesita CONSTRUIR el sistema o solo OPERAR dentro de él? El comercial que atiende leads necesita ver y trabajar sus contactos, no editar los workflows que se los entregan; darle admin es darle capacidad de romper sin ganar nada.
Tres escenarios de configuración
Escenario 1: agencia con 3 empleados
Tú (o el socio) sois admin de agencia: control total. El gestor que lleva varios clientes va como usuario de agencia con acceso solo a las subcuentas de su cartera, sin facturación. El asistente que atiende conversaciones y agenda va como usuario limitado dentro de las subcuentas donde opera, con acceso a contactos y bandeja, sin configuración. Nadie que no administre de verdad tiene admin: si el asistente comete un error, su radio es su función, no el sistema entero.
Escenario 2: cliente que solo quiere revisar sus leads
Un usuario de subcuenta con rol limitado, acotado a ver sus contactos, su pipeline y sus reportes, SIN acceso a la configuración ni a los workflows. El cliente ve sus resultados y su operación diaria; no puede desactivar por curiosidad la automatización que le montaste. Esta separación (visibilidad de resultados sí, control del motor no) es la que evita el soporte de emergencia por algo que el propio cliente rompió «mirando». Si además le entregas la cuenta con un snapshot y su onboarding, sus permisos van definidos desde el primer día.
Escenario 3: freelancer de Facebook Ads temporal
Un usuario limitado del nivel y ámbito mínimos que su tarea pide: acceso a las funciones que necesita (por ejemplo, ver la fuente y calidad de los leads que generan sus campañas) en la subcuenta concreta, y nada más. Y con fecha de caducidad mental (mejor, un recordatorio): se retira al terminar el proyecto. El freelancer que acabó hace meses y sigue con acceso es el caso clásico de deuda de seguridad; el acceso temporal se trata como temporal desde que se da.
La higiene: altas y bajas
La parte que se descuida y más riesgo acumula. Cada alta con su rol correcto desde el inicio (add user con el mínimo, no con «admin para no lidiar con permisos»); cada BAJA retirada de inmediato (remove user al momento de la salida, no «cuando me acuerde»). El ex-empleado, el freelance que terminó, el cliente que se fue: su acceso vivo es una puerta abierta a datos que ya no le corresponden. La higiene de producción es doble: retirar al instante de la salida, y revisar periódicamente la lista completa preguntando «¿esta persona sigue necesitando esto?». Esa revisión (una auditoría de accesos, en lenguaje de seguridad) encuentra siempre accesos olvidados, y cada uno cerrado es un riesgo menos.
Cuándo NO complicar los permisos
Si eres un negocio de una persona sin equipo ni clientes con acceso, no necesitas una matriz de permisos: eres el administrador y ya. La estructura de roles crece con el equipo y la cartera, no antes. El error opuesto al descuido es la burocracia prematura: montar niveles elaborados para una operación que aún cabe en una persona. Empieza simple, y añade roles y límites cuando entre gente real a la que aplicárselos, con el privilegio mínimo como criterio desde el primer usuario que no seas tú.
Errores comunes al configurar permisos
- Admin para todos «para no lidiar con permisos»: multiplica el radio de cualquier error o fuga. Solución: cada persona con su rol justo desde el alta; añadir un permiso después cuesta un minuto, revertir un desastre cuesta una auditoría.
- Acceso de agencia a quien lleva un cliente: abre los datos de todos los clientes a quien solo trabaja uno. Solución: usuario de subcuenta limitado a esa cuenta; el nivel se ajusta al alcance real de la función.
- Cliente con acceso al motor: el cliente que desactiva un workflow «mirando». Solución: rol limitado con visibilidad de resultados pero sin acceso a workflows ni configuración.
- Bajas sin retirar acceso: el ex-miembro cuyo acceso sigue vivo semanas. Solución: retirada inmediata a la salida más revisión periódica de la lista completa de usuarios.
- Permisos elaborados prematuros: una matriz digna de multinacional para un equipo de dos. Solución: estructura proporcional al tamaño real, con la disciplina de nombres y de privilegio mínimo puesta desde el inicio.
Preguntas frecuentes
Desde la gestión de equipo (en la configuración de la agencia o de la subcuenta según el nivel), la opción de añadir usuario abre el formulario: datos básicos, nivel (agencia o subcuenta), rol (administrador o limitado) y el alcance de acceso. Al guardar, el usuario recibe una invitación por email para establecer su contraseña y entrar dentro de los límites que definiste.
Sí, y es esencial: un usuario de subcuenta queda limitado a esa subcuenta, sin visibilidad de las demás. Ese aislamiento es la base de operar varios clientes con tranquilidad; darle acceso de agencia a un cliente sería el error que abre los datos de todos los demás.
Además de los roles base (administrador y usuario), GoHighLevel permite acotar el acceso por funciones y por contactos dentro del rol de usuario, lo que da bastante granularidad práctica. Verifica en tu cuenta las opciones vigentes de permisos por función, porque la plataforma las va ampliando; el criterio no cambia: da solo lo que la función necesita.
Se retira de inmediato al momento de la salida. El acceso vivo de un ex-miembro es una puerta abierta a datos que ya no le corresponden, y el riesgo no espera a que alguien se acuerde. La retirada inmediata más la revisión periódica de la lista completa son la higiene innegociable.
Depende de cómo configures su rol: puedes darle acceso a todos los contactos de la cuenta o limitarlo a los que tiene asignados, según su función. El criterio es el de siempre: el acceso justo para su trabajo, ni más contactos ni más funciones de las que necesita.
Los permisos gobiernan el acceso de PERSONAS a la interfaz; las automatizaciones y agentes operan según su propia configuración y credenciales. Aun así, el principio se traslada: dale a cada integración y a cada agente el alcance mínimo que necesita, igual que a cada usuario humano, por la misma razón de limitar el radio del error.
Criterios y pasos verificados configurando usuarios y permisos en cuentas de agencia reales, a julio de 2026. El error que más repetimos ver al auditar cuentas ajenas es el mismo: admin repartido de más y bajas sin retirar. Si tu operación creció y los accesos se dieron sin método, ordenar los permisos con el privilegio mínimo es parte de lo que implemento.
La idea que protege tu operación
Los permisos son de esas cosas que no dan las gracias cuando están bien puestos y cobran caro cuando están mal: nadie nota el acceso correctamente limitado, todos notan la fuga o el workflow que un cliente desactivó. El privilegio mínimo (cada persona con el acceso justo de su función, retirado en cuanto deja de necesitarlo) no es desconfianza ni burocracia: es la forma de que el error de cualquiera se quede en su ámbito y de que los datos de tus clientes estén donde deben. Configúralo con la matriz y los escenarios de arriba desde el primer usuario que no seas tú, revísalo periódicamente, y tendrás lo que un CRM bien gestionado debe tener: un equipo que trabaja tranquilo sobre datos que solo ve quien debe.
