Introduction

The request process is the process of requesting accounts, entitlements, and roles within the IDM. After process approval, users’ access gets provisioned on the target systems or deviceFollowing are the main features of this process

Self Request: Here, the user can do the following:
1. Request self-access for Accounts, Entitlement, and Roles
2. Request to remove self-access for Accounts, Entitlement, and Roles
3. Request to add a Delegate (To perform tasks on behalf of the user)
4. Request to add a Proxy (To manage access requests, certification tasks, and completion of approval requests)
Request for Others:
1. Request access for Accounts, Entitlement, and Roles for other users
2. Request to remove access for Accounts, Entitlement, and Roles
Ability to save and resume work in progress
1. Requests made for access (Both Self & Others) can be:
  1. Drafted - Can be used later to submit
  2. Withdrawn - Closed by the user before approval is made
  3. Closed - Closed by the IDM Administrator or 'UserHelpDesk'

Request Process Use cases:

Catalog Search

Use Case	Catalog Search
Brief Description	The process of searching for accounts, entitlements, and roles in IDM to request
Actors	IDM Requester
Trigger Events	Catalog item is being finalized/ selected for request from IDM
Preconditions	Active user in IDM Catalog item is available in IDM User has permission to view the catalog item in IDM
Post-Conditions	Success Catalog item is finalized/ selected for request from IDM Request is Drafted Fail Could not view catalog items Could not select catalog items
Basic Flow	The basic flow for the catalog is explained as below: User clicks on create request link to request for a catalog item from Dashboard or Left Menu Panel IDM searches for the catalog item through the following: Wildcard search using * or % only (To view complete list) Text Search (For a string search) Combination of Wildcard and Text Search (Prefix and Suffix search using a wildcard) IDM displays the search result The user selects the relevant catalog item and adds to the cart User clicks on View Cart to view the list of items in the cart User observes: Checkout button to move to the next section Save as Draft button to save for the future change in request before submitting

Modify Draft Request

Use Case	Modify Draft Request
Brief Description	The process of changing a saved request for access to accounts, entitlements, and roles in IDM.
Actors	IDM Requester
Trigger Events	Catalog item is drafted from IDM
Preconditions	Active user in IDM Catalog item is available in IDM Draft Request was made & saved by the user
Post-Conditions	Success Request is re-saved Draft Request is Submitted Fail Items do not match from the selected and saved items Unable to view items in Catalog Search Unable to add more items to cart Unable to re-save once the draft is opened Unable to submit the request
Basic Flow	The basic flow for modify draft request process is explained as follows: User searches for Draft Requests from the Request Track page User opens Draft created earlier The user observes a cart with selected access requests saved User clicks on adding more item to cart User searches for an item from the catalog search The user adds more items to the cart The user removes an item from the cart saved earlier The user observes the 'Check out' and 'Save as draft' button The user checks out by clicking on the 'Check out' button The user observes the 'Request for Self/Other' option User searches for another user from multiple search criteria The user adds another user for the requested item User remove previously added user from the selected item User enter the required details and add justification The user observes the 'Ready to Submit' and 'Save as draft' button The user clicks on the "Ready to submit" button for form validation. Users submit the request IDM creates a unique Request ID The user receives access to catalog item and desired roles, accounts, and entitlements post-approval and validation process

Withdraw Request

Use Case	Withdraw Request
Brief Description	The process of withdrawing submitted access request for accounts, entitlements, and roles in IDM
Actors	IDM Requester
Trigger Events	The request is submitted in IDM
Preconditions	Active user in IDM The request is submitted in IDM
Post-Conditions	Success The submitted request is withdrawn by the requester Beneficiary unable to withdraw request Fail The request is withdrawn by the beneficiary Request withdrawn for request with status as Completed, Expired, Pending Fulfillment status Requester and Beneficiary receives the notification of Withdraw Request
Basic Flow	The basic flow for the withdraw request process is explained as follows: User searches for Submitted Request The user observes Request Status as Pending Approval User clicks on Actions that can be performed on the Request User clicks on 'Withdraw' to withdraw the request The user enters comments/ justification on the popup for the reason of withdrawing the request The user confirms withdrawal of request by clicking on 'Confirm'

