Access Review Request

Access Review Request is where access that has come up for review is confirmed or withdrawn. Every review that SecureAI raises for a decision on access arrives here, where administrators work from a single queue. They can also review ongoing requests and see which requests are waiting on their decision. An administrator can decide whether an agent should keep the access it holds and record the reasoning behind each decision. The decision made here changes the access on the platform it came from.

What a request holds, and how it moves

A request is the record of one review. An entitlement is one piece of access, such as a role or a permission. The request lists each entitlement under review, together with the agent that holds that access. The list is fixed when the request is created, and comes from the entitlements chosen for the review, as they stood at the last successful fetch from each application. Each entitlement starts as pending, and ends as approved or revoked. The request keeps a running count of how many are approved, revoked, and still pending, along with any comments and a history of what has happened to the request.

A request is assigned to the certifier chosen for the review. It then moves through the stages of the workflow. Each stage is assigned separately, so one request can pass through more than one technician. The counts of what is awaiting review, approval, and execution follow these stage assignments. A decision on an entitlement is not carried out while the request is still being reviewed or approved. A request closes when every stage is finished, when someone cancels it, or when the time allowed runs out. If entitlements are still pending when the request closes, the campaign that raised the request decides what happens to them. Based on a technician's delegated role, they see their own requests and any others waiting on their decision.

Prerequisites

  • Log in as a Super Admin or as a help desk technician whose role includes the Access Review Request permission, such as the built-in Governance role. The Access Review Request permission covers both reviewing requests and acting on them.
  • Delegate at least one workflow role to every technician who has to act on a request. The role must match the stage they handle.
  • Create an access certification campaign and let it run at least once so that there are requests to work on.
  • Configure the mail server, if the technicians a request passes through are to be notified when it is created, reviewed, approved, executed, cancelled, or when it is about to expire.
Note:
  • You can't open a request raised for someone else. Based on the filter you pick, you see your own requests and those waiting on you.
  • Nothing about the request itself can be changed on this page. The entitlements under review, whether a comment is required, and whether several entitlements can be decided together are all set by the campaign that created the request.
  • Every run of a campaign creates its own request, and each request takes the campaign's name as its subject. Two runs therefore leave two requests with the same subject, told apart only by request ID and the time each was created.
  • The stages are fixed when the request is created. Changing the workflow on the governance assigning rule afterwards has no effect on a request that is already open.

How to review and act on a request

  1. Navigate to Governance > Access Certification > Access Review Request.
  2. Requests created by me displays the requests raised in your name. Request pending with me displays the requests waiting on you.
  3. Each view is split into Awaiting Review, Awaiting Approval, and Awaiting Execution, based on the stage a request has reached. Click any category to see the requests behind it, with Created On, Created By, Workflow Status, Request Status, and Assigned To details.
  4. To see one kind of request only, click the filter icon and select the required request.
  5. To export the requests, click Export As at the top-right corner of the page and choose the format to be exported in: PDF, XLSX, or HTML.
  6. Click a request's Request ID or Subject to open it.
  7. Under Task Details, the entitlements and access templates chosen for the review are shown as a count. Click more to see them listed, and click Cancel to go back. Total Objects shows the entitlements the request covers, with each entitlement counted once for every agent that holds it. Selected Actions is how many of those have been approved, revoked, or left pending.
  8. The entitlements under review are listed with Agent Name, Entitlement Type, Entitlement Value, Access Template, and Instance. Actions displays the decision on each.
  9. In a request that is waiting on you, click Approve beside an entitlement to keep the access, or Revoke to remove it. For a model, Revoke and Change puts the alternate model you pick in its place. For a service role, pick the replacement using the Select a service role drop-down menu.
  10. If the campaign requires a comment, type it in the Enter a comment field.
  11. If the campaign allows bulk certifications, click the check box beside each entitlement that gets the same decision, then click Approve or Revoke to apply that decision to all of them at once.
  12. If the workflow has an execution stage, click Execute to carry out the decisions. If the campaign allows this only once every entitlement has been approved or revoked, the request cannot be executed while any of them still reads Pending.
  13. To export the entitlements under review, click the export icon above them and choose the format to export in: CSV, PDF, XLSX, or HTML.
  14. The Comments and Activities tabs appear below the entitlements, and both cover the request as a whole rather than one entitlement. To comment, navigate to the Comments tab, type the comment, and click Post Comment. Navigate to the Activities tab to view the history of the request.
  15. The request's own details are listed alongside the entitlements. Workflow Status and Request Status show how far the request has progressed, and Expiration shows how much time is left to act.
  16. Click View Workflow Progress to view the stages the request goes through and the one it has reached.
  17. Click Cancel to withdraw a request.

Tips

  • To find out why a request is not moving, read Assigned To for the person it is waiting on, and Workflow Status for the stage they are holding it at. That person is not always the certifier the campaign named, because each stage has its own assignee.The entitlements in a request cannot be changed. If a request covers access that should not be reviewed, correct the campaign's entitlement selection, or the access template it uses. The next run then creates a request with the corrected list.