You are viewing the documentation for an outdated or unreleased devel version.
This page is also available in versions: 7.7, 7.8, 8.0, 8.1, 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.7 (current), devel

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
devel:documentation:hr_processes [2017/12/11 16:14]
poulm links
devel:documentation:hr_processes [2019/10/07 08:18] (current)
doischert
Line 3: Line 3:
 ====== 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 ​on its contracted positions. For example there is a process "End of contract"​ that watches the beginning and end of the user 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 processmanages the user identity in CzechIdM during its existence ​based on the changes ​of its contracted positions. For examplethere 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 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 ​solved ​by CzechIdM. All processes are managed based on the contracted position ​attributes. ​There are following ​attributes that the processes ​watches ​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
-  * Valid to+  * Valid till
   * Enabled   * Enabled
-  * Position+  * Work position
  
-Valid from and valid to attributes defines contracted position **validity**,​ i.e. The contracted position **is valid** if and only if current date is between or equal **valid from** and **valid ​to**. We use the term contracted position **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 source system with attributes mentioned above or manage them manually.
  
-<note important>​Since 7.6 version ​has been released, following processes are managed by eventsi.e immediately after the Watched attribute is changed, Effect take place. ​e.g. when administrator ​change ​the employee'​s last Contract end date to past, roles are removed and identity is blocked. There is no need to wait for Scheduled task run. Scheduled ​task are still available though to be to upgrade from older versions. </​note>​+<note important>​Since ​the version ​7.6 has been released, ​the following processes are managed by eventsi. 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>​
  
-==== Enabled ​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**: identity that belong to the changed contracted position is enabled.+  * **Effect**: ​the identity that belong to the changed contracted position is enabled.
  
-The process is a stateful task, therefore the contracted position is processed only once until it is set not valid again.+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, thereforethe contracted position is processed only once and then when it is set invalid ​again.
  
 ==== End of contract ==== ==== End of contract ====
  
   * **Watched entity**: contracted position,   * **Watched entity**: contracted position,
-  * **Watched attributes**:​ valid from, valid to+  * **Watched attributes**:​ valid from, valid till
-  * **Process trigger**: The identity'​s contracted position becomes ​not valid+  * **Process trigger**: The identity'​s contracted position becomes ​invalid
-  * **Effect**: All manually added roles are removed from ended contract. Additionally if the ended contract was the last valid contract of the identity, the identity itself is disabled.+  * **Effect**: All assigned ​roles are removed from the ended contract. Additionallyif the ended contract was the last valid contract of the identity, the identity itself is disabled.
  
-The process is a stateful task, therefore the contracted position is processed only once until it is set valid again.+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, thereforethe contracted position is processed only once and then when it is set valid again.
  
 ==== Contract exclusion ==== ==== Contract exclusion ====
  
   * **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 not enabled   * **Process trigger**: The identity'​s contracted position becomes valid and not enabled
   * **Effect**: If the processed contract was the last valid contracted position of the identity, the whole identity is disabled. No roles are removed by the process.   * **Effect**: If the processed contract was the last valid contracted position of the identity, the whole identity is disabled. No roles are removed by the process.
  
-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.+Contract exclusion is a process used when the contract is temporarily "​stopped",​ i. e., the user will not be at work for some time. Typically, this is used to represent parental leave. When a contract becomes excluded, the state changes to '​inactive'​. No roles are removed from the contract but identity'​s state will be provisioned to connected systems (if the systems support disabling users and it is configured in IdM).  
 + 
 +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, thereforethe 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 ====
-In fact this is not full-blooded identity lifecycle process, because it is not managed by any special long running task, workflow or by other means. It just uses standard CzechIdM feature - [[devel:​adm:​roles#​automatic_roles|automatic roles]]. But since those processes are often looked on HR process from the business point of view, we describe them here.+In fact this is not full-blooded identity lifecycle process, because it is not managed by any special long running task, workflow or by other means. It just uses standard CzechIdM feature - [[devel:​adm:​roles#​automatic_roles|automatic roles]]. But since those processes are often understood as HR process from the business point of view, we describe them here.
  
   * **Watched entity**: contracted position,   * **Watched entity**: contracted position,
-  * **Watched attributes**:​ position+  * **Watched attributes**: ​work position
   * **Process trigger**: The identity'​s contracted position is placed into/​removed from organization structure (Tree structure).   * **Process trigger**: The identity'​s contracted position is placed into/​removed from organization structure (Tree structure).
   * **Effect**: Automatic roles defined on the Tree structure are assigned in case of placing the contracted position there or removed in case of removing the contracted position from the structure. Automatic roles are not passed for role a assignment approval, they are assigned immediately.   * **Effect**: Automatic roles defined on the Tree structure are assigned in case of placing the contracted position there or removed in case of removing the contracted position from the structure. Automatic roles are not passed for role a assignment approval, they are assigned immediately.
  
-If the contract is not valid yet, all automatic roles are assigned anyway, but each role's assignment validity date (do not mistaken ​with role validity) is tied to the contracts ​validity. In other words the effect of the role e.g. the account creation ​on managed system is done the same day the contracted position begins not sooner.+If the contract is not valid yet, all automatic roles are assigned anyway, but each role's assignment validity date (do not mistake it with role validity) is tied to the contract'​s ​validity. In other wordsthe effect of the role (e.g. the account creation ​in a managed systemis done the same day the contracted position beginsnot sooner
 +If the contract'​s work position changes, the automatically assigned role are removed (unless they are also set for the new work position) and the roles defined for the new work position are assigned