Sign your team in with the identity provider you already run

SAML-based single sign-on lets everyone reach Manifestly through your own identity provider — no separate passwords to manage. Works with any SAML 2.0 IdP, from Okta and Microsoft Entra ID to OneLogin, Auth0, and Google.

Available on the Enterprise plan. See pricing · About Enterprise

Sign in to Manifestly SSO
app.manifest.ly/a/acme
Welcome to Acme on Manifestly

Your organization uses single sign-on.

Redirects to your identity provider

One front door, not another password

Every extra login is another credential to reset, another account to remember to switch off when someone leaves. Point Manifestly at the identity provider your organization already trusts and access follows the rules you already enforce.

Standalone passwords
  • A separate credential for every tool
  • Offboarding means chasing down each app
  • Your security policy stops at the login box
With SAML SSO
  • People sign in through your IdP
  • Remove access in one place at offboarding
  • MFA and access policies carry straight over

Live in three steps

1

Connect your identity provider

In your account's SSO settings, paste your IdP's sign-in URL, entity ID, and signing certificate. Manifestly hands back the assertion consumer and metadata URLs to register on the IdP side.

2

Test with your custom URL

Every account gets its own branded sign-in address. Run a real login through it end to end and confirm your team lands in Manifestly before you change anything else.

3

Make SSO required

Flip the required switch and every sign-in now goes through your identity provider — passwords and other methods are turned off for the whole account.

Connect any SAML 2.0 identity provider

Setup is a straight exchange of standard SAML values — no custom integration to build. You supply three details from your IdP; Manifestly supplies the service-provider endpoints to register on the other side. If your provider speaks SAML 2.0, it works.

  • HTTP-POST assertion consumer binding with a transient NameID.
  • Signing verified against your certificate's SHA-1 fingerprint.
  • Only an admin can view or change your account's SSO configuration.
Okta Microsoft Entra ID OneLogin Auth0 Google Any SAML 2.0 IdP
From your IdP
Sign-in URLidp.acme.com/sso/saml
Entity IDurn:acme:idp
X.509 certificate-----BEGIN CERTIFICATE-----
Register in your IdP
ACS URLapp.manifest.ly/users/saml/auth
SP metadata / entityapp.manifest.ly/users/saml/metadata
NameID formattransient

Provision users straight from your directory

SAML answers who is signing in; SCIM answers who belongs here. Included with SSO, SCIM lets your identity provider create Manifestly users the moment someone is assigned the app, and remove their access the moment they're unassigned — the two events that matter most for every new hire and every departure.

Your directoryOkta, Entra ID, … SCIMassign · unassign Manifestlyusers in sync
  • Assign the app and a Manifestly user is created and added to your designated provisioning department.
  • Unassign or offboard and their access is removed — the same path as an admin removing a user by hand.
  • Authenticated with a Manifestly API key as a bearer token, scoped to your account.
# Your IdP provisions a new hire into Manifestly
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
}

# Offboarding sets active:false and removes their access

Turn it on when you're ready — not before

Enforcing SSO is a single switch, and you control the timing. Leave it optional while you validate the connection through your custom URL, then require it to lock the whole account to your identity provider. Because it's decisive, Manifestly tells you plainly: once SSO is required, you and your users can only sign in through your IdP.

  • Test end to end on your branded URL before you enforce anything.
  • When required, password and other sign-in methods are switched off account-wide.
  • Users are matched by their email address, so identities line up with your directory.
Account settings · Single sign-on
Testing
SSO optional · sign in via /a/acme to verify
safe
once verified
SSO required
Everyone signs in through your identity provider
enforced
Test first — once required, only SSO sign-in works.

Access that follows your policy

  • Your IdP handles the actual authentication — MFA, conditional access, and device policy all apply before Manifestly ever sees the user.
  • Identities are keyed to email, so people map cleanly to the accounts they already belong to.
  • Deprovision in one place: removing someone in your directory removes their Manifestly access through SCIM.
  • Required mode leaves a single, auditable way in — your identity provider.
Employee Your IdPMFA · policy Manifestly
Enforcement
Optional while testing, required account-wide when you say so
Lifecycle
SCIM keeps joiners and leavers in sync with your directory

SAML SSO, answered

SAML SSO is part of the Manifestly Enterprise plan, and SCIM provisioning is included with it. See the pricing page or read more about Enterprise.

Any identity provider that speaks SAML 2.0. That includes Okta, Microsoft Entra ID (Azure AD), OneLogin, Auth0, and Google — and any other SAML 2.0 IdP. Setup is a standard exchange of a sign-in URL, entity ID, and signing certificate.

SAML authenticates people against a Manifestly account they already belong to — it matches on email and doesn't create new users on the fly. To automate account creation, use SCIM provisioning (included with SSO), which adds users when your IdP assigns the app and removes access when it unassigns them.

It locks the entire account to your identity provider — once required, you and your users can no longer sign in with a password or any other method. We recommend testing the connection through your custom sign-in URL first, then turning required mode on.

By email address. The email your identity provider asserts is matched to the corresponding Manifestly user, so identities line up with the accounts people already have.

Yes. SCIM, included with SSO, creates a Manifestly user when your IdP assigns the app and removes their access when it unassigns or offboards them — the two lifecycle events that cover every new hire and every departure. It authenticates with a Manifestly API key as a bearer token.

An account admin. SSO is configured in your account settings, where you enter your IdP details and get back the service-provider ACS and metadata URLs to register on the identity-provider side.

Other Features

Design your process

Workflow Customization

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

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

Authenticate Your Team Using SAML SSO

With Manifestly, your team will Never Miss a Thing.