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

  1. 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)
  2. Request for Others
    1. Request access for Accounts, Entitlement, and Roles for other users
    2. Request to remove access for Accounts, Entitlement, and Roles
  3. 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionThe 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 DescriptionInbox 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 DescriptionThe 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.