User Lifecycle & Offboarding

When a user leaves the organization, is deprovisioned from your identity provider, or needs to be archived, the platform provides a structured offboarding process that handles both the user account and all resources they own.

The Problem: Orphaned Resources

Every resource in the platform (apps, workflows, workspaces, AI models, etc.) has an owner. When a user is removed without handling their resources, those workloads become orphaned -- still consuming Kubernetes pods, storage, and compute but inaccessible to the departed user. The platform solves this with asset-aware archival for both manually managed and directory-synced users.

Archiving a User (Manual)

Step 1: Navigate to User Management

1. Click Users in the ADMIN section of the sidebar
2. Find the user you want to archive
3. Click the ... actions menu and select Archive

Step 2: Review Owned Resources

The archive modal displays a summary of all resources owned by the user:

Resource Type	Description
Apps	Deployed AI applications
Workspaces	Development workspaces
Workflows	Automation workflows
Projects	Data science projects
Data Volumes	Persistent storage volumes
Add-ons	Managed databases and services
Data Sources	External data connections
Prompts	Prompt library entries
A/B Tests	Active A/B testing configurations
Routers	AI gateway routers
AI Models	Registered AI models
Guardrails	Content safety guardrails
ML Models	ML workbench models

Step 3: Choose an Asset Action

You must choose how to handle the user's resources before archiving:

Action	What Happens	Best For
Transfer to organization admin	All resources are reassigned to the organization owner. This is the default and safest option.	Most offboarding scenarios
Transfer to specific user	All resources are reassigned to a user you select from a dropdown of active team members in the same organization.	Handing off to a direct replacement
Leave as-is	Resources remain owned by the archived user. They are accessible to admins but the archived user cannot access them.	Temporary archival where you expect to unarchive later
Delete all resources	Permanently removes all resources owned by the user. A/B tests are soft-deleted (marked as deleted but prediction data is preserved). Requires explicit confirmation checkbox.	When resources are no longer needed

Organization Isolation

Transfers are restricted to users within the same organization. You cannot transfer resources across organizations. This preserves namespace isolation, network policies, and secret boundaries.

Step 4: Confirm

After selecting an asset action, click Archive User. The system will:

1. Execute the chosen asset action (transfer, delete, or skip)
2. Set the user's account to archived and inactive
3. Clear all login tokens (forces immediate logout from all sessions)
4. Record metadata: who archived the user, when, and what asset action was taken

What Gets Recorded

The following metadata is stored on the archived user's profile for audit purposes:

• archivedAt -- timestamp of archival
• archivedBy -- admin who performed the action
• assetAction -- which asset action was chosen
• assetsTransferredTo -- target user ID (if transferred)

Unarchiving a User

To restore an archived user:

1. In User Management, toggle Show Archived to see archived users
2. Click the ... actions menu and select Unarchive
3. Confirm the action

The user's account is reactivated and they can log in again. Note that if resources were transferred or deleted during archival, those changes are not reversed -- the user starts with whatever resources remain.

Directory Sync (Okta / Azure AD)

For organizations using an external identity provider, the platform can automatically detect when users are deprovisioned and archive them with a configurable default asset action.

How It Works

1. The platform periodically queries your identity provider's API for user status changes
2. Users with profile.authProvider = 'saml' are matched by email address to IdP users
3. If an IdP user is marked as DEPROVISIONED, SUSPENDED, or DELETED, the corresponding Strongly user is automatically archived
4. If an IdP user is reactivated to ACTIVE and the Strongly user is archived, they can optionally be auto-unarchived

Supported Providers

Provider	API Used	Status Mapping
Okta	Okta Users API (/api/v1/users)	DEPROVISIONED, SUSPENDED, DELETED trigger archival
Azure AD (Microsoft Entra ID)	Microsoft Graph API (/v1.0/users)	accountEnabled: false triggers archival

Setting Up Directory Sync

1. Navigate to Admin > Security Settings
2. Click the Directory Sync tab
3. Configure the following:

