En una implementación de Employee Central, una dependencia es la relación entre dos piezas de la configuración en la que una necesita que la otra exista y esté bien configurada para funcionar. La L4 la usa como concepto central: la secuencia de implementación es, en el fondo, un orden que respeta las dependencias entre las piezas de EC.
Las dependencias aparecen en todos los niveles. Los campos del empleado dependen de que el modelo de datos los habilite. Un desplegable depende de que su lista de selección exista y tenga valores activos. La información del puesto depende de que existan los departamentos, ubicaciones y entidades legales que referencia. La historia laboral depende de los motivos de evento. Un flujo de trabajo depende de que existan sus aprobadores, sus reglas y sus roles dinámicos. Con Position Management, la información del puesto depende de que la posición ya esté creada.
La Figura 4.1 de la lección las dibuja como una red: los modelos de datos en la base, las listas de selección y los objetos de fundamento apoyados en ellos, los datos del empleado apoyados en los objetos de fundamento y los motivos de evento, y los flujos de trabajo apoyados en los datos del empleado, las reglas y los roles dinámicos.
El valor práctico de pensar en dependencias aparece al diagnosticar. Cuando algo falla, el síntoma se ve en una etapa, pero la causa casi siempre está en una anterior. La Tabla 4.3 junta los casos más frecuentes: un desplegable vacío apunta a las listas de selección; una columna rechazada en una importación, al modelo de datos; filas de historia laboral rechazadas, a los motivos de evento o a los objetos de fundamento; un error porque el usuario no existe, al orden de carga de empleados; un administrador que no encuentra una herramienta, a los permisos; cambios que no llegan a los módulos de talento, a la sincronización de HRIS.
De ahí sale el consejo de la lección: usar la tabla al revés. Antes de tocar la configuración del paso que falla, revisar los pasos de los que depende. Ese método evita una trampa común en los proyectos, que es corregir el síntoma en lugar de la causa: por ejemplo, editar a mano cientos de filas de un archivo de importación cuando el problema era un motivo de evento que nadie creó.
El caso típico que describe la lección lo muestra bien. El equipo importa la historia laboral de toda la empresa y cientos de filas vuelven con error. La causa no está en el archivo ni en la herramienta de importación: falta un motivo de evento de transferencia, y cada fila que lo usa queda rechazada.
En Essentials vimos la misma lógica dentro de un flujo de trabajo, que se configura de adentro hacia afuera. En el Video 4.2 se recorre en el sistema un dato del empleado hasta la configuración de la que depende.
