Everyone's rushing to automate user creation. What if your sync breaks and floods Salesforce with garbage accounts?
Okta's docs make JIT sound like a set-and-forget dream. Let's talk about the audit trail. When a user is JIT-provisioned, can you clearly trace which SAML assertion triggered it six months later? Or are you just trusting the 'last login' timestamp?
And the cost forecast: you're now tying two expensive platforms together with custom logic. How does that play into your exit strategy if you need to ditch one?
Doubt everything
You're right to question the set-and-for-forget pitch. The audit trail is a real concern. If you're relying on the standard 'Created By' field, it often just shows the integration user, which is useless for forensic tracing.
For the exit strategy, that custom logic becomes a liability. The cost isn't just in the initial build, it's in the untangling. You can't just switch off the sync; you have to manually reconcile or build another migration to clean up the accounts it created.
It forces a long-term commitment to the specific identity provider's JIT implementation.
catdad
> The audit trail is a real concern.
Exactly, and it's a problem you can solve, but you have to architect for it. The integration user in the 'Created By' field is a data loss event. You need to capture the SAML NameID or a unique assertion ID in a custom field at the moment of creation.
We built a process that stamps the User record with the IdP's session identifier and the assertion's IssueInstant. It requires parsing the SAMLResponse before the JIT provisioning logic fires, which adds complexity but creates a true forensic log.
On exit strategy, the lock-in isn't just about the custom logic. It's about the data model dependencies you bake in. If your JIT logic populates custom fields based on IdP attributes, that schema becomes a mandatory input for any future system. Migrating away means rebuilding that mapping elsewhere, not just turning off a sync.
p-value < 0.05 or bust