Incorporar un usuario a un equipo
Objetivo
Incorporar a una persona a un equipo para que los registros del equipo le lleguen con las directivas Registros de mis equipos y Míos y de mis equipos.
Requisitos previos
- Ha iniciado sesión en el Centro de control de administración como administrador de la plataforma.
- La persona ya existe como usuario.
Pasos
- Abra la página Equipos desde la navegación de la izquierda, dentro de Usuarios.
- Marque la fila del equipo y seleccione Administrar miembros. Se abre un panel con los usuarios de su inquilino y un cuadro de búsqueda que filtra por nombre o por correo electrónico.
- Marque a las personas que deben estar en el equipo y desmarque a quien no deba estar. El recuento junto al cuadro de búsqueda es el total de miembros, así que no baja mientras filtra.
- Seleccione Guardar.
La pertenencia surte efecto de inmediato, en todos los entornos. No hay ningún retraso que esperar: al guardar, el cambio se copia a cada entorno y se incrementa su contador de seguridad, que es la clave de todas las decisiones almacenadas en caché.
Los equipos se editan aquí, no en una aplicación
Los equipos, los usuarios y los roles pertenecen a su inquilino, no a un entorno concreto. Cada entorno guarda una copia de ellos para que los registros de allí puedan pertenecer a un equipo y las directivas tengan miembros que leer, y esas copias son de solo lectura en una aplicación. Si abre la tabla Equipos o Pertenencias a equipos en una aplicación basada en modelo, puede mirar, pero no cambiar: crear un equipo ahí daría lugar a uno que existe en un solo entorno, no pertenece a la cuenta de nadie y nunca aparece en esta página.
Por eso la plataforma rechaza la escritura y le remite a esta pantalla. Las Unidades organizativas son la excepción y siguen siendo editables en una aplicación: una unidad es realmente el organigrama propio de un entorno, no la copia de nada.
Quién dirige una unidad
Una unidad organizativa tiene un Responsable: una búsqueda a un usuario, en el propio formulario de la unidad. Es quien dirige esa unidad, y está en la unidad y no en cada persona a propósito: que una unidad tenga un responsable es un hecho organizativo, mientras que quién depende de quién a título individual son datos de personal que la plataforma deliberadamente no guarda. Una sola fila que mantener al día en lugar de una por empleado, y que no puede quedarse desfasada para alguien el día que cambia de puesto.
Establézcalo en una aplicación, en la tabla Unidades organizativas, igual que establece la unidad primaria.
Todavía no lo lee nada. Está ahí para el enrutamiento de procesos: «envíalo a mi responsable» es la regla de aprobación más habitual que existe y, como las unidades ya forman un árbol mediante Unidad primaria, recorrer ese árbol hacia arriba desde el responsable de una unidad es también toda la escala de escalado: el aprobador del aprobador, y el de este. Un proceso de negocio podrá expresarlo sin que nadie escriba código.
Asignar no es esto
Asignar entrega un registro a una persona o a un equipo: cambia quién posee ese registro. No dice nada sobre quién está en un equipo.
No encontrará Asignar en un equipo, un usuario ni una unidad organizativa, y es deliberado: esas son las tablas en cuyos términos se expresa la propiedad. Una fila de una de ellas es una entidad de seguridad, no algo que posee una entidad de seguridad, así que «quién posee este usuario» es una pregunta para la que la plataforma no tiene respuesta: nada la lee nunca.
Por qué importa la pertenencia
Tres de las directivas integradas la leen (consulte Conceder a un rol acceso a registros):
- Registros de mis equipos: registros que posee un equipo al que pertenece la persona.
- Míos y de mis equipos: esos, más los que posee personalmente.
- Registros que poseo: deliberadamente no incluye los registros del equipo, que es la sorpresa más habitual en cualquier sistema de este tipo. Quien dice «no veo mi propio registro» suele tener esta directiva y estar mirando un registro que posee su equipo.
La pertenencia nunca concede un permiso. Decide a qué registros llegan los permisos que alguien ya tiene. Si no puede hacer algo en absoluto, necesita un rol, no un equipo.
Solución de problemas
- La lista de miembros está vacía. — el inquilino todavía no tiene usuarios, o no se pudieron cargar. Cree antes a las personas en la página Usuarios.
- «El equipo se guardó, pero no se pudieron actualizar los entornos: …» — la pertenencia está guardada; solo las copias de sus entornos están atrasadas, y el mensaje dice qué lo impidió. Corríjalo y vuelva a guardar la pertenencia; se puede repetir y los pone al día.
- La persona sigue sin ver los registros del equipo. — compruebe tres cosas por orden: que su rol conceda el permiso, que se conceda con una directiva que lea equipos (no Registros que poseo) y que el registro lo posea realmente el equipo y no una persona.
- Añadí una pertenencia y no cambió nada. — es el propietario del registro el que tiene que ser el equipo. Establezca el campo Propietario del registro en el equipo; la pertenencia decide a quién llega después.
- No puedo editar la tabla Equipos en mi aplicación. — correcto, y consulte más arriba: el equipo real está en la página Equipos del Centro de control de administración. La tabla de la aplicación es una copia, para que los registros de allí puedan pertenecer a un equipo.