# Make.com SSO: What It Is, What It Requires By Ingrid Kovarová · 2026-10-27 · Source: https://www.activepieces.com/blog/make-com-sso-what-it-is-what-it-requires --- Make.com SSO lets a team sign in through its own identity provider over SAML, and it's an Enterprise-plan feature, **not something a lower tier can switch on**. Nobody gets paged for a pricing tier, but they do get paged when sign-in breaks, which is why teams running automation tools like [Activepieces](https://www.activepieces.com) alongside it tend to care where the login boundary sits. Take the plan and delivery method from the card below, which shows what Make's own pages said on 27 October 2026. Confirm both again before you quote them to a client. ## Make.com SSO enterprise sign-in | Checked 27 October 2026 | What Make states | Source page | |---|---|---| | Plan that unlocks SSO | Enterprise | Make's pricing page | | Delivery method | SAML via your identity provider | Make's help centre SSO article | | Where to re-check | The vendor's pages, not a reseller's summary | Both of the above | ![Card beside Make pricing and help pages](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/ef957257-c05e-450f-abf3-d96ef58e5252/make-com-sso-what-it-is-what-it-requires-illustr-226b7274.webp) Only these two pages settle the question for you, because sales decks and comparison posts go stale. ### What SSO covers and what it does not Your sign-in can be no more available than your identity provider, because SSO moves the login decision to it. 99.99 % allows roughly an hour of downtime a year, and Okta's trust page lists that promised uptime for Microsoft Entra ID and [Auth0](https://auth0.com/blog/auth0-guarantees-99-99-availability-on-public-cloud/). ![Which identity providers promise four-nines uptime](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/6acc805a-608d-4c0c-83be-1518c9531857/make-com-sso-what-it-is-what-it-requires-pictogr-36636b35.svg "Source: Okta") According to Okta, Google Identity Platform promises **99.95 %, about four and a half hours**, meaning you might face a major outage during business hours lasting most of a work shift. Okta reports that Google Cloud Identity promises 99.9 %, nearly nine hours, which means you could have a full overnight outage that extends into the next morning. Each figure is a ceiling on your own sign-in, and none of them covers a misconfigured domain or a missing fallback account. At 9:02 a 40-person team opened Make, and a login that no longer recognised them bounced them. Scenarios that feed hand-offs and client reports sat unreachable. The first question was not "why" but "who owns this now", and nobody could answer it, because the person who configured SSO had left the admin list. ## Make.com SSO lockout's first-hour cost Before it cost anything else, **the first hour cost the team control**. The one person who had configured SSO was gone from the admin list, so nobody could change a setting, and every other loss accrued while people could only watch. ![Admin list with an empty row and greyed settings](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/d83cce30-7a84-4e36-afda-a912b31404b1/make-com-sso-what-it-is-what-it-requires-illustr-9eeb7e83.webp) Record these four measures in any incident like this. This write-up gives no counts for them, because we've confirmed none. - People locked out of the 40-person team (incident) - Scenarios that kept running versus scenarios that stalled (incident) - Hours of lost work (incident) - Support tickets raised (incident) Read none of this list as a vendor figure: all four are the team's own record. Make publishes plan terms and setup documentation, not incident counts. Tag every number you collect the same way, or a reader will take your estimate for Make's statement. ### People and scenarios affected Count lockouts by role, not just by head. A locked-out builder is a different problem from a locked-out viewer, because only the builder can change a scenario. Whoever gets paged when an automation fails has to be able to sign in, and that person's access is the one to check first. Record scenarios in two columns: those that kept running on their schedule and those that stalled. The gap shows which automations depended on a human session and which didn't. That tells you which ones need an owner named in advance. ### Make.com SSO lockout hours and cost Count hours from the first failed sign-in to the first successful one, then multiply by the people who couldn't work. Keep that figure apart from the time spent on diagnosis, because the two have different fixes. Money lost is the sum of those hours plus any support cost, and it stays an estimate until finance confirms it. Cheapest to get, easiest to misread: the ticket count shows how many people asked for help, not how many the lockout affected. ## Make.com single sign-on setup steps Four of the five ordered steps in Make's SSO setup went wrong for us: the plan check, the domain check, the email mapping and enforcement, by which point the implementation was blocked at the core checkpoints, so all further work on the SSO implementation was stalled. The people who wrote in were only the first to hit those gaps. 1. Confirm the plan and prerequisites. We assumed our plan included SSO and never read Make's help page. 2. Configure SAML at the identity provider. 3. Verify the domain. Ours was incomplete. 4. Map users by email. 5. Enforce. We did it with no fallback login. ![Five-step SSO checklist with three crosses](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/50a8c25a-e88d-46d3-b58f-d7c0bbe6cf0d/make-com-sso-what-it-is-what-it-requires-illustr-550967d7.webp) Check that SSO is part of your plan, and name the person who owns the organisation's admin role. That owner is who gets paged when logins fail, so settle it before you configure anything. ### Make.com SSO identity provider configuration Create the SAML application at the identity provider and exchange its details with Make as the help documentation describes. This step went smoothly for us, which is the trap: a clean configuration says nothing about whether the later steps will hold. Once enforcement is on, every Make login passes through that provider, so its outages become yours. The uptime chart below shows how reliably the identity provider stayed reachable. Treat the provider as a dependency with its own owner and escalation path, not as background plumbing. Before it will route logins through your provider, Make needs proof that you control the email domain. Ours wasn't fully verified, and **some addresses didn't match Make's records**. Mapping is by email, so every user's address at the provider must match the address on their Make account exactly. Compare both lists before you enforce. When enforcement goes on, password login goes for everyone in scope. We switched it on Monday morning with no break-glass admin kept outside SSO, so nobody could get in to undo it. **Keep at least one named fallback account, test it, and enforce only after a pilot group has signed in successfully.** ## Make.com SSO rollout admin lockout Four decisions, made in a fixed order, caused the lockout. They were enforcement before testing, no admin outside the identity provider, an email attribute that didn't match, and a plan entitlement nobody verified. Whoever owns the Monday-morning page owns all four. Follow the timeline below from the moment we switched enforcement on to the admin sign-in that had nowhere to land. Take from it that no single step looks reckless alone; the failure is that each one removed the chance to recover from the next. ### Make.com SSO enforced before login testing We switched enforcement on as the first act, not the last. Once it's on, every sign-in, admins included, is sent to the identity provider (the system that holds staff credentials and vouches for them). ![Modal dialog for enabling OpenAI as an AI provider in Activepieces Platform Admin, showing API key setup instructions and…](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/f98401c7-773d-4cc0-a678-e922f6b6269c/how-webhook-triggers-detect-and-send-real-time-d-5e65f2a0.webp) Nobody had proven that path works for even one person. Make's help pages describe the setup, but a setup screen accepting your values isn't evidence that a sign-in succeeds. Treat enforcement as the final step, after a pilot group has logged in cleanly. ### Make.com SSO without a fallback admin When the identity provider sign-in failed, **nothing remained to reverse the setting**. The team had no local administrator who could still sign in with a Make-native password, so the only route back was a support ticket. In the pages we reviewed, Make's documentation doesn't state plainly that you must keep such an account, so the safeguard is yours to impose. Name one owner for it, store its credentials where a second person can reach them, and test it before enforcing. ### Email mismatch between provider and Make To the system, the admin was a stranger: Make matches the person arriving from the identity provider to an existing account, and the email attribute the provider sent differed from the email on the Make account. Because the people with the Privileged accounts can carry older or aliased addresses, so compare each admin's Make email with what the provider will send before anything is enforced. Confirm also that your plan includes SSO at all, on Make's own pricing and help pages, because we assumed the entitlement here and never checked it. ## Make.com SSO requirements next to Activepieces, side by side Make puts SSO on its Enterprise tier, while Activepieces offers SSO from its self-serve Team plan and adds SCIM, custom RBAC and audit logs in Ultimate and self-hosted enterprise control, so the plan question has a different shape for each. The table sets the two against one another; the vendors' own pages are the sources, read on 27 October 2026. ### Plan, hosting and price compared | | Make | Activepieces | |---|---|---| | Plan unlocking SSO | Enterprise (Make pricing and help pages, 27 Oct 2026) | Team plan, self-serve (Activepieces pricing page, 27 Oct 2026); Ultimate and self-hosted enterprise control add SCIM, custom RBAC and audit logs | | Cloud or self-hosted | Cloud service | Cloud or self-hosted | | Price or terms | No published price | Team is published and self-serve; Ultimate is quoted by sales | | Limits | Domain verification and fallback admin access are yours to set up | Self-hosting makes the identity provider link and admin recovery yours to run | Read the table as a procurement check. Make's "no published price" cell means you can't promise a budget to anyone before a sales conversation, while on the Activepieces side only the Ultimate and self-hosted enterprise tiers need one. To see why that matters, look at the [SSO Premium Index](https://ssopricing.com). It ranks what vendors charge to step up to an SSO plan: HubSpot 2043%, GitHub 425%, Intercom 355%, Copper 330%, Zoho CRM 271% and Figma 244%, with HubSpot's markup exceeding twenty times the base plan, which renders it cost-prohibitive for most organizations. Those are other products, not Make's price. They show that an SSO tier can cost several times the plan beneath it, so a quote is worth having before your team depends on the feature. ### When the difference matters The hosting row decides who gets paged. On Make, a failed SSO login goes to Make's support and your own owner of the account. With [Activepieces](https://www.activepieces.com), the core is MIT-licensed, so a security team can read the code and run it self-hosted or air-gapped before sign-off, where Make asks for its maturity on trust. A failed SSO login then goes to whoever runs the server, who needs a local admin login that doesn't depend on the identity provider. Name that owner before the rollout, not after the lockout. ![Activepieces admin panel showing Single Sign On configuration options including Allowed Domains, Google, SAML 2.0, and…](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/90bfeee4-b83c-46fa-94f2-883a49366b24/healthcare-automation-governance-who-must-sign-o-bbf57bd5.webp) ## Make.com SSO rollout rules Name in writing whoever gets paged when the login screen rejects forty people at 8:55 on a Monday, and do it before you switch enforcement on. The team now runs four rules and one checklist to make sure of it. ### Four rules written into the runbook First, a break-glass owner sits outside enforcement: one account that still signs in with a password, held by a named person, not a shared mailbox. Second, a test group signs in through the identity provider before anyone else is forced to. Third, the email-attribute check is written down, because a mismatch between the address the provider sends and the address Make holds is what locks a user out. Fourth, every change gets a window and a rollback owner. Before any of them comes a fifth check: cost. The [SSO Premium Index 2026](https://ssopricing.com) charts how much vendors add for SSO. One vendor adds under 100%, two add 100-199%, four add 200-299%, three add 300-499%, and one adds 500% or more. ![Where SSO price premiums cluster across SaaS vendors](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/692bde52-0e14-4783-8564-66c5a034ed5d/make-com-sso-what-it-is-what-it-requires-distrib-c6bde92f.svg "Source: SSO Premium Index 2026 (2026)") **Eight of eleven therefore add at least 200%**, so SSO is rarely a rounding error, and you should read Make's pricing page before you promise it to anyone, not after procurement has signed. 1. Check your plan on Make's pricing page and confirm SSO is included. 2. Name the break-glass owner and keep that account outside enforcement. 3. Run the email-attribute check against every user in scope. 4. Sign in a test group through the identity provider. 5. Set the change window and name the rollback owner. 6. Enforce. Run the steps in that order. Skipping to step six is how the original lockout happened. ## Frequently asked questions ### Is Make.com SSO available on the free or Pro plan? No: in our lockout it was an Enterprise-plan feature, so a team on a lower plan shouldn't expect a single sign-on toggle. Confirm against Make's pricing page and its SSO help article, and write down the date you read them. Whoever signs the order owns that check, because plan details change and a screenshot from last quarter proves nothing. ### Does Make.com support SCIM user provisioning? Treat SCIM as unconfirmed until Make's own documentation says otherwise. SSO handles who can sign in; SCIM handles who gets created and removed automatically. Without it, offboarding is a manual task, and someone must be named as the person who does it. Look for provisioning on the vendor's SSO help page and, if it's silent, ask Make's sales team to confirm in writing. ### Which identity providers work with Make.com SSO? For this question, Make's SSO help article is the authority, and the list there outranks any forum post or third-party guide. Before promising a particular provider to a team, check that the article names it or describes the standard protocol it relies on. Then test with one pilot account that has a fallback sign-in, so a misconfigured domain or mapping doesn't lock out everyone, which is how our Monday began. ### Can you self-host Make.com to control sign-in? We found no self-hosted edition in Make's pricing or documentation. Make.com is offered as a hosted service, so sign-in control comes from the vendor's SSO settings, not from running the platform yourself. If your policy requires hosting inside your own network, that's a procurement question to settle before anyone builds a scenario. Ask the vendor directly, and keep the reply with the contract. ## References - [SSO Premium Index 2026](https://ssopricing.com) - [Okta](https://trust.okta.com/)