Closing Request

Use Case	Closing Request
Brief Description	The process of closing a submitted access request for accounts, entitlements, and roles in IDM
Actors	IDM Requester IDM Administrator or UserHelpDesk
Trigger Events	The request is submitted in IDM
Preconditions	Active user in IDM The request is submitted in IDM
Post-Conditions	Success The submitted request is closed Status for request changed to Closed Fail Beneficiary able to view submitted request Request closed by beneficiary or requester Request closed for request that had status as Completed, Expired, Pending Fulfillment status
Basic Flow	The basic flow for the closing request process is explained as follows: IDM Administrator or 'UserHelpDesk' searches for Submitted Request The user observes Request Status as Pending Approval User clicks on Actions that can be performed on the Request User clicks on 'Close' to close the request The user enters comments/ justification on the popup for the reason of the closing request The user confirms the closing of the request by clicking on 'Confirm' Requester and Beneficiary receives the notification of Closed Request

Deleting Request

Process Name	Deleting Request
Brief Description	The process of deleting a request for accounts, entitlements, and roles in IDM
Actors	IDM Requester
Trigger Events	The request is submitted in IDM
Preconditions	Active user in IDM The request is submitted in IDM
Post-Conditions	Success The submitted request could not be deleted Fail Beneficiary and requester unable to view request The submitted request is deleted
Basic Flow	The basic flow for the withdraw request process is explained as follows: User searches for Submitted Request The user observes Request Status User clicks on Actions that can be performed on the Request The user observes No delete option is present for the request

Removing or revoking access request

Use Case	Removing or revoking access Request
Brief Description	The process of removing/ revoking access for accounts, entitlements, and roles in IDM
Actors	IDM Requester
Trigger Events	The request is submitted in IDM
Preconditions	Active user in IDM User has access to accounts, entitlements, and roles in IDM that needs to be revoked
Post-Conditions	Success The submitted request triggered the approval process The request ID is generated Fail Unable to submit the request
Basic Flow	The basic flow for the revoke access request process is explained as follows: User searches for an item from the My access page The user selects items for removing access (Account/Entitlements/Role) The user observes the 'Revoke/ Remove' option (Revoke for Account and Entitlement and 'Remove' for Role) Users submit the request IDM creates a unique Request ID

Proxy Request

Use Case	Proxy Request
Brief Description	The process to add a proxy to manage access requests, certification tasks, and completion of approval requests
Actors	IDM Requester Proxy-assigned user
Trigger Events	The user invokes a proxy request for a specified date
Preconditions	Active user in IDM
Post-Conditions	Success Proxy-assigned user able to perform tasks on proxy defined Start and End dates Requested user unable to perform tasks on proxy defined dates Fail Requested user able to perform tasks on proxy defined dates Proxy-assigned user able to perform tasks outside proxy defined Start and End dates Users assigned as Proxy can approve requests submitted for themselves as the user manager (approval process) Terminated users able to perform tasks on proxy defined dates
Basic Flow	The basic flow for the proxy request process is explained as follows: Flow 1: User clicks on Add Proxy The user observes the Add Proxy popup with the option to Add User, Add Manager & Start & End Date The user enters Username and dates and saves the proxy information Proxy-assigned user and requester receives mail notification for proxy dates Flow 2: Requester edits the Proxy from the 'Edit Proxy' section User changes Proxy information and dates and saves the proxy information Proxy-assigned user and requester receives mail notification for proxy dates Flow 3: Requester cancels the Proxy from the 'Cancel Proxy' section The user confirms canceling with justification provided and selects 'Confirm' Proxy-assigned user and requester receives mail notification for proxy dates

Delegate Request

Use Case	Delegate Request
Brief Description	The process of searching for accounts, entitlements, and roles in IDM to request
Actors	IDM Requestor
Trigger Events	The user invokes a delegate request
Preconditions	Active user in IDM
Post-Conditions	Success Delegated users able to perform access requests, certification tasks, and approval requests. on behalf of the user Requested user able to perform her/his functionalities Fail User's access or functionality removed once delegated within IDM Assigned delegates able to complete a user's unassigned activities on behalf of the user
Basic Flow	The basic flow for the delegate request process is explained as follows: User clicks on 'My Access' to view current accesses User clicks on 'Add Delegate' for the access that needs delegation User searches for adding delegate (other users) The user selects delegate and confirms by clicking on 'Confirm' Delegate and requester receives mail notification for access request

