[Blog]()Permisos internos # Roles y permisos: quién consulta, cambia y autoriza en tu sistema Un menú oculto no demuestra que una acción esté bloqueada. Define permisos por tarea y comprueba el resultado con cada rol. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Define los permisos por acciones del negocio: consultar, crear, modificar, aprobar, cancelar y exportar. Asigna roles según responsabilidades y comprueba tanto el trabajo permitido como el intento que debe rechazarse. Si una aprobación requiere otra persona, esa separación debe seguir funcionando aunque el usuario tenga varios roles. ## Hoja de prueba: Roles y permisos internos: consulta, cambio y aprobación Un menú oculto no demuestra que una acción esté bloqueada. Define permisos por tarea y comprueba el resultado con cada rol. Registra datos, resultado esperado, evidencia, responsable y resultado observado. [Descargar hoja CSV]() En esta guía - [Empieza por las decisiones que pueden afectar dinero o datos]() - [Ejemplo ficticio: descuento del pedido P-606]() - [Prueba el permiso efectivo de cada cuenta]() - [Define excepciones con duración y dueño]() - [Conserva una matriz que puedas mantener]() ## Empieza por las decisiones que pueden afectar dinero o datos «Administrador» y «empleado» suelen ser categorías demasiado amplias. En una distribuidora, ventas necesita preparar un descuento; finanzas puede autorizarlo; almacén debe surtir lo aprobado. Escribe esas acciones antes de elegir nombres de roles. Incluye exportar información y cambiar reglas: ambos pueden afectar al negocio aunque no modifiquen un pedido directamente. [Business Central]() distingue permisos de lectura, inserción, modificación, eliminación y ejecución. [OWASP]() recomienda privilegios mínimos, denegar por defecto y validar permisos en cada solicitud. Por eso conviene probar el resultado de la acción, no solo la presencia de un botón. La combinación de roles también debe revisarse. ## Ejemplo ficticio: descuento del pedido P-606 Ventas solicita 12% de descuento para P-606. La regla del ensayo permite a ventas proponer, pero exige a finanzas aprobar descuentos superiores a 8%. La misma persona no puede aprobar su propia solicitud. Son umbrales ficticios elegidos para comprobar el flujo, no una recomendación de margen ni una capacidad ya implementada. Si el vendedor también recibe un rol temporal de supervisor, la separación entre solicitud y aprobación sigue vigente. Al rechazar el intento, el pedido mantiene el precio anterior y la solicitud queda identificada. Si finanzas autoriza, el sistema conserva quién decidió y qué versión del pedido vio. Un cambio posterior de cantidad requiere la revisión acordada, no reutilizar silenciosamente una aprobación antigua. | Acción |Ventas |Finanzas |Almacén | | --- | --- | --- | --- | | Consultar pedido |Sí, para su trabajo |Sí, para revisar |Sí, datos de surtido | | Solicitar 12% |Sí |No es necesario para este ensayo |No | | Aprobar solicitud propia |No |No |No | | Aprobar de otra persona |No |Sí, con criterio acordado |No | | Cambiar permiso de un usuario |No |No por ser aprobador |No | ## Prueba el permiso efectivo de cada cuenta Usa cuentas de ensayo con un rol y luego con combinaciones reales. Comprueba también una acción iniciada antes del cambio de permiso y completada después. Define cuándo toma efecto la revocación según el producto y qué debe pasar con trabajo pendiente. Registrar esa dependencia es más útil que prometer un efecto instantáneo que no has probado. | Caso |Resultado esperado |Evidencia | | --- | --- | --- | | Ventas solicita 12% en P-606 |Solicitud pendiente, sin aplicar descuento |Pedido y solicitud | | Ventas intenta aprobar su solicitud |Rechazo; precio sin cambio |Intento y comparación | | Finanzas aprueba solicitud ajena |Descuento aplicado una vez a la versión revisada |Decisión y versión | | Almacén intenta cambiar precio |Cambio rechazado aunque conozca la ruta |Solicitud y estado final | | Se retira rol de finanzas |Nuevo intento no conserva el permiso retirado |Hora y prueba del permiso efectivo | | Se repite aprobación tras una respuesta perdida |Misma decisión, sin doble cambio |Referencia de aprobación | ## Define excepciones con duración y dueño Una sustitución por vacaciones puede necesitar permisos temporales. Anota motivo, fecha de inicio, fin y quién revisará su retirada. Si nadie puede aprobar durante una ausencia, acuerda un suplente; no entregues una contraseña compartida para resolverlo. Los accesos de emergencia necesitan un procedimiento distinto, con comprobación posterior de lo que se hizo. Revisa qué hereda cada usuario de grupos, roles e integraciones. El alcance de un permiso puede depender de licencia, configuración y reglas personalizadas. Si la herramienta existente ya permite cumplir la matriz, configúrala y prueba antes de pedir otra. Si falta una separación crítica, documenta el caso concreto para comparar alternativas. ## Conserva una matriz que puedas mantener Actualiza la matriz cuando cambie una tarea, no solo cuando ingrese alguien. Relaciona las acciones con una [bitácora de cambios](), comprueba la [baja de empleados]() y conserva responsables de [llaves digitales](). Los permisos del portal de clientes tienen otra frontera: allí también importa impedir acceso a información de otros clientes. La hoja descargable propone diez pruebas internas y deja los resultados vacíos. Lleva tus aprobaciones, roles actuales y una excepción anonimizada a una [consulta gratuita]() de [ciberseguridad](). Podemos revisar qué acciones requieren un control verificable y qué depende de la configuración del sistema. ## Revisemos quién cambia y quién aprueba Una solicitud que exige otra aprobación permite probar los roles mejor que una lista de pantallas. Llévala al diagnóstico gratuito junto con las acciones permitidas y las sustituciones temporales para acordar qué debe aceptarse o rechazarse. - Acciones que consultan, cambian, aprueban o exportan - Roles y grupos actuales con sustituciones temporales - Una solicitud que deba aprobar una persona distinta [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Ciberseguridad para empresas]() - [Hosting, respaldos y mantenimiento]() ## Preguntas frecuentes ### ¿Ocultar un botón es suficiente? No demuestra autorización. Un usuario puede intentar la acción desde otra pantalla o por una solicitud directa. Comprueba que la decisión del sistema bloquea el cambio y deja el dato correcto, siguiendo las funciones y pruebas disponibles del producto. ### ¿Un gerente debe tener todos los permisos? No por su puesto. Identifica las acciones que necesita y separa administración de usuarios, aprobación de negocio y consulta. Dar permiso para autorizar descuentos no implica que deba poder cambiar las reglas que limitan esos descuentos. ### ¿Cómo pruebo usuarios con varios roles? Ejecuta la matriz con la combinación efectiva de grupos y roles. Presta atención a permisos que se suman o se excluyen y a restricciones de aprobación propia. La cuenta individual puede tener más acceso que cualquiera de sus roles visto por separado. ### ¿Qué hago si no hay un suplente? Define quién puede asumir temporalmente la decisión y por cuánto tiempo. Si la operación debe detenerse hasta obtener aprobación, hazlo explícito. Compartir credenciales elimina la atribución y no sustituye una regla de suplencia. ## Fuentes 1. [Define granular permissions]()Microsoft 2. [Authorization Cheat Sheet]()OWASP Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Control de accesos8 oct 2026 ### Baja de empleados: cuentas, sesiones e integraciones que debes revisar]()[Producción8 oct 2026 ### Órdenes de compra: autorizaciones, cambios y recepción comprobable]()[Portales8 oct 2026 ### Permisos de un portal: cada cliente solo ve lo que corresponde]() --- Canonical: https://nightlysoftware.com/blog/permisos-roles-sistema Updated: 2026-10-08 Description: Diseña permisos por acción y prueba aprobaciones, exportaciones y cambios de rol. Incluye una matriz para usuarios internos de tu negocio.