Una regla de negocio es una pieza de lógica que le dice al sistema qué hacer cuando se cumple una condición sobre los datos. El modelo de datos define qué campos existen, cómo se llaman, si son obligatorios y cómo se muestran. Lo que no define es el comportamiento: que un campo se complete solo, que un valor imposible se rechace, que un cambio de grado se registre como promoción y pase por aprobación. Ese comportamiento lo agregan las reglas. La academia oficial lo resume así: en Employee Central Core, las reglas de negocio automatizan procesos de RR. HH. como la derivación de flujos y de motivos de evento, las alertas y muchos otros.
En SuccessFactors las reglas no son exclusivas de Employee Central. La misma herramienta se usa en otros módulos de la suite, y por eso el editor es genérico y ofrece escenarios para cada caso de uso. En Employee Central, sin embargo, las reglas tienen un peso especial, porque casi todo lo que pasa en el ciclo de vida del empleado pasa por ellas: el alta, los cambios de puesto, la compensación, las bajas y las alertas.
El trabajo con una regla tiene dos momentos que conviene no confundir. El primero es la creación, en Configurar reglas de negocio, donde se elige el escenario, el objeto base y se arma la lógica. El segundo es la asignación, en Gestionar configuración empresarial, donde la regla se conecta a un elemento o a un campo con un evento. Una regla creada pero no asignada no hace nada. Muchos tickets de "la regla no funciona" terminan ahí: la regla estaba bien, pero nadie la asignó, o se asignó con un evento que no corresponde.
A lo largo del curso ya aparecieron varias. En Essentials U4 vimos una regla simple para disparar un flujo. En la U5 usamos reglas para derivar el motivo de evento, para generar la alerta del período de prueba y para filtrar el historial de puestos interno. En la U6 las ordenamos desde la base y agregamos las de Best Run Argentina: AR_CC por departamento, AR_Modalidad por defecto, AR_Validar horas semanales, AR_Derivar motivo de evento, AR_Disparar flujo de promoción, AR_ID de usuario y AR_Grupo de pago por grado.
En un proyecto real, las reglas se acumulan rápido. Un cliente con varios países puede tener cientos, y con el tiempo nadie recuerda por qué existe cada una. Por eso, además de saber armarlas, un consultor tiene que dejarlas documentadas: un nombre que diga qué hacen, una descripción que diga dónde están asignadas y con qué evento, y una convención que permita reconocer a qué país o proceso pertenecen. En el caso del curso usamos el prefijo AR_ para todo lo de la filial, y la descripción de cada regla indica su asignación.
Una última idea que conviene tener presente: las reglas corren con los datos que tienen en ese momento. Si una regla anterior cambió un valor, la siguiente ve el valor cambiado. Ese encadenamiento es útil, pero también es la fuente de muchos comportamientos inesperados, y es lo que las herramientas de control de la L5 y la L6 ayudan a entender.
