Do I need to build provisioning workflows around SSO?

Usually, yes — if you want SSO to be operationally useful beyond just login.

SSO handles authentication: it lets users sign in once via an IdP.
Provisioning handles lifecycle management: creating, updating, disabling, and deleting accounts and access.

When you do need provisioning

You should build or integrate provisioning workflows if you need any of these:

• Auto-create accounts when a user first logs in or is assigned access
• Deprovision users when they leave the company
• Update roles/groups when someone changes teams
• Keep app access in sync with HR/IAM source of truth
• Avoid manual admin work for onboarding/offboarding
• Meet compliance requirements for access removal and auditability

Common provisioning mechanisms:

• SCIM for automated user/group provisioning
• JIT provisioning at first login
• API-based provisioning from your internal systems
• Manual admin setup for smaller apps or early-stage products

When you might not need it

You may be fine without dedicated provisioning if:

• Your app is small/internal
• You only need authentication, not lifecycle management
• Admins can manually create accounts
• Users don’t need roles/groups synced from the IdP
• The app is used by a limited set of trusted users

Practical rule of thumb

If you’re offering enterprise SSO, customers will often expect:

1. SSO login
2. Automatic user creation
3. Automatic deactivation on offboarding
4. Group/role mapping

So the short answer is:
SSO alone is not enough for most enterprise setups; provisioning is usually the companion workflow you need.

If you want, I can also give you a decision tree for whether to implement SCIM, JIT, or manual provisioning.