When a user apply for a change on his roles set, the role change request is created. CzechIdM contains the standard approval process, which ensures approving of this request in the following steps:

• Helpdesk – the whole request is approved by holders of the role designated for helpdesk department representatives.
• User's manager – approved by managers (e.g. superordinates or guarantees) of the user for whom the role is requested. Managers are not defined by a role as in the previous steps but they are calculated by all user’s contracted positions. Any manager can approve. In applications where the approval of specific managers according to individual contracted position is needed, we recommend disabling this step in configuration and set approval by managers to be operated by the criticality of roles - see the next step.
• Managers of users – the whole request is approved by holders of the role designated for administers of user identities in CzechIdM.
• Roles Criticality – The whole request disintegrates in this step. Every role which the request was composed of is now approved individually. The way of approving of each role is determined by the settings of each one. More specifically, the attribute Criticality is set for each role. Only after of all individual roles assignment is resolved (approved/denied) does the process continue into the following step.
• Security – The request formed again by all the roles approved in the previous step is now approved by the holders of the role designated to Security department. If a role has been denied in the previous step, it is not present in the request in this step.

In steps 1, 2, 3, and 5, the request is approved as whole; i.e. all roles approved in the previous steps proceed into the next round of approval. In the approval rounds 1, 2, and 3, the realizator can return the request for a revision, deny it, or approve it. If the approving agent returns or denies the request, the requesting agent is notified about it.

After the request has been successfully approved in last round, a notification is generated which show the resulting state of the request, i.e. which roles have been approved and which not.

Approval of individual roles which were requested within the main process is now realized in the subprocesses. This approval is done asynchronously for all roles. The main process is resumed after finishing the last subprocess (be its denial or approval).

• Changing users' roles manually in GUI
• Configuring standard role change approval process
• Role criticality levels configuration
• Configuring notification for user role change process

• Role assignment approval

• Changing users' roles