Source: https://manu-tests-all-orgs.docs-staging.pageloop.ai/product/identity-access/access-management/setting-up-agentic-access-provisioning

# Setting up agentic access provisioning

Agentic access provisioning delivers the right app access to the right employees at the right time — with minimal manual effort from IT. Define the essentials once (your applications, their entitlements, and the access policies that govern them) and Atom takes over: interpreting each request, evaluating eligibility, managing approvals, and provisioning access accordingly.

This guide covers end-to-end configuration. For the concepts behind it, see the **[Access management overview](/docs/10-access-management/overview)**. For time-bound access, see **[Just-in-Time access management](/docs/10-access-management/just-in-time-access-management)**.

## The four building blocks

Everything in agentic provisioning is built from four pieces, and you set them up in this order:

- **Applications** — the tools and systems you provide, such as Salesforce, HubSpot, ChatGPT, or Cursor. Auto-populated from your IdP, or added manually.
- **Access policies** — the rules mapping _which users_ get _which access_ to an app, and whether it needs approval.
- **Entitlements** — the specific level of access within an app, like _View accounts_, _Edit opportunities_, or _Read-only_.
- **Provisioning rules** — ownership and conflict handling for when a user qualifies for more than one policy.

## Configuring application access

### 1. Manage your applications

1. **Open the Applications page**

   Go to **Settings** in the left navbar and click **Applications** under **Access management**.
2. **Let your IdP populate it**

   If you've integrated an identity provider like Okta or Entra, this page fills automatically with your apps.
3. **Add anything missing**

   Click **Add** to create an app manually — give it a name, assign an app owner, and upload a logo.

Once an application exists, configure it using its **Access policies**, **Entitlements**, **Users**, and **Settings** tabs.

### 2. Create access policies

Access policies decide which users get access to an application. You can create multiple policies per app to cover different teams and roles. Say your organization uses **Salesforce**:

| Team      | Entitlement they need | Approval          |
| --------- | --------------------- | ----------------- |
| Sales     | Standard User         | Pre-approved      |
| Finance   | Marketplace Viewer    | Approval required |
| Marketing | Read-only             | Reporting Manager |

Instead of managing this by hand, create three policies — each mapping a segment to the entitlements it needs. When a user requests access through Atom, the correct policy applies automatically.

Before building policies from scratch, review the AI-generated suggestions Atomicwork surfaces from your existing access grants in Okta, Azure AD, or Microsoft Intune. Review them in one consolidated view, edit or discard individually, and publish the ones that fit. Suggestions refresh every 24 hours.

To create a policy, open the app's **Access policies** tab and click **Add**:

1. **Define the segment**

   Choose which users the policy applies to.
2. **Set the approval requirement**

   Pick pre-approved or approval-required (described below).
3. **Require business justification (optional)**

   Prompt users for a reason when they request access — it's logged automatically. Ask employees to be specific, since vague requests may fail validation.
4. **Choose entitlements and duration**

   Select the entitlements for this policy and a duration. New policies default to time-bound access; permanent access must be set explicitly.
5. **Publish**

   The policy becomes available for employee access requests.

The approval requirement has two modes. **Pre-approved** gives users access without an approval workflow — best for low-risk, broadly-needed entitlements. **Approval required** grants access only after review by designated approvers, which you set by choosing an approval policy: the app owner, org admins, reporting manager, or a custom policy. For example, Salesforce Read-only for Marketing might require the reporting manager's approval.

### 3. Define entitlements

Entitlements describe the specific level or type of access within an app. A Salesforce app might expose:

| Entitlement        | What it allows                             |
| ------------------ | ------------------------------------------ |
| View accounts      | View account records                       |
| Edit accounts      | Create or update account records           |
| View opportunities | View opportunity records                   |
| Export reports     | Export report data                         |
| Manage dashboards  | Create and modify dashboards               |
| Modify all data    | Full administrative control across objects |

For the Marketing team, the Read-only policy would bundle _View accounts_, _View opportunities_, and _Export reports_.

To add an entitlement, open the app's **Entitlements** tab and click **Add**:

1. **Name and describe it**

   Give it a clear name and a description of what it allows a user to do, then click **Next**.
2. **Choose the provisioning method**

   Decide how access is granted: add the user to an **Okta group**, add them to an **Entra group** (via Azure AD), or **create a service request** for an agent to fulfil manually.
3. **Configure the service request (if used)**

   If provisioning via a service request, select the target workspace and use **Add a question** to collect any details upfront.
4. **Save**

   The entitlement becomes available for policies and employee access requests.

This lets you automate provisioning where possible while still supporting apps that need manual steps.

### 4. Set provisioning rules

Open the app's **Settings** tab to manage ownership and resolve overlaps:

1. **Set policy conflict handling**

   Choose which policy wins when a user qualifies for several: the highest-severity policy, the most recently created one, or the one targeting the most specific user segment.
2. **Enable Self-service with Atom**

   So Atom applies your configured policies during conversational access requests.
3. **Update**

   Save your changes to the application.

## Understanding grants and auditing

Every access grant — automated or manual — is logged for compliance. The **Users** tab shows who currently has access and how they got it: which entitlement, their status, when it was last granted, and which team or workspace provisioned it. [Audit logs](https://support.atomicwork.com/en/articles/12284156-audit-logs) additionally capture changes to applications, entitlements, policies, and approval policies, giving you full transparency for access reviews.

## Requesting and managing access with Atom

Once configuration is complete, employees handle access conversationally, and Atom uses the policy logic you've defined so access stays consistent and governed. A few examples of what that looks like:

- _"Can I get access to Salesforce Marketplace?"_ — Atom reviews the policies, confirms eligibility, checks for approvals, and provisions using the defined method.
- _"What access do I have in HubSpot?"_ — Atom lists existing entitlements and the policy context behind them.
- _"I need view-only access to Gong."_ — Atom identifies the read-only entitlement and guides the user through approval or justification steps.

If employees already have access, they can't request again or extend it until the first expiry reminder. Revoke the grant first to change an employee's access duration.

## Go deeper

- [Access management overview](/docs/10-access-management/overview)

  The big picture: how IGA works and what it delivers for employees and admins.
- [Just-in-Time access management](/docs/10-access-management/just-in-time-access-management)

  Configure durations, expiry notifications, extensions, and grant monitoring.