Outbound provisioning synchronizes customer accounts from Strivacity to external systems such as identity providers, directories, CRMs, or messaging platforms.

Capabilities

Using outbound provisioning, you can:

• Provision accounts into downstream systems
• Keep external accounts synchronized when customer data changes
• Deprovision accounts when they are deleted or removed from scope
• Execute custom provisioning logic using hooks
• Synchronize external identifiers or metadata back into Strivacity

Common target systems include:

• Microsoft Entra ID
• Active Directory
• Salesforce
• Email or mailbox systems
• Custom HTTP services
• Other downstream identity or business systems

📘

Outbound provisioning is configured per identity store.

How outbound provisioning works

Outbound provisioning uses configurable provisioning targets attached to an identity store.
Each target defines:

• Which accounts are in scope
• When provisioning should occur
• How provisioning is executed
• How provisioning state is tracked

Provisioning is implemented using custom provisioning logic that executes through a hook.

The provisioning lifecycle can include:

• Initial provisioning
• Re-provisioning after account updates
• Scheduled synchronization
• Deprovisioning
• Retry and polling behavior for long-running external operations

Example use cases

Outbound provisioning can support scenarios such as:

• Creating mailboxes in external systems
• Synchronizing identities into Microsoft Entra ID
• Provisioning CRM customer records
• Maintaining downstream directory synchronization
• Synchronizing external identifiers back into Strivacity
• Removing access when accounts leave scope

Before you begin

Before configuring outbound provisioning:

• Create or identify the target identity store
• Determine which accounts should be synchronized
• Prepare the external system endpoint or provisioning API
• Define the provisioning logic required by the target system

⚠️

Outbound provisioning is highly flexible and can affect large numbers of accounts. Carefully validate provisioning logic and filters before enabling a target in production.

Create an outbound provisioning target

1. Go to Identities > Identity stores.
2. Select the identity store.
3. Open the Outbound provisioning tab.
4. Select Create.
5. Configure the provisioning target (filling out the Name field is mandatory to proceed).
6. Save the configuration.

After the initial save, additional tabs become available for configuring provisioning logic and reviewing logs.

Configuration

The Configuration tab defines the provisioning target settings.

General configuration

• Enable: Controls whether the provisioning target is active. When enabled, Strivacity begins processing accounts that match the configured filter.

  ⚠️

  Enabling a provisioning target can immediately trigger provisioning operations for matching accounts. Always validate filters and provisioning logic before enabling a target.
  Provisioning targets are created in a disabled state by default.

• Name: Name of the provisioning target.
• Description: Optional description for administrators.
• Maximum parallel jobs: Controls how many provisioning jobs can execute in parallel for the target.
  This setting helps prevent external systems from becoming overloaded during large synchronization operations.
  For example:
  • Lower values reduce load on downstream systems
  • Higher values increase synchronization throughput
    Provisioning operations for the same account are not executed in parallel.

Filter

Filters determine which accounts are included in outbound provisioning. If no filter is configured, all accounts in the identity store are included. Filters can use searchable account attributes, organization membership, or other supported criteria.

Example:

• Only provision accounts where department = Sales
• Only provision accounts belonging to a specific organization.

The filter preview link allows administrators to review matching accounts before enabling the target.

Actions

The Actions section provides administrative operations for the outbound provisioning target.

• Force provision of all accounts: Schedules provisioning for all accounts currently matching the provisioning filter.
  Use this action to:
  • Re-run provisioning after provisioning logic changes
  • Re-synchronize accounts with the external system
  • Recover from external synchronization issues
    Accounts are processed according to the configured provisioning settings and parallel job limits.

🚧

Force provisioning large identity stores can take significant time depending on the number of matching accounts and the external system performance.

• Delete outbound provision: Permanently deletes the outbound provisioning target. Deleting a provisioning target removes its configuration and provisioning logic.

❗️

Deleting an outbound provisioning target cannot be undone.

Provisioning triggers

Provisioning operations are triggered automatically based on account lifecycle events and provisioning configuration.

Provisioning can be triggered in several ways:

• Account creation: New accounts matching the filter are automatically provisioned.
• Account updates: When a matching account changes, the provisioning target runs again to synchronize updated data.
• Manual synchronization: Administrators can manually trigger provisioning for an individual account using Sync provision now.
• Force provision all accounts: The provisioning target configuration includes a Force provision of all accounts action. This action schedules provisioning for all accounts currently matching the filter.
• Scheduled re-provisioning: Provisioning logic can schedule future provisioning runs using retry or polling intervals. This is useful for:
  • Long-running provisioning workflows
  • External mailbox creation
  • Periodic synchronization
  • Retry handling

Deprovisioning

Outbound provisioning can also remove or deactivate accounts in external systems when they are no longer eligible for provisioning.

Accounts can be deprovisioned when:

• An account is deleted
• An account no longer matches the filter
• Provisioning logic explicitly returns a deprovision response

Example: If provisioning only applies to accounts in the Sales department, moving an account to another department can trigger deprovisioning.

Provisioning logic

The Provisioning logic tab defines the custom provisioning behavior for the outbound provisioning target.

📘

The Provisioning logic tab only appears after the initial outbound provisioning configuration is saved.

Provisioning logic is implemented using JavaScript code executed during provisioning and deprovisioning operations.

The editor supports:

• Custom JavaScript provisioning logic
• Package dependencies
• Provisioning response handling

Provisioning reasons

Provisioning logic executes with one of the following reasons:

• provision
• deprovision

Provisioning responses

Provisioning logic returns a provisioning response that determines the provisioning result and future execution behavior.

Supported statuses include:

• provisioned
• provisionFailed
• provisionNotNeeded
• provisionOngoing

Responses can also:

• Schedule future provisioning runs
• Persist metadata between executions

Updating account attributes

Provisioning logic can update Strivacity account attributes using values returned by external systems.

Example use cases include storing:

• External account identifiers
• Mailbox identifiers
• External reference values

Account provisioning status

Accounts display provisioning status information for each configured provisioning target.

Possible statuses include:

• Pending provisioning
• Provisioned
• Provisioning failed
• Provision not needed
• Provision ongoing

All enabled provisioning targets for the identity store appear in the account provisioning view, including targets where provisioning is not currently required.

Logs

The Logs tab displays provisioning execution history for the target.

📘

The Logs tab only appears after the initial outbound provisioning configuration is saved.

Logs help administrators:

• Review provisioning attempts
• Troubleshoot failures
• Monitor retries
• Inspect provisioning status transitions

Best practices

Start with a narrow filter

Before enabling a provisioning target broadly:

• Test with a limited account subset
• Use dedicated test attributes or organizations
• Validate provisioning logic behavior carefully

Validate external system capacity

Large synchronization jobs can generate high request volume. Configure Maximum parallel jobs appropriately to avoid overloading external systems.

Use retries for long-running operations

Avoid keeping provisioning hooks running for extended periods. Instead:

• Start the external operation
• Return provisionOngoing
• Schedule a follow-up run

Design provisioning logic carefully

Provisioning logic is highly flexible and can support complex workflows, but incorrect implementations can:

• Trigger duplicate provisioning
• Overload downstream systems
• Create synchronization inconsistencies

Limitations

Current limitations include:

• By default, a maximum of 8 external targets is supported per instance.
• Large full-account synchronizations may take significant time for very large identity stores.
• Some retry timing protections are enforced internally and cannot be fully customized.
• Disabling a provisioning target does not immediately stop already-running provisioning executions.