SCENARIO 05 Okta Workflows JML Lifecycle SOC 2

Okta Workflows JML Automation

Following the M&A Okta migration, every lifecycle event still required manual admin intervention — no guardrails, no audit trail. Three Okta Workflows deployed covering Joiner, Mover, and Leaver events. Mover flow writes timestamped rows to a JML Audit Log table. Break/fix documented. SOC 2 CC6.2 and CC6.3 evidence produced.

Okta Workflows JML Lifecycle Audit Log Tables SOC 2 CC6.2/CC6.3 Hybrid AD Identity

Business Problem

Following the M&A app migration completed in Scenario 02, the acquired workforce was fully onboarded into Okta — provisioned from Active Directory via the Okta AD Agent and authenticated through Okta SAML SSO. The migration eliminated the technical debt of the legacy IdP. It did not eliminate the operational debt of manual access management.

Every lifecycle event — a new hire joining the HR team, an analyst transferring to Security, a departing employee — required an IAM administrator to log into Okta, locate the user, and manually modify app assignments. There were no guardrails and no audit trail proving the change had been made within any defined SLA. Delays in provisioning were impacting Day 1 readiness. Delays in deprovisioning created lingering access that would fail a SOC 2 audit.

Risk

  • Manual provisioning with no SLA — Day 1 access delays impacting new hire experience
  • Manual deprovisioning with no enforcement — offboarded users retaining app access
  • No audit trail proving lifecycle changes were made within policy
  • SOC 2 CC6.2 and CC6.3 exposure — no documented access provisioning or removal evidence

Scope

FieldDetail
Affected populationAcquired workforce migrated to Okta in Scenario 02
PlatformOkta Workflows
Lifecycle events coveredJoiner, Mover, Leaver
Trigger sourceOkta-native group membership changes — AD-synced groups do not fire native Workflow trigger events
Audit destinationJML Mover Audit Log table (timestamped rows)
Compliance targetSOC 2 Type II — CC6.2, CC6.3

Solution Design — 3 Workflows

WF 1

Joiner — HR Portal Provisioning

Triggers on User Added to Group scoped via Continue If gate to GRP-WORKFLOWS-HRApps — an Okta-native group used as the trigger source. On trigger, IDSentinel HR Portal is assigned and the provisioning event logged. Okta-native groups required because AD-synced group changes via the AD Agent do not fire native Workflow events.

WF 2

Mover — HR to Security Role Transfer

Triggers on User Added to Group scoped to GRP-ACCESS-SecurityApps. On trigger: HR Portal removed, Security Tools assigned, timestamped row written to JML Mover Audit Log table. Single trigger used — Security group addition chosen as the authoritative role-change signal.

WF 3

Leaver — Deactivation Offboarding Log

Triggers on User Deactivated. On trigger, event logged via Compose. Explicit app removal and account suspension removed after implementation — Okta clears AppUser records as part of deactivation (Remove App returns 404) and Suspend User returns 400 on already-deactivated accounts. Deactivation is the terminal access removal event in Okta's lifecycle model.

// diagrams/jml-workflow-architecture.png — JML flow diagram — trigger, logic, and action for all three workflows expand
JML flow diagram — trigger, logic, and action for all three workflows

Implementation

  • 01

    Joiner Flow — Validated

    Triggered by adding a pilot user to GRP-WORKFLOWS-HRApps directly in Okta. HR Portal appeared in the user's application list without manual admin intervention. Execution log confirmed successful flow run.

    // 01-joiner-flow-canvas expand
    Joiner flow canvas
    // 02-joiner-flow-execution-log expand
    Joiner flow execution log — successful run
    // 03-joiner-app-assignment-confirmed expand
    HR Portal assigned — confirmed in user's app list
  • 02

    Mover Flow — Validated

    Triggered by adding a pilot user to GRP-ACCESS-SecurityApps. HR Portal removed from the user's app list, Security Tools appeared in its place. JML Mover Audit Log table confirmed a timestamped row — user login, previous app, new app, and timestamp all captured.

    // 04-mover-flow-canvas expand
    Mover flow canvas
    // 05-mover-flow-execution-log expand
    Mover flow execution log — successful run
    // 06-mover-app-swap-confirmed expand
    App swap confirmed — HR Portal removed, Security Tools assigned
    // 07-mover-audit-log-table expand
    JML Mover Audit Log — timestamped row
  • 03

    Leaver Flow — Validated

    Triggered by deactivating a pilot user. Execution log confirmed successful run. Deactivated account confirmed with zero app assignments — Okta's deactivation event clears all AppUser records. Cannot authenticate regardless of residual group membership records.

    // 08-leaver-flow-canvas expand
    Leaver flow canvas
    // 09-leaver-flow-execution-log expand
    Leaver flow execution log — successful run
    // 10-leaver-zero-app-assignments expand
    Deactivated account confirmed — zero app assignments
  • 04

    Break/Fix — Mover Flow Firing on Wrong Group

    • Root cause: Continue If gate temporarily scoped to GRP-WORKFLOWS-HRApps instead of GRP-ACCESS-SecurityApps — flow fired on HR group addition, incorrectly removing HR Portal and assigning Security Tools
    • Fix: Restored value B on the Continue If card to GRP-ACCESS-SecurityApps
    • Validation: User added to GRP-WORKFLOWS-HRApps — flow did not fire
    // 12-breakfix-incorrect-assignment expand
    Break — Mover flow firing on wrong group
    // 13-breakfix-corrected-flow-canvas expand
    Continue If gate corrected — flow canvas
    // 14-breakfix-corrected-execution-log expand
    Corrected flow — validation execution log

Outcome

Joiner flow: HR Portal assigned automatically on group addition — no manual intervention
Mover flow: HR Portal removed, Security Tools assigned, audit log table row written with timestamp
Leaver flow: deactivation event logged; Okta lifecycle constraints documented correctly
Break/fix documented: Continue If gate misconfiguration reproduced, corrected, and re-validated
Okta-native trigger group pattern documented as production-relevant hybrid AD design decision
SOC 2 CC6.2 and CC6.3 evidence produced — execution logs prove no manual provisioning path

SOC 2 Compliance Mapping

ControlFrameworkEvidence
CC6.2SOC 2Access provisioning tied directly to role-aligned group membership — Joiner flow execution log proves no manual provisioning path
CC6.3SOC 2Deactivation event triggers Leaver flow — execution log provides timestamped audit evidence of offboarding

Files