AI Service Desk Identity: Okta Examples, Entra Lifecycle Controls

An AI service desk connected to an identity provider reads the directory before it acts on it. The connector examples on this page are Okta’s, and the Entra ID part describes the lifecycle controls Microsoft documents. The directory already holds a person’s profile, manager, groups, application assignments and account status, so most of an access request is a lookup. What the agent may then change is bounded twice: Okta documents that a service app is limited by the OAuth scopes granted and the admin roles assigned to it, and Serval’s Okta guide states that a scope alone is not enough. Microsoft names the three events to design around, joiner, mover and leaver, while Okta and JumpCloud document the exceptions: a return from leave, a suspension that returns the same access later, a removal that leaves an entry downstream. Trusting an AI agent to grant access comes down to four questions: what it reads, what it may change, how fast a removal takes effect, and which actions wait for an approval.

What does an agent read from the directory?

Okta connector pages converge on the same core: who the person is, where they sit, what they belong to and what state the account is in. Harmony’s and Siit’s Okta pages both list name and email, department, manager and location, group memberships, application assignments and account status. Harmony also lists MFA status and employment type, and states that when an HR system such as HiBob is connected alongside Okta, the HR data takes precedence; Siit lists job title, employee number and custom attributes. Serval syncs groups with their members and applications with their assigned groups.

Configuration changes that picture. Siit excludes suspended, deactivated and staged users from its Okta import by default, with a status filter to change that, and lets the import be scoped to chosen groups, apps or user types. Imports also act on the tool: Ravenna adds synced Okta users who have no Ravenna account to the organization as members. An access review run on a filtered or scoped import concludes less than the directory knows.

What may the agent change, and who decides?

Okta’s service-app guide states that only the Super Admin role can grant scopes to an app, and each service app gets admin roles assigned to constrain it to least privilege. Okta also documents an org setting, Public client app admins, that bypasses that assignment by granting the super admin role automatically once scopes are granted, and says to disable it after admin roles are part of the workflow. Serval’s guide puts the split in one line: scopes gate which parts of the API are available, and the admin role gates which resources the integration can actually touch.

Siit’s Okta page documents the scope side in detail. The connection screen lists the scopes it requests one per line with a checkbox, the administrator chooses which to grant, and the connector runs only the actions the approved scopes allow. One scope is required for any action to run, because without it the connector cannot resolve the Okta user behind a request; a scope added later is granted by reconnecting. The same page labels OAuth through a service app recommended and the API token legacy, since a token inherits the permissions of the admin who created it and expires after 30 days of inactivity. This page covers authorization for Okta only: it does not describe consent or key handling for Entra ID or JumpCloud connectors.

The same checks transfer to any tool that automates provisioning and deprovisioning:

• which fields and statuses it imports, and which it excludes by default;
• which scopes or roles it asks for, and whether they can be granted in part;
• what happens downstream, and in which order, when access is removed;
• how quickly an urgent revocation takes effect in the applications themselves;
• whether each action can be gated behind an approval.

Joiner and leaver have exceptions of their own

Microsoft defines the three phases. Joiner is “when an individual enters the scope of needing access”. Mover is “when an individual moves between boundaries within an organization”, and the definition continues: “This movement might require more access or authorization.” Leaver is “when an individual leaves the scope of needing access”, with the clause “This movement might require the removal of access.” Okta describes the same arc as provisioning that automates the IT processes of an individual joining, moving within or leaving an organization.

For a joiner, Microsoft’s lifecycle workflows pair tasks with an execution condition naming who is in scope and when the workflow fires. Its worked example sends a manager an email seven days before the value of the employeeHireDate attribute, and the same page states that the feature requires Microsoft Entra ID Governance or Microsoft Entra Suite licenses. JumpCloud publishes a state rather than a workflow: Staged lets an administrator “preassign all the resources and policies new users will need on their start dates without granting access”, and a user cannot return to Staged once activated. Siit’s Okta page publishes starter sequences of the same kind: a Day-1 run on the HR start date that activates the user, adds baseline groups and assigns the department’s applications, and an offboarding run on the end date that revokes sessions, removes the user from all groups and deprovisions the account.

For a leaver, Okta describes deprovisioning as deactivating the account in Universal Directory, removing access to Okta app integrations and deactivating the accounts in external apps, with a notice in the admin dashboard when manual deprovisioning is required for an app.

Those sequences are minimal cases, not a taxonomy. A return can call for creating an account or for reactivating one, and the two do not start from the same state. Okta states that reactivating a user in Universal Directory also reactivates the user’s accounts in the external apps, and its example is an employee returning from leave; a rehire handled by reactivation therefore starts from the old state, an inference worth testing in a sandbox organization. Reactivating a suspended JumpCloud account returns “the same access they had prior to being suspended”. Suspension preserves a recoverable account. It can be one offboarding step, but does not establish that downstream access and retained data have been handled. JumpCloud also lists a contractor’s contract expiring among the uses of a scheduled suspension; since it cannot be edited, a contract extension means deleting it and scheduling a new one. The onboarding and offboarding playbook takes the sequences apart step by step.

What changes when a person moves?

