Diseña un modelo de permisos con esquemas claros para planes, límites y banderas para que soporte y admins ajusten el acceso de clientes de forma segura sin depender de ingeniería.
Si vendes más de un nivel, tarde o temprano recibirás el mismo ticket de soporte: “El cliente X pagó por Pro, pero no puede acceder a la Función Y.” Sin un sistema claro, soporte no puede arreglarlo directamente. Un cambio simple de acceso se convierte en una tarea para ingeniería.
El problema mayor es la inconsistencia. Las reglas de acceso acaban dispersas por el producto: una casilla en una pantalla de administración, una comprobación codificada en la API, una nota en una hoja de cálculo y una actualización puntual en la base de datos del trimestre pasado. Los clientes ven comportamientos diferentes según el lugar, y nadie está seguro de cuál regla es la válida.
Un modelo de permisos te da una única fuente de verdad sobre quién puede hacer qué, basada en su plan y en cualquier excepción aprobada. Mantiene los niveles previsibles (para que el precio sea creíble), a la vez que deja espacio para la vida real: una mejora temporal, un aumento de cuota o una función piloto para una cuenta.
“Ajustar sin ingeniería” debe ser concreto. En la práctica:
Por ejemplo, un cliente en el nivel Business alcanza un límite de usuarios activos en una temporada intensa. Soporte debería poder conceder +10 asientos por 14 días, y el sistema debería revertirlo automáticamente cuando termine el periodo. Ingeniería sólo debe intervenir cuando se está añadiendo una capacidad completamente nueva, no cuando se hacen ajustes rutinarios de acceso.
Un buen modelo de permisos empieza con unos pocos objetos claros y una responsabilidad definida. Si estas bases son difusas, soporte acabará pidiendo a ingeniería “solo una excepción más” cada semana.
Aquí tienes un conjunto simple de bloques de construcción:
La evaluación de permisos no es facturación. Facturación responde “¿qué debemos cobrar y cuándo?” Los permisos responden “¿qué puede hacer este cliente ahora mismo?” Un cliente puede no haber pagado pero estar en periodo de gracia, o estar al día pero bloqueado temporalmente por cumplimiento. Mantén estas decisiones separadas para que finanzas pueda arreglar facturas sin cambiar accidentalmente el acceso al producto.
Varios grupos dependen de este esquema:
Define límites desde el principio. Haz que el contenido de los planes y las excepciones del cliente sean configurables (para que soporte actúe), pero mantén el comportamiento central en código. Ejemplos de “comportamiento central” incluyen cómo calculas la cuota restante, cómo manejas trials vencidos y qué acciones deben auditarse.
La mayoría de los problemas de niveles se simplifican cuando nombras correctamente el permiso. Hay tres tipos comunes, y cada uno responde a una pregunta diferente:
Las banderas son ideales para funciones que no deberían funcionar parcialmente. Si export está desactivado, oculta el botón y bloquea el endpoint también. Los límites funcionan bien para configuraciones de “capacidad” que no se reinician, como asientos, proyectos o vistas guardadas.
Las cuotas requieren cuidado porque el tiempo importa. Los tickets de soporte bajan rápido cuando la regla de reinicio está escrita y es visible en la UI de administración.
El ámbito (scope) es la otra decisión que evita confusión. Una bandera como “SAML SSO enabled” suele ser a nivel de cuenta. “Max projects” podría ser a nivel de workspace. “Puede ejecutar reportes” podría ser a nivel de usuario si vendes add-ons basados en roles.
Para cuotas, elige una regla de reinicio por cuota y cúmplela:
Si la regla de reinicio cambia según el plan, trata la propia regla como parte del permiso, no como conocimiento tribal.
Un modelo de permisos amigable para soporte suele funcionar mejor si se mantiene simple: pocas tablas, claves claras y registros acotados en el tiempo que puedas auditar. El objetivo es permitir a los administradores cambiar acceso editando datos, no desplegando código.
Empieza con cuatro tablas principales: plans, plan_entitlements, customers y customer_overrides.
Una forma relacional compacta que funciona bien:
plans: id, name, description, is_activeplan_entitlements: id, plan_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_bycustomers: id, name, plan_id, status, created_atcustomer_overrides: id, customer_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_byLos campos de permiso deberían ser consistentes entre tablas. Usa una key estable como seats, api_calls o sso_enabled. Usa type para mantener la evaluación sencilla (por ejemplo: flag, limit, quota). Almacena unit explícitamente (como users, requests, GB). Para cuotas, deja reset_policy sin ambigüedades (como monthly, daily, never).
Los overrides deben comportarse como una allowlist con fechas. Si un cliente tiene un override activo para sso_enabled=true, debe ganar sobre el valor del plan, pero solo dentro de effective_from y effective_to. Esto es lo que hace que “conceder 10 asientos extra por 14 días” sea un cambio de una fila que caduca automáticamente.
La evaluación de permisos es el pequeño fragmento de código (o servicio) que responde a una pregunta: “¿Se le permite hacer esto a este cliente ahora mismo?” Si esta parte es predecible, todo lo demás será más fácil de operar.
Usa un orden de precedencia claro y no lo desvíes: override del cliente \u003e valor del plan \u003e valor por defecto del sistema. Eso permite a soporte conceder excepciones temporales sin cambiar el plan y da a ingeniería valores seguros cuando nada está configurado.
Un flujo de evaluación práctico:
El cache importa porque los permisos se consultan constantemente. Cachea los permisos resueltos por cliente con un TTL corto y un número de versión explícito. Invalidar cuando cambie cualquiera de estos: asignación de plan, definición de plan, overrides de cliente o estado del cliente (trial, grace, blocked). Un patrón simple es “cache por customer_id + entitlements_version”, donde una edición por soporte incrementa la versión para que los cambios se reflejen rápido.
La seguridad multi-tenant es no negociable. Cada consulta debe filtrar por el id de la cuenta/cliente actual, y cada entrada de caché debe tener esa id como clave. No busques permisos por email, dominio o nombre del plan solo.
Un flujo amigable para soporte mantiene el modelo flexible sin convertir cada caso límite en una tarea de ingeniería. El objetivo es hacer cambios de forma segura, dejar rastro y confirmar la experiencia del cliente.
Empieza por encontrar el registro correcto del cliente y confirma qué piden y por qué. “Necesitan dos asientos más por una semana” es distinto de “firmamos una enmienda por un nivel superior.” Una buena UI de administración facilita ver, en un solo lugar, el plan actual, el estado del cliente y cualquier override activo.
Antes de cambiar nada, comprueba el uso real frente al límite o la cuota actual. Muchas solicitudes desaparecen al ver que la cuenta no está en el tope, o que el problema está en otra parte (por ejemplo, el seguimiento de uso no se está actualizando).
Cuando necesites ajustar acceso, prefiere un override explícito en lugar de editar el plan. Mantén los overrides acotados (una bandera o un límite), incluye un responsable y una razón, y por defecto una fecha de expiración. Las excepciones temporales son comunes y fáciles de olvidar.
Un checklist simple dentro de la herramienta de administración suele ser suficiente:
Siempre verifica el cambio tal como el cliente lo experimentará. Si permites impersonación, haz evidente cuando está activada y regístralo.
La mayoría de los problemas de permisos aparecen durante cambios: un cliente mejora a mitad de ciclo, una tarjeta falla o un trial termina en fin de semana. Si las reglas son vagas, soporte acaba adivinando y se involucra ingeniería.
Para upgrades, mantenlo simple: el acceso debería cambiar normalmente de forma inmediata, mientras que los detalles económicos quedan en facturación. Tu modelo de permisos debe escuchar un evento de facturación como “plan changed” y aplicar las nuevas entitlements de plan de inmediato. Si facturación hace prorrateos, perfecto, pero no incluyas la lógica de prorrateo dentro de los permisos.
Las downgrades son donde aparecen las sorpresas. Elige un comportamiento claro para downgrades y hazlo visible a soporte:
Los trials funcionan mejor como su propio plan, no como un booleano en el cliente. Da al plan trial flags y límites explícitos, además de una regla de expiración automática. Cuando el trial termina, mueve al cliente a un plan por defecto (a menudo “Free”) y aplica el comportamiento de downgrade que definiste.
Los periodos de gracia también son útiles para fallos de pago. Una ventana corta de “past due” (por ejemplo, 3 a 7 días) da tiempo para arreglar el pago sin perder acceso en medio de una jornada. Trata el periodo de gracia como un override con límite temporal, no como un nombre de plan personalizado.
Un consejo práctico: no enlaces los permisos a nombres de marketing como “Pro” o “Enterprise.” Mantén IDs internos estables (como plan_basic_v2) para que puedas renombrar niveles sin romper reglas.
Si soporte puede cambiar acceso sin ingeniería, necesitas un rastro. Un buen modelo de permisos trata cada cambio como una decisión registrada, no como un ajuste silencioso.
Para cada override, captura el actor, la razón de negocio y las marcas de tiempo. Si la organización lo requiere, añade un paso de aprobación para cambios sensibles.
Mantén el log simple para que realmente se use:
created_by y created_atapproved_by y approved_at (opcional)reason (texto corto como “paid add-on” o “incident credit”)previous_value y new_valueexpires_atLos controles de seguridad evitan accidentes antes de que lleguen a producción. Pon guardrails en la UI de administración y en la base de datos: limita valores máximos, bloquea números negativos y exige una fecha de expiración cuando un cambio es grande (por ejemplo, aumentar llamadas API 10x).
Soporte cometerá errores. Dales una acción única “revertir a los valores por defecto del plan” que borre los overrides a nivel de cliente y devuelva la cuenta al plan asignado.
Para auditorías, facilita la exportación del historial por cliente y rango de fechas. Un CSV básico que incluya razón y aprobador responde la mayoría de las preguntas sin tener que pedir intervención de ingeniería.
Ejemplo: un cliente en “Pro” necesita 30 asientos extra por un evento de una semana. Soporte pone seats_override=60 con expires_at el viernes siguiente, añade la razón “evento” y obtiene la aprobación del manager. Tras la expiración, el sistema vuelve automáticamente a 30, y todo el historial está disponible si facturación lo disputa después.
La forma más rápida de romper un modelo de permisos es dejar que crezca sin control. Unos atajos tempranos pueden convertirse en meses de tickets de soporte y “¿por qué este cliente puede hacer eso?” sin fin.
Un problema habitual es dispersar comprobaciones de funciones por todas partes. Si distintas partes de la app deciden el acceso de formas distintas, acabarás desplegando contradicciones. Centraliza la evaluación de permisos detrás de una función o servicio, y haz que toda UI y API lo use.
Otra trampa frecuente es mezclar estado de facturación con acceso. “Pagado” no es igual a “permitido”. Facturación tiene reintentos, devoluciones, trials y facturas que se liquidan después. Mantén eventos de facturación separados y tradúcelos a permisos con reglas claras (incluidos periodos de gracia) para que los casos límite no bloqueen usuarios ni les permitan acceso indefinido.
Evita confiar en una sola cadena de “tier” como “basic” o “pro” como única fuente de verdad. Los niveles cambian con el tiempo y las excepciones ocurren. Almacena flags y límites explícitos para que soporte conceda una capacidad sin dar accidentalmente todo lo que incluye una etiqueta de nivel.
Los overrides manuales son necesarios, pero overrides ilimitados sin controles se transforman en deuda invisible. Exige un responsable, una razón y referencia de ticket. Fomenta fechas de expiración o revisión. Mantén los overrides estrechos (una clave a la vez) y hazlos fáciles de auditar.
Las cuotas también se estropean cuando las reglas de reinicio son confusas. Define qué significa “por mes” (mes calendario vs 30 días rodantes), qué pasa al hacer upgrade y si la cuota no usada se acumula. Aplica estas reglas en la lógica del backend, no solo en la UI, para que los cambios de soporte no creen comportamientos inconsistentes entre web y móvil.
Antes de desplegar un modelo de permisos, haz una última revisión con las personas que lo usarán a diario: soporte, success y quien esté de guardia.
Asegúrate de que cada función se mapea a una clave estable con un dueño claro. Evita duplicados como reports_enabled vs reporting_enabled. Asegura que cada plan tiene valores por defecto explícitos para las claves que lances. Si una clave falta, falla seguro (normalmente negar acceso) y alerta internamente para que se corrija.
Para operaciones, confirma que el flujo es realmente usable:
Una prueba práctica: pide a soporte que conceda un add-on de 14 días a un cliente y luego lo elimine. Si pueden hacerlo con confianza en menos de dos minutos, vas por buen camino.
Imagina que ofreces tres niveles, y cada nivel define algunos permisos claros que aparecen en el producto y se aplican en el backend.
Ahora un cliente Team dice: “Tenemos un empuje de fin de trimestre y necesitamos 8.000 exports este mes. ¿Pueden ayudarnos por 30 días?” Esto es exactamente donde un override temporal es mejor que moverlos a otro plan.
Soporte abre el registro del cliente, añade un override como export_monthly_limit = 8000 y establece expires_at a 30 días desde hoy. Añaden una nota: “Aprobado por Alex (Sales), excepción de 30 días para reporting de Q4.”
Desde el lado del cliente, deben ocurrir dos cosas:
Si se pasan, ven un mensaje claro como: “Límite de exportaciones alcanzado (8.000/mes). Contacta soporte o haz upgrade para aumentar tu límite.”
Al expirar la fecha, el override deja de aplicarse automáticamente y el cliente vuelve al límite del plan Team sin que nadie tenga que acordarse de desactivarlo.
Empieza convirtiendo “funciones” en un pequeño catálogo de permisos. Da a cada ítem una clave clara, un tipo (flag vs limit vs quota) y un valor por defecto por plan. Este catálogo se vuelve el lenguaje compartido entre producto, soporte e ingeniería, así que usa nombres específicos y estables.
Decide dónde se aplica el enforcement. Una regla segura es: hacer enforcement en la API para todo lo que cambia datos o cuesta dinero, usar jobs en background para detener trabajos largos cuando se exceden límites y tratar la UI como guía (botones deshabilitados, mensajes útiles) pero no como la única puerta.
Mantén la primera versión contenida. Enfócate en los permisos que generan más preguntas, añade comprobaciones a las acciones de mayor riesgo y lanza una vista de administración que muestre cliente, plan, overrides e historial en un solo lugar.
Si quieres construir el panel de administración y la lógica subyacente rápido sin programarlo todo a mano, AppMaster (appmaster.io) es una opción práctica para este tipo de trabajo: puedes modelar planes y overrides como datos, implementar comprobaciones como procesos de negocio y entregar una UI de soporte que se mantenga coherente entre backend y apps.
¿Qué es un modelo de permisos y por qué lo necesitamos?Un modelo de permisos es una forma única y consistente de decidir qué puede hacer un cliente en este momento en función de su plan más cualquier excepción aprobada. Evita situaciones de “funciona en la UI pero falla en la API” haciendo que todas las partes del producto lean las mismas reglas.
¿Qué pasa si no tenemos un sistema claro de permisos?Soporte acaba presentando solicitudes a ingeniería para pequeños ajustes de acceso, y los clientes ven comportamientos inconsistentes en pantallas y endpoints. Con el tiempo, las reglas se dispersan entre código, casillas de administración, hojas de cálculo y actualizaciones puntuales de la base de datos, lo que facilita incidentes y disputas de facturación.
¿En qué se diferencian los permisos del estado de facturación?La facturación responde “qué cobrar y cuándo”, mientras que los permisos responden “qué está permitido ahora mismo”. Mantenerlos separados permite que finanzas arregle facturas y reintentos sin cambiar accidentalmente el acceso al producto.
¿Cuándo debo usar una bandera, un límite o una cuota?Usa una bandera cuando una capacidad debe estar completamente activada o desactivada, como habilitar SSO. Usa un límite para capacidades que no se reinician, como asientos máximos o proyectos máximos. Usa una cuota para uso en el tiempo, como exportaciones por mes, donde la regla de reinicio debe ser explícita.
¿Los permisos deben ser a nivel de cuenta, workspace o usuario?Elige el ámbito que coincida con cómo se vende y se aplica el producto: a nivel de cuenta para cosas como SSO, a nivel de workspace para recursos compartidos como proyectos, y a nivel de usuario para permisos o add-ons ligados a personas. Lo importante es usar el mismo ámbito en todos los lugares donde se verifica el permiso.
¿Qué reglas de precedencia debería seguir la evaluación de permisos?Un orden común es primero la excepción del cliente, luego el valor del plan y por último el valor por defecto del sistema. Si la clave falta o es desconocida, denegar el acceso para comprobaciones de enforcement y registrarlo como un error de configuración para que se corrija en lugar de conceder acceso silenciosamente.
¿Cuál es un diseño de base de datos práctico para planes y overrides de clientes?Almacena los valores por defecto del plan en una tabla y las excepciones específicas de cliente en otra, usando las mismas claves y tipos estables en ambos sitios. Haz que las excepciones tengan fechas de inicio y fin para que soporte pueda conceder acceso temporal que caduque automáticamente sin trabajos de limpieza.
¿Cómo hacemos las comprobaciones rápidas sin servir reglas obsoletas?Cachea los permisos resueltos por cliente con un TTL corto y un número de versión. Cuando soporte cambia una asignación de plan o una excepción, incrementa la versión para que el cliente vea la actualización rápidamente sin esperar a que caduquen las cachés.
¿Cuál es la forma más segura para que soporte conceda acceso temporal como “+10 asientos por 14 días”?Crea por defecto una excepción limitada con fecha de expiración y una razón clara, y luego verifica el resultado viendo el producto como lo haría el cliente. Evita editar el plan para solicitudes puntuales, porque eso cambia el acceso de todos en esa tier y es más difícil de auditar después.
¿Qué deberíamos registrar y auditar cuando soporte cambia permisos?Registra quién hizo el cambio, cuándo ocurrió, por qué se hizo, cuál era el valor anterior, cuál es el nuevo valor y cuándo expira. Además, ofrece una acción de “revertir a los valores por defecto del plan” para que los errores se deshagan rápidamente sin limpieza manual.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
