Governed Employee Access Changes with ServiceNow, Okta and Microsoft 365

Most access incidents are not dramatic. A joiner receives the wrong group. A mover keeps rights from their previous role. A leaver's account stays active for a week because the ticket was closed before the change was made. Each of those is a coordination failure between the system where the request lives and the system where identity is changed.

In many organisations the request is logged in ServiceNow, the approval happens in email or chat, and an administrator applies the change in the identity provider by hand. The ticket says done. The identity system may or may not agree. Proving what happened later requires correlating timestamps across three tools.

This guide describes a Nexus pattern that keeps ServiceNow as the request system and Okta as the identity system, and puts the sequence between them into one governed workflow with approval and audit. It deliberately does not assume HR system integrations, because those depend on your estate and are not part of this workflow pattern.

ServiceNow is a listed Nexus trigger source and appears in the actions library, with action groups for Users, Change Management, CMDB, Incidents and Tickets. A new or updated access request can start a run directly, carrying the requester, the subject, the requested access and any justification as structured input.

The first steps check that the request is complete and consistent. Is the subject a known user? Is the requested access defined? Does the request conflict with a rule, such as a separation-of-duties pair? Those checks run as Rules + Code, and a request that fails them is returned to ServiceNow with a specific reason rather than silently stalled.

Context matters for the approver. The run can gather what the approver needs to decide, such as current assignments or the owning team, through the identity system API or ServiceNow data, and present it alongside the request.

• 01ServiceNow request starts the run
• 02Completeness and policy checks in Rules + Code
• 03Context gathered for the approver
• 04Invalid requests returned with a reason

The workflow pauses for the access owner. The approver sees the request, the context and the policy checks, and approves, rejects or asks for correction. Their identity and decision are written to the execution record, and optionally back to the ServiceNow ticket.

Because approval is inside the run, it cannot be skipped by accident. The identity step is downstream of the decision, so the change cannot happen before the approval exists. That ordering is the core control, and it is enforced by the workflow structure rather than by a procedure document.

Approval rules can vary by sensitivity. Standard access can be approved by a line manager. Privileged access can require a second approver. The rule is part of the workflow version, so a reviewer can see which rule applied to any historical change.

Nexus provides 42 Okta actions across Roles, User Management, Groups and Events. Where the needed operation is not a prebuilt action, the HTTP Request node can call the Okta API directly under a vault-backed credential.

Either way, the step runs with defined inputs and outputs, and its response is recorded. A failure, such as an unknown group or an expired credential, takes an explicit branch: retry where safe, route to an administrator where not. The ticket is not closed on a failed change.

Azure Active Directory is a separate listed trigger source. Estates that use it can pair directory events with the same approval and audit structure.

Microsoft Calendar appears in the Nexus actions library, and Microsoft Teams is a listed trigger source. After an approved change, a Calendar action can schedule a related session, such as an onboarding walkthrough, and a notification step can inform the right people.

These steps are useful, but they are not the control. They should run after the identity change succeeds, not before, and their outcome should be recorded like any other step. If the productivity step fails, the access change is still valid and the failure is visible for follow-up.

Additional Microsoft 365 operations use Microsoft APIs through the HTTP Request node within the same governed workflow.

The final step updates the ServiceNow request with the outcome: approved and applied, rejected, or failed with a reason. The ticket now reflects what actually happened in the identity system, because the same run did both.

For leavers and movers, the same structure applies with different policy. Removal steps can be prioritised, and the workflow can confirm that the change is in place before the ticket closes.

Scheduled runs can support periodic access reviews by collecting assignments through the API and code and routing anomalies to owners, again with recorded decisions.

For any access change, the execution record shows the request, the checks, the approver and decision, the identity call and response, any follow-through steps and the final ticket update. That answers the questions an auditor normally asks without reconstructing timelines by hand.

Nexus runs on-premises, in private or sovereign cloud, or air-gapped, and reaches the identity and ticketing systems over the network paths you allow. Nexus provides 1,480+ pre-built actions across 43 product families. Additional operations can use APIs, protocols, databases or Rules + Code in the same governed run.

The practical outcome is fewer access mistakes and a record that holds up when someone asks how a change was made.