Reference · built on requestOperator by FibricIT & reliability

Access Review

Turns the quarterly access review into per-manager lists of grants to keep or revoke, built from your directory and HR roster.

Request accessPricing ↗

About

Access reviews fail when the reviewer gets a spreadsheet with every grant in the company. Access Review builds each manager's list from the source systems: groups, application assignments, and admin roles from Okta; group members, directory roles, and sign-in records from Microsoft Entra ID; and the roster from Workday, BambooHR, or Rippling with each worker's manager, department, and status. It compares every grant to the worker's current role, flags grants that outlived a transfer or that no one has used, and pairs each with the sign-in evidence.

Each manager receives only their team's grants, with a proposed decision per row. What they approve becomes a group removal or an app unassignment through the identity connector. What they keep is recorded with their name and the date. The campaign closes with a complete ledger.

This is a reference listing. It documents what Fibric would read from Access Review and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Groups of type OKTA_GROUP, APP_GROUP, and BUILT_IN with their members, and application user assignments with scope USER or GROUP and lastSync
  • Microsoft Entra ID group members and owners, directoryRole members, and oAuth2PermissionGrant records through Microsoft Graph
  • Sign-in records from /auditLogs/signIns and user.session.start events in the Okta System Log, as evidence that a grant is used
  • Workers with manager, supervisory organization, and job profile from Workday, employees changed since a timestamp from BambooHR, or worker changes from Rippling
  • Access review schedule definitions, instances, and decision items where your tenant already runs Entra access reviews
  • Existing review tickets in Jira, so an open decision is not asked twice

Proposed actions

  • Target capability: propose a per-manager review packet, one row per grant, with a keep or revoke recommendation and the last sign-in beside it
  • Target capability: propose Unassign a user from a group through the Okta Groups API for each revocation a manager approves
  • Target capability: propose removing a group member or a directory role assignment through Microsoft Graph for each approved revocation
  • Target capability: propose recording decisions on an accessReviewInstance through batchRecordDecisions when Entra access reviews are in use
  • Target capability: propose a Jira issue for grants whose owner cannot be found in the roster, assigned to the application owner

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Close out a transfer that kept old access

    Workday shows a worker moved to a new supervisory organization. Their Okta APP_GROUP membership for the old team's finance app is still active and unused for the period. The manager sees one row, approves, and the group unassignment is applied.

    With Workday, Okta

  • Review directory roles with sign-in evidence

    Each Entra directoryRole member is listed with their last interactive sign-in from /auditLogs/signIns. Role holders with no sign-in in the window are proposed for removal to the role owner.

    With Microsoft Entra ID

  • Feed decisions into Entra access reviews

    Where the tenant already schedules access reviews, the operator prepares the decision items with roster context and proposes batchRecordDecisions once the manager has approved the packet.

    With Microsoft Entra ID, BambooHR

  • Ticket the orphaned grant

    A service account in Okta belongs to no one in Rippling. Access Review proposes a Jira issue to the application owner rather than a removal, and tracks it until closed.

    With Rippling, Okta, Jira

Requirements

  • Okta API scopes okta.groups.read and okta.apps.read for the review, and okta.groups.manage if approved removals are to be applied
  • Microsoft Graph application permissions Group.Read.All, RoleManagement.Read.Directory, and AuditLog.Read.All, with GroupMember.ReadWrite.All for removals
  • An HR connector that exposes each worker's manager and employment status: Workday, BambooHR, or Rippling
  • A mapping from HR worker to directory user, usually by primary email, agreed before the first campaign
  • AccessReview.ReadWrite.All and a Microsoft Entra ID Governance license if decisions are to be recorded in Entra access reviews
Authentication
Access Review signs in to nothing. Directory reads and approved removals run through the Okta and Microsoft Entra ID connectors, roster reads through your HR connector, and tickets through Jira, each under its own scopes.

Limits

  • Sign-in evidence is bounded by retention: 30 days for Entra ID P1 or P2 sign-ins and 90 days for the Okta System Log.
  • A grant inherited through a nested group or a dynamic rule cannot be removed row by row; the packet names the rule instead.
  • Workers missing from the roster mapping are listed for a human, not decided by the operator.
  • Removals happen only after a manager approves them and only through the identity connector. The operator never disables an account.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Access Review ↗

Questions and answers

What does a manager actually approve?
A short list: their own reports' grants, each with a keep or revoke recommendation, the reason, and the last sign-in. They approve rows one at a time or all at once. Only approved revoke rows are applied, and only through the directory connector.
What is recorded when the campaign ends?
For every grant reviewed: the reviewer, the decision, the timestamp, the evidence shown, and, for removals, the API call that applied it and how to reinstate it. Grants left undecided are listed as such, never assumed kept.
Does it remove access without a decision?
No. An undecided row stays as it is. Removals need an explicit approval from the manager or role owner, and even then the operator removes group or app membership only. Deactivating or suspending a user is out of scope here.
Ask about Access Review

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy