Public sector use case · Workday + Okta + Microsoft 365
Joiner, mover, leaver for public employees
Access for new staff starts late, movers keep old rights and leavers stay active. Each change is a ticket, and nobody can show which policy allowed which access. Workforce changes become policy-checked identity changes, with collaboration set up and removed on time.
Architecture
One governed run
How it starts: A webhook, a schedule or an HTTP poll of Workday starts the run. Workday and Okta steps run as pre-built actions.
Step by step
How the process runs
- 01
Lifecycle context
The employee record and job details are read from Workday.
- 02
Policy
Rules + Code maps role and department to the groups and roles allowed.
- 03
Approval
Changes outside baseline access pause for the access owner.
- 04
Identity change
Okta users, groups and roles are created, changed or removed.
- 05
Follow-up
Teams messages, email and calendar invites go to the employee and manager.
Control
Human decision and exception path
Human decision
The access owner approves privileged roles and anything outside the role policy. Baseline access runs by policy.
Exception path
- Missing manager or department data routes to HR operations.
- Okta errors are captured and retried.
- Leaver runs that fail to deactivate raise an immediate alert.
Evidence
What gets audited
- The Workday context read at run time.
- The policy version and result.
- Approver identity and decision.
- Every Okta operation and Microsoft 365 message.
Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.
Sovereignty and deploymentRelated
Patterns, connectors and next steps
- Workday-Okta integration
Integration pattern · Employee lifecycle changes become governed identity and access changes.
- Microsoft 365-Okta integration
Integration pattern · Identity changes and collaboration follow-up happen together, under policy.
- Workday connector
66 pre-built actions
- Okta connector
42 pre-built actions
- Microsoft 365 connector
45 pre-built actions
- Governed self-service
Requests with policy and approval built in.
- Citizen request to case resolution
Another public sector use case.
FAQ
Questions about this use case
- Does Nexus replace any of these systems?
- No. Each system keeps its own records. Nexus runs the process between them and records each decision.
- How does the run start?
- A webhook, a schedule or an HTTP poll of Workday starts the run. Workday and Okta steps run as pre-built actions.
- What if a step is not covered by a pre-built action?
- It runs through an API, protocol or database call, or as Rules + Code in Python, Bash, Go, Java, .NET, PHP, PowerShell or JavaScript/TypeScript, with the same approvals and audit.
Use case review
Discuss this use case
Bring your version of the process. We will map the systems, approvals and evidence it needs.