| Both sides previous revision
Previous revision
|
|
devel:documentation:hr_processes [2019/10/07 07:59]
doischert |
devel:documentation:hr_processes [2019/10/07 08:18] (current)
doischert |
| ====== HR Processes ====== | ====== HR Processes ====== |
| |
| Process of identity lifecycle (ILP), in other words HR process, manages the user identity in CzechIdM during its existence watching the changes of its contracted positions. For example, there is a process "End of contract" that watches the beginning and the end of user's contracted position. If the contracted position ends, the process removes all user roles from it. | The process of identity lifecycle (ILP), in other words HR process, manages the user identity in CzechIdM during its existence based on the changes of its contracted positions. For example, there is a process "End of contract" that watches the beginning and the end of user's contracted position. If the contracted position ends, the process removes all user roles from it. |
| |
| This article assumes that the identity already exists in IdM, whether [[tutorial:adm:new_identity|created manually]] or [[devel:documentation:synchronization:dev:synchronization|synchronized from a system]], and focuses only on true HR processes, i. e., contract changes. | This article assumes that the identity already exists in CzechIdM, whether [[tutorial:adm:new_identity|created manually]] or [[devel:documentation:synchronization:dev:synchronization|synchronized from a system]], and focuses only on actual HR processes, i. e., contract changes. |
| |
| ===== Standard ILPs ===== | ===== Standard ILPs ===== |
| |
| Following text describes the core set of HR processes managed by CzechIdM. All processes are managed based on the contracted position attributes. These are the attributes that the processes watch for a change: | The following text describes the core set of HR processes managed by CzechIdM. All processes are managed based on the contract's attributes. These are the attributes that the processes watch for a change: |
| |
| * Valid from | * Valid from |
| * Work position | * Work position |
| |
| Valid from and valid to attributes defines contracted position **validity**, i.e. The contracted position **is valid** if and only if the current date is between or equal to **valid from** and **valid to**. We use the term contracted position's **validity** in following text. | Valid from and valid till attributes defines contracted position **validity**, i.e. The contracted position **is valid** if and only if the current date is between or equal to **valid from** and **valid till**. We use the term contracted position's **validity** in following text. |
| |
| If you want to use ILPs, you must synchronize contracted positions from source system with attributes mentioned above or manage them manually. | If you want to use ILPs, you must synchronize contracted positions from a source system with attributes mentioned above or manage them manually. |
| |
| <note important>Since 7.6 version has been released, the following processes are managed by events, i. e., immediately after the Watched attribute is changed, Effect take place. For example, when the administrator changes the employee's last Contract end date to past, the employee's roles are removed and the identity is blocked. There is no need to wait for the Scheduled task to run. Scheduled tasks are still available though to be to upgraded from older versions. </note> | <note important>Since the version 7.6 has been released, the following processes are managed by events, i. e., immediately after the Watched attribute is changed, the Effect take place. For example, when the administrator changes the employee's last Contract end date to past, the employee's roles are removed and the identity is blocked. There is no need to wait for the Scheduled task to run. Scheduled tasks are still available though to be used for processing large amount of data (e. g., after synchronization). </note> |
| |
| ==== Enable contract ==== | ==== Enable contract ==== |
| |
| * **Watched entity**: contracted position, | * **Watched entity**: contracted position, |
| * **Watched attributes**: valid from, valid to, enabled, | * **Watched attributes**: valid from, valid till, enabled, |
| * **Process trigger**: The identity's contracted position becomes valid and enabled, | * **Process trigger**: The identity's contracted position becomes valid and enabled, |
| * **Effect**: the identity that belong to the changed contracted position is enabled. | * **Effect**: the identity that belong to the changed contracted position is enabled. |
| Upon creation, the identity is in the state Created. It can be enabled only if the current date is between the contract's attributes 'Valid from' and 'Valid till'. If 'Valid from' and 'Valid till' are not specified, the contract is automatically considered valid. If 'Valid till' is not specified but 'Valid from' is in the past the contract is considered valid as well. If 'Valid from' is in the future, the contract is invalid but once the date specified in 'Valid from' comes, the state changes to valid. | Upon creation, the identity is in the state Created. It can be enabled only if the current date is between the contract's attributes 'Valid from' and 'Valid till'. If 'Valid from' and 'Valid till' are not specified, the contract is automatically considered valid. If 'Valid till' is not specified but 'Valid from' is in the past the contract is considered valid as well. If 'Valid from' is in the future, the contract is invalid but once the date specified in 'Valid from' comes, the state changes to valid. |
| |
| The process is a stateful task, therefore, the contracted position is processed only once until it is set not valid again. | The process is a stateful task, therefore, the contracted position is processed only once and then when it is set invalid again. |
| |
| ==== End of contract ==== | ==== End of contract ==== |
| If the 'Valid till' comes, the contract becomes invalid. This means that all assigned role of the contract are removed. If this was the last contract of the identity, the identity's state changes to 'Left'. | If the 'Valid till' comes, the contract becomes invalid. This means that all assigned role of the contract are removed. If this was the last contract of the identity, the identity's state changes to 'Left'. |
| |
| The process is a stateful task, therefore, the contracted position is processed only once until it is set valid again. | The process is a stateful task, therefore, the contracted position is processed only once and then when it is set valid again. |
| |
| ==== Contract exclusion ==== | ==== Contract exclusion ==== |
| Once the contract stops being excluded (e. g., the parental leave ends), the identity's state will change to active again and this change will be provisioned to connected systems, i. e., all accounts will be activated again. | Once the contract stops being excluded (e. g., the parental leave ends), the identity's state will change to active again and this change will be provisioned to connected systems, i. e., all accounts will be activated again. |
| |
| The process is a stateful task, therefore, the contract is processed only once until it is enabled again. End of contracted position exclusion is managed by **Enabled contract** process. | The process is a stateful task, therefore, the contract is processed only once and then when it is enabled again. End of contracted position exclusion is managed by the **Enable contract** process. |
| |
| ==== Work position assignment/change/removal ==== | ==== Work position assignment/change/removal ==== |