Request Failure Process

Use Case	Request Failure Process
Brief Description	The process when a request unable to submit for access to accounts, entitlements, and roles in IDM
Actors	IDM Requester
Trigger Events	The user invokes a submit request
Preconditions	Active user in IDM The request is submitted from the user-end through the User interface
Post-Conditions	Success Reattempted 5 times for submitting a request (after every failed attempt) Status changed to 'Request Failed' after 5th attempt Fail Status changed to 'Request Failed' before 5th attempt No re-attempts made No notification of request failure was sent to the designated support team and requester and beneficiary.
Basic Flow	The basic flow for the request failure process is explained as follows: User submits requests The system tries to submit a request and fails in 1st attempt The system tries to submit a request and fails in 2nd attempt The system tries to submit a request and fails in 3rd attempt The system tries to submit a request and fails on 4th attempt The system tries to submit a request and fails on 5th attempt Requester receives total request failure notification after 5th attempt failure

Approval Process Use Case:

Auto- Approval

Use Case	Auto Approval
Brief Description	The process when a request does not require approval by a manager or approve group in IDM
Actors	IDM Requester
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM The request is submitted by the user The request ID is generated
Post-Conditions	Success Request sent to the fulfillment process Request status is changed to provisioning Fail Request not sent for fulfillment process Request sent for Manager/ Approve group approval Request status does not change to 'Provisioning'
Basic Flow	The basic flow for the auto-approval process is explained as follows: User submits Request IDM triggers the approval process and identifies no approval needed from the manager or any approved group IDM sends the request for the fulfillment process IDM change request status to 'Provisioning' IDM sends a notification to the requester

Manager Accept Approval

Use Case	Manager Accept Approval
Brief Description	The process when a request requires approval by the manager in IDM
Actors	IDM Requester Manager
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM A request is submitted by the user The request ID is generated
Post-Conditions	Success Request sent to the fulfillment process Request status is changed to provisioning Fail Request not sent for fulfillment process Request sent for Approve group approval Request status does not change to 'Provisioning'
Basic Flow	The basic flow for the manager approval process is explained as follows: User submits Request IDM triggers the approval process and identifies manager approval needed IDM sends the request to the manager (and his delegate, or proxy, as present in the system) IDM change request status to 'Obtaining operational approval' The manager provides some comments & justification and approves the request IDM sends a notification to the requester and beneficiary IDM change request status to 'Provisioning'

Manager Reject Approval

Use Case	Manager Reject Approval
Brief Description	The process when a request requires approval by the manager in IDM
Actors	IDM Requester Manager
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM The request is submitted by the user The request ID is generated
Post-Conditions	Success Request not sent for fulfillment process Request status is changed to 'Request Rejected' Requester unable to reopen the request Fail Request sent to the fulfillment process Request sent for Approve group approval Request status does not change to 'Request Rejected'
Basic Flow	The basic flow for the manager reject process is explained as follows: User submits Request IDM triggers the approval process and identifies manager approval needed IDM sends the request to the manager (and his delegate, or proxy, as present in the system) IDM change request status to 'Obtaining operational approval' The manager provides some comments & justification and rejects the request IDM sends a notification to the requester and beneficiary IDM change request status to 'Request Rejected' Manager no longer able to view the task under Approver details

Manager Reassign Approval

Use Case	Manager Reassign Approval
Brief Description	The process when a request requires approval by the manager in IDM
Actors	IDM Requester Manager
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM The request is submitted by the user
Post-Conditions	Success Request reassigned to the new user Request status remains unchanged Fail Request sent to the fulfillment process Request sent for Approve group approval
Basic Flow	The basic flow for the manager reassign process is explained as follows: User submits Request IDM triggers the approval process and identifies manager approval needed IDM sends the request to the manager (and his delegate, or proxy, as present in the system) IDM change request status to 'Obtaining operational approval' Manager searches for another user/ group to reassign the task Manager reassigns the task to another user/ group User has chosen for reassigned task able to view the re-assigned task Delegated user acts on behalf of the manager to perform task operation and able to view the task

