Add and remove users from the directory you already run

SCIM provisioning connects Manifestly to your identity provider. Assign the app in Okta or Microsoft Entra ID and a Manifestly user is created. Unassign it and their access is removed. No invites to send, no accounts to chase at offboarding.

Okta → Manifestly SCIM 2.0
DR
Dana Ruiz dana@acme.co
Assigned in Okta → user created in SCIM department
created
PS
Priya Shah priya@acme.co
Assigned in Okta → user created in SCIM department
created
AK
Alex Kim alex@acme.co
Unassigned in Okta → access removed
removed

Offboarding that doesn't depend on someone remembering

Every tool a person has access to is one more place to clean up when they leave. With SCIM, your directory is the source of truth: the same assignment that gives someone Okta access gives them Manifestly, and the same removal takes it away.

Manual invites
  • New hires wait for an admin to send an invite
  • Leavers keep access until someone notices
  • Seats drift from what the directory says
With SCIM
  • Assign the app and the user exists in Manifestly
  • Unassign and their access is gone the same minute
  • Your directory and Manifestly always agree

Connected in three steps

1

Create a SCIM API key

In your account settings, create a dedicated API key and name it SCIM. It's the bearer token your identity provider will use, and keeping it separate means you can revoke it without touching your other integrations.

2

Point your IdP at Manifestly

Paste the SCIM endpoint and the key into your identity provider's provisioning settings for the Manifestly app. Okta, Microsoft Entra ID, and any SCIM 2.0 client work the same way.

3

Assign people

Assign the app to a person or a group in your directory. Each one becomes a Manifestly user, ready to sign in through SSO, with nothing for an admin to do.

Joiners and leavers, handled at the source

SCIM covers the two events that happen for every employee: the day they start and the day they leave. Your identity provider sends each one to Manifestly as it happens.

Your directoryOkta, Entra ID, … SCIM 2.0assign · unassign Manifestlyusers in sync
  • Assigned: a Manifestly user is created from the name and work email in your directory.
  • Unassigned or deactivated: their memberships in your account are archived, the same path an admin takes when removing a user by hand.
  • Recorded: every provisioning event lands in your account's activity log, marked as SCIM.
# New hire assigned in your IdP
POST /scim_v2/Users
Authorization: Bearer <api-key>
{
  "userName": "dana@acme.co",
  "name": { "givenName": "Dana", "familyName": "Ruiz" },
  "emails": [{ "type": "work", "value": "dana@acme.co" }],
  "active": true
}

# Offboarded in your IdP
PATCH /scim_v2/Users/4821
{ "Operations": [{ "op": "replace", "value": { "active": false } }] }

# → access removed, activity logged

You decide where new people land

Provisioned users arrive with the member role: they can take part in any run they're assigned to, but can't create or edit workflows. Create a department named SCIM and that's where they'll land, so you can promote and move people on your own schedule. Without one, they join the account itself.

  • Safe by default: no one is provisioned straight into an admin role.
  • Users are matched by email, so SCIM and SAML SSO line up on the same identity.
  • Your API key users and guest users are never exposed to the directory.
Account settings · SCIM provisioning
SCIM endpoint https://app.manifest.ly/scim_v2
Bearer token API key “SCIM” · ••••••••
New users land inSCIM department
Default rolemember

Works with the directory you already have

Manifestly speaks standard SCIM 2.0, so any identity provider with SCIM support can provision users.

OktaLifecycle Management Microsoft Entra IDAutomatic provisioning OneLoginSCIM provisioning Any SCIM 2.0 clientstandard Users endpoint

SSO decides who gets in. SCIM decides who belongs.

SAML SSO authenticates people against your identity provider, but only for users who already exist in Manifestly. SCIM is the other half: it creates those users ahead of their first sign-in and retires them when they go. Together, your directory controls access end to end, and SCIM is included with SSO on the Enterprise plan.

SAML SSO
Who is signing in
SCIM
Who belongs here

SCIM provisioning, answered

SCIM is included with SAML SSO on the Manifestly Enterprise plan. See the pricing page or read more about Enterprise.

Any identity provider that supports SCIM 2.0, including Okta, Microsoft Entra ID, and OneLogin. Manifestly exposes a standard SCIM Users endpoint, authenticated with a bearer token.

Their memberships in your Manifestly account are archived, the same as when an admin removes a user. Their work history stays in your runs and activity log. If they belong to another Manifestly account, that account is unaffected.

They arrive as members, able to participate in runs but not create or edit workflows. If your account has a department named SCIM, they land there; otherwise they join the account itself. Admins can then change roles and move people between departments as usual.

Not yet. Today SCIM creates users, lists them, and removes them. Profile updates and group provisioning are on the roadmap. Name and email changes can be made in Manifestly directly.

SCIM comes with the SSO entitlement, and the two are designed to work together: SCIM creates the user and SSO signs them in. Users are matched by email in both, so they resolve to the same person.

Other Features

Workflow Customization

Shape exactly how each workflow behaves — logic, data, timing, and documentation.

Govern, secure & prove it

SSO, granular permissions, and a complete audit trail — the controls enterprise teams need to run their work and prove how it was done.

Trusted by organizations big and small for their recurring workflows

Compass logo
Sheraton logo
Foxconn logo
Coldwell logo
Plural Sight logo
BDO logo
KW logo
UT Austin logo

Provision Users From Your Identity Provider

With Manifestly, your team will Never Miss a Thing.