El ticket llega siempre con la misma frase: «no tengo acceso». Y entonces tres equipos miran al mismo usuario, cada uno por su ventana, y los tres responden lo mismo: de mi lado está bien.

El equipo de autorizaciones verifica y el rol está asignado. El equipo de Fiori verifica y la app está en el catálogo. El funcional verifica y el permiso existe. Nadie está mintiendo — están mirando tres permisos distintos, y el usuario necesita los tres a la vez.

Las cuatro capas, y la pregunta que responde cada una

En un ambiente con Fiori, un perfil no es una cosa — son cuatro, apiladas. Cada una responde una pregunta distinta, y fallar en cualquiera produce el mismo síntoma en pantalla.

El catálogo responde: ¿esta app existe y sabe adónde ir? Es el inventario. Guarda el tile que la persona ve y el mapeo de destino — la instrucción que dice qué aplicación abrir cuando se hace clic.

La página y el espacio responden: ¿esta app aparece en su pantalla? Es la capa visual. La página organiza los tiles en secciones; el espacio es la pestaña del launchpad que lleva esa página hasta el rol. Nada aquí concede permiso — es vitrina.

La actividad responde: ¿puede hacer lo que la app hace? Es el campo de autorización detrás del objeto — crear, modificar, visualizar, eliminar. Aquí sí es permiso de verdad, y es el único lugar donde vive.

El compuesto responde: ¿quién es esta persona en la empresa? Es el cargo. Es el único objeto que se asigna al usuario, y no contiene nada por sí mismo — agrega.

El síntoma engaña porque las cuatro fallan igual. Sin catálogo, la app no abre. Sin espacio, no aparece. Sin actividad, abre y da error de autorización. Sin el compuesto, nada de eso llega al usuario. Desde su silla, los cuatro casos son «no tengo acceso».

Cómo lo estructuramos, en la práctica

El diseño de abajo es el de una aseguradora de porte medio, con 78 roles simples y 56 espacios. No es el único posible, pero resuelve el problema que casi todo diseño de perfil tiene: saber, mirando el nombre, dónde buscar cuando algo falla.

Solo el compuesto se asigna al usuario. Representa el cargo — módulo, área y función. Dentro van exactamente dos roles: el simple homónimo, que carga todo lo de ese cargo, y un rol base, técnico, que todo usuario de launchpad necesita y que nadie debería duplicar.

Todo vive en el rol simple. Catálogo, página, espacio y datos de autorización — los cuatro en el mismo objeto. Es la decisión más importante del diseño, porque crea un lugar único donde buscar. Cuando alguien dice que el perfil está mal, no hay duda de dónde mirar.

El compuesto agrega, no contiene. No guarda contenido propio: reconstruye el menú a partir de los roles que contiene. Eso tiene una consecuencia práctica que cuesta horas a quien no la conoce — tocar el simple no llega al usuario hasta que el compuesto se reagrega. El contenido está bien, la prueba falla, y el equipo busca el error en el lugar equivocado.

El nombre carga la convención. Rol y contenido usan el mismo identificador, cambiando solo el separador: el rol usa dos puntos, y la página, el espacio y el catálogo usan guion bajo. Parece detalle cosmético. No lo es: es lo que permite hallar el catálogo de un rol sin consultar a nadie, y fue lo que hizo posible auditar las 78 estructuras por consulta en lugar de pantalla por pantalla.

Por qué el tile aparece y no abre

Ese es el defecto más común cuando los catálogos fueron armados por copia manual, y merece nombre propio porque no se parece a lo que es.

Un tile en el catálogo tiene dos partes: el tile, el cuadradito en la pantalla, y el mapeo de destino, la instrucción de adónde navegar. Copiar un catálogo por la interfaz trae el tile y no trae el mapeo. El resultado es un launchpad de apariencia perfecta donde hacer clic no hace nada.

En uno de los casos, un catálogo tenía 96 tiles y cero mapeos. Y el defecto opuesto también existía: catálogos con más de 2.600 mapeos y 30 tiles, porque alguien copió un catálogo estándar entero dentro del rol. En ambos casos el síntoma en pantalla es confuso; la causa es la misma decisión de armado.

Arreglar eso a mano no es viable — fueron más de 500 catálogos, con cerca de 860 mapeos recreados y 15.357 eliminados en la limpieza. En ese volumen el trabajo no es hacer mejor clic; es comparar la intención de cada tile con la de cada mapeo y actuar por lo que dice la comparación.

Lo que sale mal, con nombre

Tratar el catálogo como autorización. Sacar la app del catálogo no impide nada — la persona sigue llegando por la transacción clásica si la actividad lo permite. El catálogo esconde; la actividad prohíbe. Confundirlos produce la sensación de seguridad sin la seguridad.

Dar el permiso sin dar el camino. Lo inverso es igual de común y más silencioso: el usuario tiene todo lo que necesita y no encuentra la pantalla. No abre un ticket diciendo «mi catálogo está incompleto» — dice que el sistema no funciona, y alguien va a revisar autorizaciones durante horas.

Confiar en el nombre del rol como fuente de verdad. En bases con algunos años, el nombre es histórico. Encontramos roles cuyo nombre describía un cargo y cuyo contenido era otro — herencia de un paquete estándar instalado años antes. La fuente confiable es el mapa cargo → rol que mantiene la empresa, no el texto del objeto.

Asignar el mismo espacio dos veces. Ocurre cuando dos personas corrigen en paralelo, y el efecto es una pestaña repetida en la pantalla del usuario. Es trivial de resolver y casi imposible de percibir sin una verificación que cuente ocurrencias.

Corregir en el lugar equivocado. Editar el compuesto buscando contenido que está en el simple es el error que más tiempo consume, porque el equipo hace el cambio correcto en el objeto equivocado y concluye que el sistema está fallado.

El límite honesto

Ningún diseño de perfiles resuelve una organización que no decidió quién hace qué. Si dos áreas discrepan sobre quién aprueba una solicitud de pedido, eso no es un problema de autorización — es una decisión de negocio que se convierte, dentro del sistema, en un rol que nadie logra cerrar. Estructurar perfiles expone esa indefinición; no la resuelve.

También es honesto decir que la convención de nombres vale más que la herramienta. La mayor parte de la ganancia aquí no vino de la automatización: vino de decidir que rol y contenido comparten el identificador, y que solo el rol simple carga contenido. Después de eso, la automatización se volvió posible — antes, solo habría acelerado el desorden.

Y hay un costo de mantenimiento que no desaparece: cada app nueva tiene que entrar en el catálogo correcto, con el mapeo correcto, y aparecer en la página correcta. Sin alguien responsable de eso, la estructura vuelve a divergir en pocos meses — más despacio, por el mismo motivo de antes.

Si el punto de partida es entender lo que existe hoy antes de rediseñar, empiece por el diagnóstico de TI. Si la preocupación es el control de acceso como un todo, y no solo el launchpad, vea seguridad gestionada. Y si el ambiente ya está en operación y el problema es sostener la estructura en el día a día, el camino es AMS para SAP.

Preguntas frecuentes