Permisos y segregación de funciones en Business Central: evitar accesos peligrosos
En Business Central, saber qué puede hacer cada usuario obliga a cruzar permission sets, control de acceso y, a menudo, XML poco legible. Dirección financiera y auditoría preguntan algo más duro: ¿quién puede comprar y pagar a la vez?
Eso es Segregación de Funciones (SoD) — y el estándar de BC no os lo pinta en una matriz clara.
El dolor real (no es «poner más permisos»)
- Caja negra. Para entender un usuario hay que recorrer sets uno a uno.
- Sin matriz SoD lista para auditoría. El estándar de BC no ofrece una visión SoD con alertas automáticas equivalentes: nadie avisa si alguien acumula funciones incompatibles (p. ej. alta de proveedor + pago).
- UI a medida a mano. Ocultar un campo o un botón por perfil acaba en desarrollo o en «que no lo pulse».
La licencia limita el tipo de usuario (Essentials, Team Member…); los permission sets limitan qué hace dentro. Son capas distintas: hace falta las dos bien.
Qué debería poder enseñar un buen gobierno
Pedid demo con un caso real:
- Matriz usuario × proceso (lectura / escritura / sin acceso) sobre permisos reales de BC, no un invento paralelo.
- Conflictos SoD detectados, con opción de reconocer, mitigar o aceptar (con nota para auditoría).
- Generación de permission sets sin vivir en XML a ciegas.
- Reglas para ocultar o deshabilitar campos y botones por usuario o perfil — sin recompilar la app cada vez.
Si la respuesta es «exportad a Excel los sets y revisad», no tenéis gobierno: tenéis deberes.
Cómo lo abordamos: SecurIA
SecurIA convierte los permisos de Business Central en una matriz visual, con motor de Segregación de Funciones, generador de permission sets y reglas de UI — escribiendo sobre los permisos reales del ERP.
Encaja en implantaciones nuevas, en limpiezas post-migración (donde se arrastran SUPER y sets eternos) y en auditorías.
¿Cuándo sí / no?
| Situación | Encaje |
|---|---|
| Varios usuarios, compras/pagos/contabilidad, presión de auditoría | Sí |
| Tres usuarios de confianza y poco movimiento | A veces basta disciplina + sets estándar |
| El problema es solo «Team Member vs Essentials» | Empezad por licencias |
| Queréis ocultar datos sensibles en pantalla | SecurIA (UI) + permisos; no solo esconder la columna en Excel |
Cómo lo vemos en DevConsultIA
Primero el mapa de quién hace qué de verdad; luego la matriz y los conflictos SoD. Sin vender miedo: con control.
Preguntas frecuentes
¿Los permission sets estándar no bastan? Para equipos pequeños, a veces sí. Cuando crece el organigrama o hay auditoría, la visión por proceso y el SoD marcan la diferencia.
¿SoD es lo mismo que la licencia Team Member? No. La licencia limita el tipo de usuario. El SoD limita combinaciones peligrosas de funciones.
¿SecurIA sustituye los permisos de Microsoft? No. Trabaja sobre los permisos reales de BC.
¿Hace falta para cumplir VERI*FACTU? Son temas distintos. VERI*FACTU es facturación; esto es acceso y gobierno. Ambos importan en un BC serio (factura electrónica).
Artículo informativo. Última revisión: agosto de 2026.