For a promotion or role change, Okta describes updates sent out to the external apps, changing access levels and adding or removing group membership. The starting state differs per person, and additions and removals need not land at the same moment. Microsoft’s task catalog lists Remove all access package assignments for user under Leaver and Mover: when daysUntilExpiration is set, the removal is scheduled rather than immediate, and in mover templates it defaults to 15 days.

Okta automates part of the work and publishes its limits. A group rule adds a user whose profile attribute matches, and removal follows: “When a user’s department attribute changes, the user is removed from the Sales group automatically.” The same page lists the boundaries. Orgs can have a maximum of 2000 rules. Group rules cannot assign users to admin groups. Only string attributes can be used in basic condition group rules. Okta’s lifecycle page adds that a user removed from a group that provided access to an app integration is automatically deprovisioned from it.

Okta documents the order of removals as a hazard. Its Group Push page works through a case: remove a user from the group that carried the application assignment and deactivate their Okta account, and an entry for them remains in the push group downstream. In Okta’s words, “There’s no longer a link between Okta and the Taylor Smith entry in the downstream app.” The remedy is to take the user out of the membership maintenance group first.

That behavior belongs to groups managed inside Okta. What happens downstream when an agent removes a user from a group is not described on the connector pages listed below, and should be tested rather than assumed. Ravenna, Serval and Siit document group removal as an action. Whether such an action waits for an approval is taken up in what autonomy means for an IT agent.

What does Microsoft document for Entra ID’s cycle?

Microsoft’s catalog of built-in lifecycle workflow tasks labels each task Joiner, Mover or Leaver, and several carry more than one label. Adding to groups and removing from selected groups appear under all three. Requesting an access package assignment is listed under Joiner and Mover, removing one under Leaver and Mover, and emailing a manager about a user move under Mover alone.

For a leaver the catalog lists Disable user account, Remove users from all groups, Revoke all refresh tokens for user and Delete user, among others. Three limits are published. The group tasks cover Microsoft 365 and cloud-only security groups, not mail-enabled, distribution, dynamic or role-assignable groups, and on-premises AD group-based resources need group writeback. Disabling or deleting a user is not supported for users with Microsoft Entra role assignments. The token task excludes external users’ sign-in sessions.

Revocation can lag behind the click

Microsoft’s guide to revoking access in an emergency lists compromised accounts and employee termination among its scenarios, and states: “In some scenarios, there could be a period between the initiation of access revocation and when access is effectively revoked.” Two mechanisms explain it. “By default, access tokens issued by Microsoft Entra ID last for 1 hour”, and “Microsoft Entra ID can’t directly revoke a session token issued by an application”: the application has to revoke it under its own policies. Downstream, the page recommends Microsoft Entra app provisioning, which typically runs every 20 to 40 minutes, to deprovision or deactivate users in SaaS and on-premises applications, and a separate process for applications that require manual deprovisioning. The same page points to Continuous Access Evaluation (CAE), which lets administrators revoke tokens for applications that are CAE capable.

• 01

  Scopes and admin roles both bound a connector

  Okta's service-app guide has an administrator grant OAuth scopes, a step only a Super Admin can take, and assign admin roles to the app to constrain it to least privilege. A scope list alone does not describe what a connector can reach.

  Okta developer documentation
• 02

  Suspension is not departure

  JumpCloud bills a suspended account as a normal user and restores the same access on reactivation. Suspension preserves a recoverable account. It can be one offboarding step, but does not establish that downstream access and retained data have been handled.

  JumpCloud
• 03

  Revocation can lag behind the click

  Microsoft states there can be a period between starting a revocation and access being effectively revoked: access tokens last 1 hour by default, and Entra cannot revoke a session token an application issued.

  Microsoft Learn
• 04

  Removal order decides what remains

  Okta's Group Push page describes a user removed from the assignment group and deactivated whose entry stays in the downstream push group, with no link left to Okta. Removing from the push group first avoids it.

  Okta

Where does the directory connection stop?

Initial imports meet Okta’s rate limits as well: Siit’s page notes that large tenants may occasionally hit them during the initial sync, and that it retries automatically. Another identity connector is treated in the Google Workspace profile. What an organization then lets an agent carry out without asking first is taken up in scoping what an agent may do alone.

Which vendors document the users, groups and applications their Okta connector imports, and the lifecycle actions it can run?

This list names the AI service desk vendors whose public Okta connector documentation, read for this guide in October 2026, states which users, groups and applications the connector imports and which lifecycle actions it can run.

• Harmony: Harmony’s Okta page lists the applications, users and groups it syncs, and documents workflows that assign a user to an Okta application and remove the assignment on deprovisioning.
• Ravenna: Ravenna’s Okta overview states that it syncs Okta users, groups and applications, with workflow actions that add or remove group members and provision or deprovision application access.
• Serval: Serval’s Okta page documents a background sync of users, groups with their members and applications with their assigned groups, and actions that create, deactivate or suspend users and add or remove them from groups.
• Siit: Siit’s Okta page lists the identity, profile, group, application and status fields it imports, and actions that activate, suspend or deprovision a user, change group memberships and assign or remove applications, each gateable behind an approval.