Role Approval

Use Case	Role Approval
Brief Description	The process when a request requires approval by the approval group in IDM
Actors	IDM Requester Role Approver
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM The request is submitted by the user The request ID is generated
Post-Conditions	Success Request sent to the fulfillment process Request status is changed to provisioning Fail Request not sent for fulfillment process Request status does not change to 'Provisioning'
Basic Flow	The basic flow for the role approval process is explained as follows: User submits Request IDM triggers the approval process and identifies role approval needed IDM sends the request to the member(s) of the approval group IDM change request status to 'Obtaining operational approval' IDM sends a notification to the requester and all member(s) of the approval group One of the members of the group provides some comments & justification and approves the request IDM change request status to 'Provisioning'

Approval Expiry & Notification

Use Case	Approval Expiry and Notification
Brief Description	The process when a request requires approval by the manager in IDM
Actors	IDM Requester Manager
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM The request is submitted by the user The request ID is generated
Post-Conditions	Success Request status is changed to 'Request Expired' Notifications sent to requester and approver Fail Request status does not change to 'Request Expired' Notifications not sent Request able to re-open the expired request
Basic Flow	The basic flow for request expiry and notifications is explained as follows: User submits Request IDM triggers the approval process and identifies auto-approval cannot be made IDM sends the request to the manager/ approve group for approval IDM change request status to 'Obtaining operational approval' IDM checks the status of request after 5 days of Request creation and finds it unchanged IDM sends a notification to the requester and approver IDM checks the status of request after 10 days of Request creation and finds it unchanged IDM sends a notification to the requester and approver IDM checks the status of request after 15 days of Request creation and finds it unchanged IDM change request status to 'Request Expired' IDM sends a notification to the requester and approver

Bulk- Approval

Use Case	Auto Approval
Brief Description	The process when a request requires approval by a manager or approve group in IDM
Actors	IDM Requester
Trigger Events	The user invokes an approval process after submitting a request
Preconditions	Active user in IDM A request is submitted by the user The request ID is generated
Post-Conditions	Success Request status is updated for all tasks Request notification is sent to all requesters Fail Request status does not change for some/ all tasks Request status update notification not sent to all Beneficiary approved some part of their own request
Basic Flow	The basic flow for the auto-approval process is explained as follows: User searches for Approval Tasks User starts multi-select option to approve multiple tasks at a time The user selects tasks that need to be claimed, approved, rejected, or submitted The user performs the task The user provides comments and justification to the bulk task performance IDM change request status IDM sends a notification to requesters

Track Request Use Case:

Track Request

Use Case	Track Request
Brief Description	The process when a request submitted can be tracked n IDM
Actors	IDM Requester
Trigger Events	The user invokes a search and display trigger for requests submitted
Preconditions	Active user in IDM A request is submitted from the user-end through the User interface
Post-Conditions	Success IDM users were able to search for and track requests in the IDH by User ID, Request ID, or both. IDM Users were able to view all requested data Search results have fields: Request ID, Item requested, an action performed, status, beneficiary, and date requested Fail IDM users were unable to search for and track requests in the IDH by using the User ID, Request ID, or both. IDM Users were unable to view all requested data Search results did not have one/multiple fields among the following: Request ID, Item requested, the action performed, status, beneficiary, and date requested
Basic Flow	The basic flow for the request failure process is explained as follows: The user clicked on the 'Search Request' page User searched request by User ID and Request ID The user used advanced search functionality and availed AND/OR function and used a combination of fields: Request ID, Application, Entitlement, Role, Requester, Beneficiary, My Direct Reports, Requests Raised by Me, Requests Raised for Me to get search result User clicks on 'Search' to view search results User vi search results with fields: Request ID, Item requested, the action performed, status, beneficiary, and date requested. The user enters the desired Request and observes in detail by clicking on the hyperlink on Request ID

The following information shall be available when tracking a request:

Request and Approval Status
Approver and last date and time of activity
Approver hierarchy and status of the request for each level of approval
Approver comments

Validation Use Case:

ECI Validation

