Most IT systems already automate the joiner-mover-leaver process, but OneStream is often the exception, with a security admin applying every HR change by hand. Here is how to close that gap by connecting OneStream directly to your identity and access management (IAM) system, and the concurrency issue you will hit if you do not handle simultaneous updates carefully.
How the OneStream and IAM integration works
At a high level, your IAM system triggers a Data Management sequence through OneStream's REST API, which calls a Business Rule Extender. The extender reads the inbound parameters and applies the requested change through OneStream's Security Admin API.
We designed the integration around four actions that mirror the standard joiner-mover-leaver lifecycle:
- Creation: create the user and assign initial groups
- Provisioning: add group memberships after a role or responsibility change
- Deprovisioning: remove specific group memberships
- Deactivating: disable the account entirely
The automation only works if it holds up under how your IAM platform actually sends events. In this case, the IAM system sends one call per group membership, so a user with several group changes can trigger several near-simultaneous calls into OneStream, sometimes hitting different application servers.
If each call reads the current groups, applies one change, and saves the full list back, the last save can overwrite the earlier ones. Every request can complete without an obvious error while some memberships quietly disappear.
Handling simultaneous OneStream calls safely
We serialize updates per user rather than across the whole integration. Requests for the same user queue up and process one at a time, while requests for other users keep running in parallel. Because calls can land on different application servers, the lock needs to live in a shared layer. In this implementation, we use a SQL Server application lock (sp_getapplock) on OneStream's framework database. After acquiring the lock, each call re-reads the user's current memberships before applying and saving the change.
The order matters: lock first, then re-read. That keeps every update based on the latest saved state instead of a stale snapshot.
The real outcome for OneStream access automation
This is ultimately an access management improvement, not a locking exercise. Automating OneStream user access is not just a nice-to-have, it is what lets your finance platform keep pace with how the rest of the organization already manages identity. Joiners, movers, and leavers get reflected automatically, administrators spend less time on repetitive security maintenance, and the process becomes more consistent and easier to audit.
Working on a similar OneStream IAM integration?
A useful first question to ask is whether your IAM system sends one event per user or one per group. If you want a second pair of eyes on the access flow, Finext's OneStream team can review the design with you.
