Make.com single sign-on, or SSO, lets users authenticate through the organization’s identity provider instead of maintaining a separate Make.com password. The usual enterprise setup uses SAML 2.0 for authentication, while SCIM may be used separately to provision and deactivate users.
The technical configuration is only part of the work. A reliable rollout also needs a clear access policy, a defined owner, consistent user identifiers, a recovery path for administrators, and a test plan that covers both successful and failed access.
The safest sequence is to design the access model first, configure SAML in a controlled pilot, validate the identity mapping, and only then consider SCIM provisioning or broader enforcement. This prevents an authentication change from becoming an avoidable user-lifecycle or permissions problem.
What Make.com SSO controls
SSO controls how a user proves their identity when signing in to Make.com. Make.com acts as the service provider, while an identity provider such as Microsoft Entra ID, Okta, or Google Workspace authenticates the user and sends a signed SAML assertion back to Make.com.
SSO does not automatically decide who should have access, what role they should receive, or which teams should own their scenarios. Those decisions remain part of the organization’s access model and the configuration available in the relevant Make.com plan and workspace structure.
SAML SSO
SAML connects Make.com to the identity provider for sign-in. It typically relies on an ACS URL, an entity ID, a login URL, a signing certificate, and a stable user identifier.
SCIM provisioning
SCIM can automate user and group lifecycle actions where supported. It is separate from SAML and should be evaluated as a provisioning control, not as another login method.
SSO answers “How does this person authenticate?” It does not, by itself, answer “Should this person have access?”
Plan the access model before configuring SSO
Before opening the SAML settings, decide what Make.com access is meant to represent in your organization. A small automation team may need access to build and maintain scenarios, while other employees may only need limited access or no direct access at all.
Document the intended user groups, the business owner for each group, the required permissions, and the process for joining or leaving the group. Use identity provider groups where possible, but do not assume that a group name alone creates a complete governance model.
- Confirm that the Make.com subscription and organization settings support the required SAML and, if needed, SCIM features.
- Identify the Make.com organization administrator and the identity provider administrator.
- Choose the authoritative user identifier, normally a stable work email address or directory attribute.
- Create a pilot group rather than assigning the application to the entire company immediately.
- Define an emergency administrator and a recovery route if SSO configuration fails.
- Decide who owns certificate renewal, group membership, and periodic access review.
These decisions reduce the risk of configuring a technically valid connection that is difficult to operate. For broader systems work, the same process-first approach applies when reviewing systems, CRM, automation and AI implementation services.
How to configure SAML SSO for Make.com
The exact labels may change as Make.com and identity providers update their administration interfaces. Use the values shown in the current Make.com settings and map them carefully into the corresponding fields in your identity provider.
1. Collect the service provider values
Open the SSO configuration area for the Make.com organization and record the values provided for the SAML connection. These commonly include:
- Assertion Consumer Service, or ACS, URL.
- Service provider entity ID or audience URI.
- Expected NameID format or user identifier.
- Any other organization-specific values shown in the configuration screen.
Do not copy values from an old connection or from a different Make.com organization. SAML depends on exact matching, and a near match can produce a failed login that looks like a user permissions problem.
2. Create the Make.com application in the identity provider
Create a dedicated SAML application in the identity provider. Enter the ACS URL and entity ID from Make.com, then select the identifier format that matches the Make.com user record. In many environments, the primary work email is used, but the correct choice is the attribute that remains stable and is consistently maintained.
Configure the identity provider to sign the SAML response or assertion according to the requirements shown by Make.com. Record the issuer or entity ID, the SSO login URL, and the certificate used to validate the signed response.
Keep the application assignment restricted to the pilot group while testing. Broad assignment at this stage makes it harder to distinguish configuration failures from incomplete access design.
3. Enter the identity provider metadata in Make.com
Return to Make.com and enter the identity provider values in their matching fields. Check the issuer, login URL, certificate, and user identifier one character at a time. Certificates should be pasted in the expected format, without accidental spaces or missing certificate boundaries.
Save the configuration without enforcing it for all users if the interface allows that approach. Preserve the current administrator session until the pilot has completed successfully. A second browser session or private window is useful for testing without destroying the working administrative session.
4. Test the pilot flow
Test with users who represent the actual access pattern, not only the administrator. The pilot should include at least one user who is assigned to the application, one who is not assigned, and, where relevant, a user whose directory data has recently changed.
- Sign out of existing Make.com sessions or use a private browser window.
- Start login from Make.com or the identity provider application portal.
- Confirm that the user is redirected to the identity provider and returns to the correct Make.com organization.
- Verify that the expected account and permissions are present.
- Confirm that an unassigned user is denied access as intended.
- Record the result, error message, timestamp, and test identity.
A successful administrator login proves only that one identity works. It does not prove that group assignment, account matching, role mapping, or access removal works.
Understand the difference between SAML and SCIM
SAML and SCIM solve different problems. SAML establishes an authentication path. SCIM provides a standardized way for an identity provider to send user or group lifecycle changes to an application, where the application supports the required operations.
If SCIM is available for the Make.com organization and identity provider, obtain the SCIM endpoint and access token from the relevant Make.com settings. Configure provisioning in the identity provider, assign a small test group, and verify the results before enabling broader synchronization.
Test the full lifecycle, not only creation:
- Assign a new pilot user and confirm the expected account behavior.
- Change a supported directory attribute and verify whether the change reaches Make.com.
- Remove the user from the application or group and confirm the expected deactivation or access removal.
- Check what happens to ownership, scenarios, teams, and other business objects before automating offboarding.
SCIM should not be enabled merely because it is available. If ownership transfers and offboarding rules are undefined, automated deactivation can expose a separate operational gap.
Automated provisioning is safe only when the organization has decided what happens to the work owned by a departing user.
Operational controls that make SSO reliable
Use one authoritative identity attribute
Account matching fails when the identity provider sends one value while Make.com stores another. Decide whether the primary email or another directory attribute is authoritative, then include it in joiner, mover, and leaver procedures. Avoid changing identifiers casually after the connection is live.
Make ownership visible
Assign an owner for the SAML application, certificate renewal, group membership, SCIM token, and Make.com organization administration. These may be different people, but each responsibility should have a named owner and a backup.
Separate access from administration
Not every Make.com user needs organization administration rights. Use the narrowest practical assignment and review elevated access separately from ordinary application access. An identity provider group that grants access to Make.com should not automatically be treated as a group that grants administrative authority.
Design certificate and token rotation
Record certificate expiry dates and SCIM token ownership in an operational system that someone reviews. Test the replacement procedure before the existing certificate expires. A configuration that works today but has no renewal owner is not a finished integration.
Make reporting answer a decision
Review sign-in failures, application assignments, inactive users, and provisioning errors with a specific decision in mind. For example, a monthly review might decide whether access groups are still justified. Reporting that produces a list without an owner or follow-up action rarely improves access control.
Troubleshoot common Make.com SSO failures
Start with the failure point rather than changing several settings at once. The following sequence narrows the problem quickly.
- Check application assignment. Confirm that the test user belongs to the identity provider group assigned to Make.com.
- Check the identifier. Compare the NameID or mapped attribute in the SAML response with the user identifier stored in Make.com.
- Check ACS and entity ID values. Verify that the values in the identity provider match the current Make.com organization settings exactly.
- Check signing material. Confirm that the certificate is current, complete, and associated with the active identity provider configuration.
- Check account and organization context. Make sure the user is returning to the intended Make.com organization and is not relying on an old browser session.
- Check provisioning separately. If SAML works but a user is missing or inactive, investigate SCIM assignments, synchronization logs, and lifecycle rules independently.
A hypothetical example illustrates the distinction: a marketing analyst is assigned to the identity provider application and authenticates successfully, but Make.com rejects the login because the assertion contains an old email alias. The SAML connection is functioning, while identity matching is not. Changing the certificate would not solve that problem.
A SAML error is often a data consistency problem, not an authentication problem.
Maintain the integration after launch
After the pilot, expand access in stages and keep a record of the configuration. Review group assignments when teams change, monitor failed sign-ins and provisioning events, and confirm that the recovery administrator still has a tested route into the organization.
SSO is one part of a wider automation operating model. If Make.com scenarios are business-critical, document who owns each scenario, what system is authoritative for its data, and what happens when a user, credential, or connected service changes. More tools do not automatically create a better operating system. Clear decisions, visible ownership, and reliable handoffs do.
Organizations reviewing this kind of control often benefit from first mapping the underlying process and then selecting the right implementation support, such as workflow automation and business system integration services where relevant.
Frequently asked questions
What is required to set up SSO for Make.com?
You generally need a Make.com organization with the relevant SSO capability, an identity provider that supports SAML 2.0, administrator access to both systems, and a defined user identifier such as a primary work email. Confirm current plan and feature availability in Make.com before starting.
Does Make.com SSO automatically provision users?
No. SAML SSO handles authentication. User provisioning and deprovisioning are separate lifecycle functions that may be supported through SCIM, depending on the Make.com organization and identity provider configuration.
Why does Make.com reject a user after successful identity provider login?
Common causes include a mismatched NameID or email attribute, incorrect ACS or entity ID values, missing application assignment, an expired certificate, or a user account and organization mismatch in Make.com.
Should every employee be assigned to the Make.com SSO application?
Not necessarily. Assign access to the users or groups that need Make.com, using the organization’s access policy. Start with a pilot group and expand only after authentication, permissions, and ownership rules have been tested.
Who should own Make.com SSO after setup?
Ownership should be explicit. Assign responsibility for the SAML configuration, certificate renewal, identity provider groups, SCIM token, Make.com administration, monitoring, and emergency recovery, with backups for critical responsibilities.
Design a dependable Make.com access model
If SSO setup is exposing unclear ownership, inconsistent user data, or wider automation governance issues, ConsultEvo can help map the process, clarify the control points, and implement a maintainable systems design.
