Self-Service: Request Access Rights
Self-Service: Request Access Rights
Self-Service: Request Access Rights
This use case is part of access right management use cases and in this article is described use case for requesting access rights from Self-Service.
It is important to separate access right requests from automation, which grants access rights automatically based on users personal and employment related information, when access right requests are made by end-users and usually request requires approval before provisioning.

When the use case is delivered, it contains three (3) possibilities to request access rights,
- Request access rights to myself (available to all end-users)
- Request access rights to my subordinate (available to managers)
- Request access rights to external users (available to managers)
Please notice, that IGA packages (Starter, Growth, Enterprise) has affect to the use case and relating functionalities such as user lifecycle management, toxic combinations, etc.
Use case in nutshell
End-user is logged into Self-Service
- Manager or user requests access rights from Self-Service
- Approver(s) approves request(s) in the Self-Service
- Access right(s) are automatically added to user or manual request is sent for adding the access right(s) manually
- Manager and user can see their own request history from Self-Service
- IGA Admin can manage access right information, request catalog and visibility for the access rights which are published into Self-Service from IGA solution.
- All auditing details are available for reporting (by using ready-made reports and dashboards or IGA admins can easily create own reports)
Full Use Case Description
Use Case Description
This use case is part of all IGA packages, and customer can decide when it is published to end-users
| Description | |
Overview |
This use case describes how end-user can request additional entitlements or business roles and what are outcomes for that request. User and manager can request additional entitlements or business roles for him/herself (request access rights). Manager can request additional entitlements or business roles for subordinate or for external subordinate (request access rights for my subordinates or request access rights for external users) |
Operators |
IGA solution |
Prerequisites |
Entitlements (access rights) and/or business roles need to be published to Self-Service. Manager - subordinate relations needs to be existing in IGA solution. |
Result |
The request is appropriately approved and send to provisioning process. All audit details are saved and can be reported. User and manager can follow up request status in Self-Service. |
Operating chain |
|
Self-Service |
Request access rights for myself If user lifecycle management add-on is included, request access right service can also be shown in "onboard internal users" and "onboard external users" bundle orders. |
| Self-Service reporting |
User can see own active access rights Manager can see own and subordinates active access rights User can see own open requests Manager can see own open requests Manager can see request waiting for approval Approver can see request waiting for approval Approver can see own approval history User can see own request history Manager can see own request and approval history |
| IGA administration tasks & reporting | IGA administrations tasks can be found from here. |
Messages |
User can see own open requests and their status, and request history from Self-Service, so it is highly recommended that email notifications are added to IGA solution in further development phase and try to guide users to portal at the first phase. Email notifications can be also added by IGA Admin. |
Delivery Instructions
Configuration Instructions
In this chapter are described configuration instructions, please check also following chapter system- and approval testing,
Relations to other use cases,
Manage entitlements - use case for IGA admins to be able to define different settings to single access right group (entitlement), such as approvers, visibility in Self-Service, description etc.
Manage request catalog - users to be able request access rights from Self-Service, IGA admin needs to build categories for the request catalog.
Approval - use case for different approval types.
Provisioning - is used when group memberships are created.
IGA administration - use case for IGA admins to be able to get notifications in case there is a need for manual actions.

Configuration instructions for Self-Service
- Login as a admin to Self-Service admin UI
- Publish service "Request Access Right for Subordinate" in Self-Service
- Publish service "Request Access Rights for External Users" in Self-Service
- Publish service "Request Access Rights for Myself" in Self-Service
Configuration instruction for connector
- Login as IGA configuration admin to IGA solution
- From connector management, select correct directory where provisioning is made
- Configure connector settings for correct directory and test connection
- Configure related event-based task called “[Directory] IGA Service request: Verify, Add, Remove”
- Define user and group filters and settings,
- No need to change user identity mappings
- Configure related event-based task called “[Directory] IGA Access Right Record: Remove or Add group”
- Define user and group filters and settings
- No need to change user identity mappings
Configuration instructions for workflows
- Go to IGA Access right record and workflow called “1.0 Access right ending”
- Publish the workflow
- Go to IGA Access right record and workflow called “2.0 Add or remove group membership”
- Publish the workflow
- Go to IGA service request and workflow called “2.0 Manager Adds Rights to Others Workflow”
- Publish the workflow
- Go to IGA service request and workflow called "2.3 Users Add Rights for Themselves"
- Publish the workflow
- Move to testing instructions.
System and Approval Testing Instructions
Testing request access right use case happens from Self-Service, but results are validated also from IGA solution, and it is recommended to test also related IGA administration daily actions by creating on purpose test cases which generates IGA administration tasks (failed provisionings etc.).
Preparation tasks
- Ensure that you have users with manager-subordinate relationship
- If external users own request service is used, ensure that manager has external users as subordinate
- All users need to have active work periods
- Create request catalog categories
- Publish entitlements and business roles to request catalogs
Testing instructions, Self-Service
- Login as user to Self-Service
- Request access rights for your self
- One entitlement
- Several entitlements at the same time
- Business roles
- Manual and automatic type of entitlements
- Validate that,
- Info text's, tool tips, descriptions etc. are correct
- Request status is updated according to request progress in the front page
- Request is visible in My Request view
- Request is visible in My Things (if active access rights are listed there)
- Request access rights for your self
- Login as approver to Self-Service
- Make approval decision
- Approve the request
- Decline the request
- Validate that,
- Approval information is showed correctly
- The request is visible in Approvals view
- Make approval decision
- Login as manager to Self-Service
- Request access rights to subordinate
- One entitlement
- Several entitlements at the same time
- Business roles
- Manual and automatic type of entitlements
- Validate from Self-Service,
- Info text's, tool tips, descriptions etc. are correct
- Request status is updated according to request progress in the front page
- Request is visible in My Employees (if active access rights are listed there)
- Request access rights to subordinate
Testing instructions, IGA solution
- Login as IGA admin to IGA solution
- Validate that
- IGA service request is created correctly
- IGA access right record(s) are created correctly
- Provisioning is successful
- The entitlement and/or business role is visible in users identity storage, person, work period, account, entitlement and/or business role data cards.
- Test re-running the provisioning for failed requests
- Validate that
Table of Contents