This article will focus on the end user experience available within Fischer's Self-Service Portal as it relates to requesting access to resources. There are multiple administrative configurations that culminate in what is displayed to each distinct Identity when they authenticate. We will try to call out each administrative option that should be configured or that is required to be configured in order for the access request feature to be populated as seen below.
| View Requests | |||||||||||||||||||||||||||||
|
This tab provides requestors and beneficiaries with the ability to view any request that has been submitted by the end user themselves, or by an authorized entity submitting a request on behalf of the beneficiary. If the authenticated Identity sees requests listed in this view, they are able to drill down into the request to view more details of the request. The screenshot below will show you what an expanded view of a request looks like using Fischer's default color palette and nomenclature.
|
|||||||||||||||||||||||||||||
| Request Access | |||||||||||||||||||||||||||||
|
The request access tab provides authenticated users with the ability to submit requests for access to resources they may not directly qualify for. Users are able to search for the resource they would like to request. Any resource can be made available for request or IGA Administrators can limit what is requestable from what is automatically provisioned by Fischer's RBAC provisioning engine. Users have the ability to submit a bulk request as seen in the screenshot below. This is a more efficient approach to submitting requests for processing as it does not force the end user to submit individual requests for each resource they are requesting.
A very important concept to understand is the feature provided by Fischer to allow routing each individual resource through its defined workflow / authorization process. You'll see in the screenshot below that some of the requested resources require an approval, while some do not. This showcases Fischer's ability to parse the bulk request and ensure that each requested resource is processed according to the defined business process which may include layers of approvals prior to granting access to the request beneficiary. Furthermore, Fischer will release an individual resource once it has been acted upon, even if it is encapsulated within a bulk request. This provides for ultimate flexibility for the approval authority and maximum efficiency from a business process point of view. If the approval authority has a significant amount of requests in their approval queue, they can address the high priority items to ensure access is granted to the beneficiary and come back later to complete the approval process for the lower priority items. This is important because the approval authority does not need to approve all resources within a request at once in order to push the process forward, rather they can approve them individually and push the individual resources forward for further approval and ultimately fulfillment of the request. |
|||||||||||||||||||||||||||||
| Change Access | |||||||||||||||||||||||||||||
|
The change access tab provides authenticated users with the ability to modify their own access OBOs to modify access for someone else. There are multiple features embedded into this self-service interface. Step 1 and Step 2 are both active when an authorized user access the tab. This is because these two steps are tied together.
|