Setting	Description
Identity Provider	Select Okta or Azure AD
API Endpoint	Your IdP URL (e.g., https://your-org.okta.com for Okta, https://graph.microsoft.com for Azure AD)
API Token	Read-only API token for user listing. Encrypted at rest using AES-256
Sync Interval	How often to check for changes (15 min to daily)
Default Asset Action	What happens to resources when a user is auto-archived: transfer to admin, delete, or leave as-is
Auto-archive deprovisioned	Enable/disable automatic archival of deprovisioned users
Auto-unarchive reactivated	Enable/disable automatic unarchival when IdP users are reactivated

Testing the Connection

Click Test Connection to verify the API endpoint and token are working. The platform will attempt to list users from your IdP and report the count.

Manual Sync

Click Sync Now to trigger an immediate sync without waiting for the next scheduled interval. After completion, a summary shows:

• Number of IdP users scanned
• Users archived
• Users unarchived
• Users skipped (no action needed)
• Errors encountered

Sync History

The Sync History table at the bottom of the Directory Sync tab shows a log of all sync runs. Click the eye icon on any row to see detailed per-user actions (who was archived, unarchived, or had errors).

Required IdP Permissions

Okta:

• Create an API token at Security > API > Tokens
• The token needs read-only access to the Users API
• Ensure the token's service account has the Read-only Administrator role or equivalent

Azure AD:

• Register an application in Azure AD
• Grant User.Read.All permission (application type)
• Generate a client secret
• The API endpoint should be https://graph.microsoft.com

REST API

Get User Asset Summary

GET /api/v1/users/:id/assets

Returns a count of all resources owned by the user. Useful before archiving to understand the impact.

Scope: users:admin

Response 200 OK

{
  "userId": "user_789",
  "userName": "Jane Smith",
  "userEmail": "jane@example.com",
  "organizationId": "org_xyz",
  "isSSO": false,
  "assets": {
    "apps": 3,
    "workspaces": 2,
    "workflows": 5,
    "projects": 1,
    "dataVolumes": 0,
    "addons": 1,
    "datasources": 2,
    "prompts": 8,
    "abTests": 0,
    "routers": 1,
    "aiModels": 4,
    "guardrails": 2,
    "mlModels": 0,
    "total": 29
  }
}

Archive User with Asset Handling

POST /api/v1/users/:id/archive

Archive a user with explicit asset handling. Replaces the previous toggle-based archive endpoint.

Scope: users:admin

Request Body

Parameter	Type	Required	Description
assetAction	string	No	One of: transfer, transfer-to-admin, delete, leave-as-is. Defaults to leave-as-is
transferToUserId	string	Conditional	Required when assetAction is transfer. Must be an active user in the same organization

Example Request

{
  "assetAction": "transfer",
  "transferToUserId": "user_456"
}

Response 200 OK

{
  "archived": true,
  "assetAction": "transfer",
  "assetResult": {
    "success": true,
    "transferred": {
      "apps": 3,
      "workflows": 5,
      "workspaces": 2,
      "total": 29
    },
    "transferredTo": "user_456"
  },
  "userId": "user_789",
  "userName": "Jane Smith"
}

Unarchive User

POST /api/v1/users/:id/unarchive

Reactivate a previously archived user. Resources that were transferred or deleted during archival are not restored.

Scope: users:admin

Response 200 OK

{
  "archived": false,
  "userId": "user_789"
}

Best Practices

1. Use "Transfer to admin" as default -- this is the safest option and ensures no workloads are disrupted
2. Review asset summary first -- always check what the user owns before choosing an action, especially before deleting
3. Enable directory sync for enterprise -- automates the offboarding process and reduces the window between IdP deprovisioning and Strongly archival
4. Set sync interval based on security requirements -- for SOC 2 compliance, consider a 15-30 minute interval to minimize the gap
5. Monitor sync history -- check for errors regularly, especially after IdP configuration changes
6. Don't delete if unsure -- use "leave as-is" and review later. Deletion is permanent for most resource types
7. Archive within 24 hours of departure -- SOC 2 best practice for employee offboarding

STAN Integration

You can also archive users and manage assets via STAN:

• "Archive user jane@example.com and transfer their resources to bob@example.com"
• "Show me what resources jane@example.com owns"
• "Run a directory sync now"

STAN uses the same REST API endpoints documented above.