Use Case	ECI Validation
Brief Description	The process when a request requires ECI validation in IDM
Actors	IDM HRMS LMS Requester
Trigger Events	The user invokes a validation process after submitting a request The validation process verifies LMS Record for training details of the user
Preconditions	Active user in IDM The request is submitted by the user HRMS is connected to IDM and user record is synced LMS is connected to IDM Not all IDM catalog items will go through ECI validation, only those with specific Export Control Codes. Upon receipt of an HRMS record, IDM determines if ECI Validation is required based on the ECC Code.
Post-Conditions	Success Request rejects after ECI Validation fails The request moves to another step after ECI Validation passes Fail Request Completed after ECI Validation fails Request Failed after ECI Validation passes
Basic Flow	The basic flow for the role approval process is explained as follows: User submits Request IDM triggers validation process and checks ECI indicator for requested application, role, or entitlement IDM checks the Export Control Code (ECC) in the user identity record as received in IDM from HRMS IDM finds one of the options for ECC from below: "A" = US Persons (US Citizens, Green Card Holder, Asylee) "B" = Foreign Nationals from restricted countries "C" = Foreign Nationals from un-restricted countries "D" = Special Status Consultants "BLANK" = represents low values or spaces, but any code that does not conform to any of the codes above will fit this category. IDM identifies that attributes as "B" or "C" require ECI validation, whereas "A" and "D" does not require ECI validation and "Blank" will deny access IDM identifies that ECI Validation is required LMS is invoked at request time through a web service to check the requester's qualifications to have access to ECI. IDM identifies that either user has or hasn't completed the required training. IDM identifies that ECI Validation can move to the next step if the user has completed the training in LMS IDM identifies that training has not been completed in LMS by the user IDM sends notification that provides specific instructions for the user to complete the required training in LMS IDM sends notification that the user must complete the required training before the request can be completed IDM rejects the request after sending notification

Inbox Management Use Case:

Inbox Workflow

Use Case	Inbox Workflow
Brief Description	Inbox Management is the method that users, approvers, certifiers, and fulfillers use to complete tasks assigned to them by the Access Governance System
Actors	IDM Manager/ Approver/ Task Performer
Trigger Events	The user invokes an Approve, Reject, Certify or Revoke, Claim, Remove, or Complete Task request
Preconditions	Active user in IDM
Post-Conditions	Success The Inbox lists all approval, provisioning, fulfillment, certification, and audit violation tasks assigned to the user IDM users were able to search tasks by request or task ID and to filter tasks by user and application. Task removed from Inbox after task completion Fail Task still shows in Inbox after task completion
Basic Flow	The basic flow for the request failure process is explained as follows: IDM notifies the manager or approver is notified that they have a task to perform via email notification The manager, approver, or task performer clicked on the 'Inbox' icon to enter the inbox page User searched request by User ID or Request ID User vi all the lists of approval, provisioning, fulfillment, certification, and audit violation tasks assigned to the user with fields: Request ID, Beneficiary, Assignee, Acquired By, Expiration Date, and Assigned Date. The manager, approver, or task performer completes the task (using the Approve, Reject, Certify or Revoke, Claim, Remove, or Complete button) The task is removed from the inbox by IDM.

Access Request Use Case:

Process Name	Access Request Process
Brief Description	The process of requesting accounts, entitlements, and roles in IDM.
Actors	IDM Requester Approver
Trigger Events	Catalog item is being requested from IDM
Preconditions	Active user in IDM Catalog item is available in IDM
Post-Conditions	Success The Request ID is being generated and the user has the requested catalog item Desired roles and entitlements have been provisioned to the user Fail Status of the request is being rejected If the entire process fails, need to submit the request again and will go for IDM validation and approver approves the request
Basic Flow	The basic flow for the access request process is explained in the below activity diagram User clicks on the create request to link to request for a catalog item IDM searches for the catalog item and displays the search result The user selects the relevant catalog item and adds to the cart User clicks on checkout button and then enter the required details and add justification The user clicks on the "Ready to submit" button for form validation. Users submit the request IDM creates a Request ID The request goes for ECI validation After successful validation, a request is sent for approval Approver approves the request The user receives access to catalog item and desired roles, accounts, and entitlements

Diagram

The diagram below illustrates the basic flow of the user creation process.