Access Troubleshooting

This guide covers the most common reasons a user cannot sign in to Monte Carlo or is missing expected access after signing in.

For permission-level debugging (a user can sign in but has unexpected allow/deny results), see Authorization.

📘

Account Owner

Throughout this guide, "Account Owner" refers to a user within your organization who holds the Account Owner role in Monte Carlo — not a Monte Carlo employee or support agent. Account Owners have full administrative access to the account, including user management, SSO and SCIM configuration, and account-wide settings. If you are unsure who yours is, check with your IT team or the person who originally set up Monte Carlo at your organization — or ask the Support Agent to return the current list of Account Owners for your account.

Contents

• Signing in
• SSO issues
  • How to inspect your SAML assertion
  • Migrating to a new identity provider
  • Company email domain change or rebrand
• New user sign-up and invite issues
• SCIM provisioning issues
• Password reset issues
• Not receiving emails from Monte Carlo
• SSO fallback and emergency access
• Duplicate or conflicting accounts
• Access issues after signing in

Signing in

Monte Carlo's sign-in flow has two steps: you first enter your email address (or account identifier) to determine whether your account uses SSO or password-based authentication, then you complete the appropriate sign-in method.

"An error occurred while verifying authentication domain"

Monte Carlo could not reach its authentication service when looking up your email. This is almost always a network issue.

To resolve:

1. Check whether you are on a VPN or behind a corporate proxy. Some configurations block traffic to *.amazoncognito.com and auth.getmontecarlo.com, which Monte Carlo uses for authentication.
2. Try disconnecting from VPN and signing in again.
3. If you must remain on VPN, ask your IT team to allow outbound HTTPS traffic to *.amazoncognito.com and auth.getmontecarlo.com.
4. If the issue persists without VPN, check Monte Carlo's status page for any active incidents.

"An error occurred while fetching authentication options"

Monte Carlo was unable to load your authentication options automatically — for example when arriving from an email link or integration redirect. This is usually a transient network issue or an expired link.

To resolve:

1. Refresh the page and enter your email manually at getmontecarlo.com/signin.
2. If you arrived via an invitation or integration link, navigate directly to getmontecarlo.com/signin instead.

"An error occurred while redirecting to domain"

Your account belongs to a specific Monte Carlo deployment and the redirect to that deployment failed.

To resolve:

1. Refresh and try again — this is usually transient.
2. If you know your deployment URL (e.g., yourcompany.getmontecarlo.com), navigate there directly.

"No authentication options available"

Monte Carlo found your email but could not match it to any active authentication configuration. Common causes include:

• You are using a different email address than the one on file
• Your user account was removed and has not been re-invited
• Your account is managed under a company account identifier rather than an individual email domain
• The SSO domain configured in Settings → Single sign on is incorrect — for example, entered as @company.com instead of company.com, or as a partial domain like company instead of company.com

To resolve:

• Contact your Monte Carlo Account Owner to confirm your user account is active and that you are using the correct email address.
• If your organization uses SSO, ask your Account Owner to review the domain list in Settings → Single sign on and correct any malformed entries.

"Unable to sign in. Please verify your email and password."

This message covers all password login failures, including wrong password, account does not exist, or account locked.

To resolve:

1. Double-check that you are entering the correct email address.
2. Use the Forgot password link on the sign-in page to reset your password.
3. If your organization uses SSO, you may not have a Monte Carlo password — go back to the sign-in page, enter your email, and follow the SSO sign-in path instead.
4. If you believe your account has been disabled, ask your Monte Carlo Account Owner to re-invite you.

I am being asked to sign in frequently

Monte Carlo sessions expire after 48 hours of inactivity. This timeout is fixed at the platform level and cannot be adjusted per account or per user. Your SSO provider's own session duration setting does not extend or override Monte Carlo's session timeout — the two are independent.

If you are being asked to re-authenticate more frequently than expected, check for:

• A browser extension or privacy tool clearing cookies automatically
• Browser settings configured to clear storage on close
• A shared or ephemeral browser environment that does not persist cookies

SSO issues

SSO errors are returned by your identity provider (IdP) during the redirect and displayed on the Monte Carlo sign-in page. They typically require action from your Monte Carlo Account Owner or your IT/IdP administrator.

📘

SP-initiated SSO only

Always initiate sign-in from getmontecarlo.com/signin. Monte Carlo uses SP-initiated SSO; starting login from the IdP dashboard tile will fail unless a bookmark app has been configured.

"Invalid SAML response received" / invalid samlResponse or relayState

You attempted to log in by clicking the Monte Carlo tile directly inside your IdP dashboard (IdP-initiated login). Monte Carlo does not support IdP-initiated flows.

To resolve:

1. Start your sign-in from getmontecarlo.com/signin, enter your email, and let Monte Carlo redirect you through your IdP.
2. Alternatively, ask your IT team to create a bookmark app in the IdP that points to your Monte Carlo SP-initiated sign-in URL. This lets users click the tile without triggering an IdP-initiated flow. See Setting Up Single Sign-On for configuration details.

User successfully authenticates with IdP but lands back on the sign-in page

If signing in via SSO loops back to the sign-in page without an error, or you see a "Current user has no access to account" message, common causes are:

• Not assigned to any Authorization Group — the user account exists but is not a member of any group. An Account Owner needs to add the user to a group in Settings → Authorization groups.
• SSO configuration mismatch — the IdP provider name does not match what is configured in Monte Carlo. Use How to inspect your SAML assertion to check what provider name your IdP is sending, then compare it against the provider configured in Settings → Single sign on. Contact your Account Owner or Monte Carlo Support to correct a mismatch.
• Missing required SAML attributes — Monte Carlo requires the IdP to send three specific attributes in the SAML assertion. If any are missing or named incorrectly, authentication fails silently. See the section below on SAML attribute requirements.

Required SAML attributes for all IdPs

The email attribute is required for authentication — if it is missing or named incorrectly, Cognito will reject the assertion and the user cannot sign in. The givenname and surname attributes are used to populate the user's display name in Monte Carlo; if they are absent, login still succeeds but the profile name will be blank.

All three should be mapped in your IdP for the best experience. The exact URI names to use are:

⚠️

NameID alone is not sufficient

The email attribute must be explicitly mapped using the exact URI above. Sending only a NameID will not satisfy the email requirement.

Okta and Microsoft Entra ID: The official Monte Carlo setup guides for these IdPs include the correct attribute mappings. If you followed those guides, the attributes should already be correct. If SSO was set up manually or imported, verify each attribute name matches the URI above exactly.

Other IdPs (DUO, PingFederate, OneLogin, etc.): The Monte Carlo setup guide focuses on Okta and Entra ID. For any other IdP, you must manually configure these attributes using the exact URI strings listed in the table.

To verify what your IdP is actually sending, see How to inspect your SAML assertion below.

How to inspect your SAML assertion

When SSO fails silently — a user authenticates with the IdP but lands back on the sign-in page, ends up in the wrong Authorization Group, or receives an "email is empty" error — inspecting the SAML assertion your IdP is actually sending to Monte Carlo will show you the exact attribute names and values in use. What is configured in the IdP's attribute settings and what the IdP actually sends are not always the same.

Capturing the SAMLResponse

The SAML assertion is transmitted as a base64-encoded SAMLResponse parameter during the login redirect. To capture it using browser developer tools:

1. Open developer tools (F12 or Cmd+Option+I on Mac) and go to the Network tab.
2. Trigger the SSO login flow from getmontecarlo.com/signin.
3. Look for a POST request named IDPResponse. In the request's form data, find the SAMLResponse parameter.
4. Copy the value — it is base64-encoded XML.

Your organization may have dedicated SAML capture or inspection tooling. Use whichever method is consistent with your security procedures.

Decoding the SAMLResponse

The SAMLResponse value is base64-encoded XML. To decode it:

macOS / Linux (Terminal):

echo "<paste_base64_string_here>" | base64 --decode

Windows (PowerShell):

[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("<paste_base64_string_here>"))

The decoded XML contains the user's email address and group memberships. Handle it in accordance with your organization's security procedures.

What to look for in the decoded XML

The decoded assertion is XML. Find the AttributeStatement block. It should contain the three required attributes with the exact Name URI values:

<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
  <saml:AttributeValue>[email protected]</saml:AttributeValue>
</saml:Attribute>

<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
  <saml:AttributeValue>First</saml:AttributeValue>
</saml:Attribute>

<saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
  <saml:AttributeValue>Last</saml:AttributeValue>
</saml:Attribute>

Check that:

• All three Name URIs match exactly as shown — any variation (shortened name, different casing, trailing slash) means Monte Carlo will not recognize the attribute.
• The AttributeValue elements are non-empty and contain no leading or trailing whitespace.
• NameID may be present and correct, but it is not used for these fields — the explicit named attributes above are required regardless.

Verifying the SSO group claim

If you use SSO group mapping, look for the group attribute in the same AttributeStatement:

<saml:Attribute Name="User.Groups">
  <saml:AttributeValue>MC-Admins</saml:AttributeValue>
  <saml:AttributeValue>MC-Editors</saml:AttributeValue>
</saml:Attribute>

The AttributeValue strings here are exactly what Monte Carlo uses for group mapping. In Settings → Authorization groups, the SSO group name field must match one of these values character-for-character, including case. If the assertion sends MC-Admins but the Authorization Group is configured with mc-admins, the mapping will not apply.

Things to check:

• The group attribute is missing entirely — Group Attribute Statements are not configured in your IdP. For Okta, see Okta users are provisioned via SCIM but SSO group mapping is not working. Contact your IdP administrator to configure the group attribute — your Account Owner should know who to contact if you are unsure.
• Microsoft Entra ID sends group object IDs (UUIDs) by default. You can configure it to send display names instead for cloud-only groups, or sAMAccountName for AD-synced groups — the right option depends on your group type. The SSO group name in Monte Carlo must match whichever format Entra is sending. See the Authorization Group mapping guide for configuration details. This requires action from your IdP administrator.
• The user is not a member of any group included in the attribute filter — the assertion will not include groups the user does not belong to in the IdP. Contact your IdP administrator to verify group membership and filter configuration.

If you cannot resolve the issue after inspecting the assertion, share the decoded XML with Monte Carlo Support.

"The user was disabled. Please contact an Account Owner to request a new invitation and regain access"

This error means Monte Carlo does not have an active user record for this email address in the workspace. Successful authentication with your IdP is not enough — Monte Carlo maintains its own user list and the record here is marked as deleted. It appears in two situations:

• The user was previously removed from the account. Even if they have since been re-added to the correct IdP groups, Monte Carlo's soft-deleted record blocks access. JIT SSO login and SCIM provisioning will not automatically recreate a previously deleted user — a fresh invitation is required to explicitly reinstate them.
• The user exists in one Monte Carlo environment but not another. If your organization has multiple workspaces (e.g., production and dev), a user may be active on one but not yet added to the others. SSO succeeds on the workspace where the user record exists and fails on the rest.

To resolve:

An Account Owner must send a fresh invitation from Settings → Users → Invite:

1. Invite the user to the workspace where they are seeing the error.
2. The user accepts the invitation and completes the sign-up step.
3. SSO login will work normally on the next attempt.

📘

Which group should I choose when sending the invite?

For SSO users, the Authorization Group selected during the invite does not determine long-term access — SSO group mapping overrides it on first login. On SSO-enabled accounts, select None when sending the invite so the user is reinstated without being granted any group access in the interim. The correct group assignment will be applied automatically when the user signs in via SSO.

If you are managing access via SCIM or an IdP and expected that adding a user to a group would be sufficient, see SCIM or SSO is not automatically recreating a previously removed user for a full explanation of why a fresh invite is still required in this case.

"Cannot access account. Does not have an assigned SSO group mapped to an Authorization Group in the account"

Your account requires SSO users to belong to at least one IdP group that is mapped to a Monte Carlo Authorization Group. Your IdP is not sending a group attribute that matches a configured mapping.

To resolve (Account Owner access required):

1. Go to Settings → Authorization groups and check which groups have an SSO group name configured.
2. Confirm with your IT/IdP administrator that the user is a member of one of those mapped groups, and that the group name matches exactly — values are case-sensitive.
3. If using Microsoft Entra ID: by default, Entra sends group UUIDs (object IDs), not group names. You need to either use the group UUID as the SSO group name in Monte Carlo, or — if your tenant uses Active Directory synchronization — configure Entra to send the sAMAccountName attribute instead. See Map SSO Groups to Authorization Groups for details.
4. If needed, add a new Authorization Group mapping for the user's IdP group.

To confirm exactly what group values your IdP is sending in the SAML assertion — and whether the attribute is present at all — see How to inspect your SAML assertion.

"Provider in Cognito not configured"

Monte Carlo received a successful SSO authentication from your IdP but the provider is not registered in Monte Carlo's system. This indicates an incomplete SSO setup.

To resolve:

Ask your Account Owner to contact Monte Carlo Support. This requires backend investigation to reconcile the IdP configuration, and cannot be self-served by a user who cannot sign in.

"AADSTS700016: Application with identifier was not found in the directory"

This Microsoft Entra ID error means MC's SSO configuration is still pointing at an Entra enterprise application that no longer exists or is no longer accessible in the tenant. During an IdP migration it typically means the old Entra app was removed or decommissioned before the new SSO metadata was saved in MC.

To resolve (Account Owner access required):

• If you are mid-migration to a new IdP: update the SSO metadata URL in Settings → Single sign on to point to the new IdP. If you are currently locked out, use your recovery user to sign in and correct the configuration — see SSO fallback and emergency access. A recovery user should be set up before making SSO changes for exactly this scenario.
• If you are not migrating: check in Entra that the Monte Carlo enterprise application is still active and that the metadata URL in MC matches the current application's metadata endpoint.

"Invalid SAML response received: Invalid user attributes: email: Required attribute cannot be deleted"

Cognito rejected the SAML assertion because the email attribute is missing or named incorrectly. Common causes:

• The IdP is sending a short attribute name such as email or Email instead of the full required URI: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
• This often occurs when migrating to a new IdP that uses different default attribute name conventions

To resolve:

Check your IdP's SAML attribute configuration against Required SAML attributes for all IdPs and use How to inspect your SAML assertion to confirm the exact attribute names being sent.

"Could not create SSO configuration. Failed to create identity provider"

This error occurs when trying to set up or re-configure SSO if a stale or orphaned Cognito identity provider entry already exists for your account — for example, after a previous SSO setup attempt failed partway through, or after deleting and trying to recreate the SSO configuration.

To resolve:

Contact Monte Carlo Support. The orphaned Cognito IdP entry needs to be cleared on the backend before you can complete the new SSO setup. Do not attempt to delete and recreate multiple times, as this can create additional stale entries.

"Could not update SSO configuration. duplicate key value violates unique constraint"

This error when saving SSO configuration changes usually means two user records in your account resolve to the same identity in your SSO provider — most commonly caused by a user who exists under two email addresses (for example, after a company domain change or rebrand where the old email was never removed from Monte Carlo).

To resolve:

1. Check Settings → Users for any user records on the old domain that may still be active.
2. Delete the stale user record from the old domain in Monte Carlo.
3. If the error persists after deleting the stale user, contact Monte Carlo Support — the old Cognito record may need to be cleaned up on the backend.

Okta users are provisioned via SCIM but SSO group mapping is not working

In Okta, Push Groups and Group Attribute Statements are two separate mechanisms that serve entirely different purposes — and both must be configured for full SSO + SCIM integration:

• Push Groups sync group membership from Okta to Monte Carlo via SCIM. They control which users are provisioned and which groups exist in Monte Carlo.
• Group Attribute Statements send group membership inside the SAML assertion at login time. They are what Monte Carlo reads to place a user in the correct Authorization Group when they sign in.

These two features are independent of each other. Configuring Push Groups alone does not enable SSO group mapping. If users are appearing in Monte Carlo (provisioning is working) but are landing in the wrong Authorization Group at login, Group Attribute Statements are likely missing.

To resolve:

1. In Okta, go to Applications → [your Monte Carlo application] → Sign On tab → Attribute Statements. In the Okta Identity Engine UI, group attribute statement fields may be under Show legacy configuration.
2. Add a Group Attribute Statement with:
   • Name: User.Groups
   • Filter: configure the filter to include the relevant Okta groups (for example, Starts with a common prefix, or a regex matching your Monte Carlo groups).
3. In Monte Carlo, go to Settings → Authorization groups and confirm each group has the correct SSO group name set — values must match exactly, including case.
4. Before asking users to sign in again, use How to inspect your SAML assertion to confirm the User.Groups attribute is now present in the assertion and that the group name values match what you have configured in Monte Carlo.
5. Have affected users sign out and sign back in to trigger re-evaluation with the new assertion.

See Map SSO Groups to Authorization Groups for the full setup guide.

User is prompted to create a password when SSO is expected

If a user is asked to set a password but your organization uses SSO, the account may not be linked to the SSO configuration. This can happen if the user was invited through a non-SSO path.

To resolve:

1. Close the tab and navigate directly to getmontecarlo.com/signin, enter your email, and follow the SSO flow.
2. If the problem persists, ask your Account Owner to delete the user account in Settings → Users and re-invite. The new invitation will be tied to the correct SSO configuration.

SSO stopped working after a certificate rotation

Cognito validates an inbound SAML assertion against any signing certificate present in the IdP metadata — adding a new certificate alongside the old one is safe and is the recommended zero-downtime rotation approach.

If SSO breaks after a rotation, the most common cause is stale metadata:

• When metadata is supplied by URL, Cognito caches it for up to ~6 hours — the new certificate may not be picked up until the cache expires.
• When metadata was supplied as a static blob (pasted XML), it is never refreshed automatically and must be updated manually.

To resolve:

1. Confirm with your IdP administrator that the new certificate is present in the metadata the IdP is currently serving.
2. In Settings → Single sign on, re-save the metadata URL (or paste the updated metadata blob) to force a refresh.
3. If sign-in is still failing after the cache window, ask your Account Owner to contact Monte Carlo Support.

SSO group changes aren't reflected in Monte Carlo

Authorization Group memberships obtained through SSO group mapping are only evaluated at login time. If a user's group membership changes in the IdP, they must sign out of Monte Carlo and sign back in before the change takes effect.

Similarly, if a push group in your IdP is updated (for example in Okta), the change is applied in Monte Carlo on the user's next login, not immediately.

To resolve:

1. Have the affected user sign out of Monte Carlo completely and sign back in via SSO.
2. If the correct groups are still not appearing after a fresh login, verify in your IdP that the user is in the expected groups and that those groups are being pushed in the SAML assertion. Use How to inspect your SAML assertion to capture the assertion during a live login and confirm the group values are present and correctly named.

SSO users are landing in the wrong Authorization Group

If SSO users are consistently being placed in a group they should not be in, the likely cause is the Default authorization groups setting in your SSO configuration. This setting is a fallback — it applies only when a user matches no SSO group mapping on login. It does not override explicit group assignments.

To resolve (Account Owner access required):

1. Go to Settings → Single sign on and review the Default authorization groups value.
2. If you are using push groups (Okta) or SSO group mapping to assign users, consider setting the default to a minimal-access group or "None" so that push group assignments are authoritative.
3. Ensure the push group names in your IdP match Monte Carlo group names exactly, including case. Use How to inspect your SAML assertion to see the exact AttributeValue strings your IdP is sending — these must match your Authorization Group SSO group name settings character-for-character.

Configuring SSO for multiple Monte Carlo environments with Microsoft Entra ID

Monte Carlo uses a fixed Entity ID for all accounts. Microsoft Entra ID enforces that Entity IDs are unique per application within a tenant, which means you cannot create separate Entra enterprise applications for each MC environment — Entra will reject any attempt to register a second application with the same Entity ID.

The supported approach is to use a single Entra enterprise application shared across all Monte Carlo accounts, and use Authorization Group mapping to control which users can access each account:

1. Configure the single Entra application once per the Setting Up Single Sign-On guide.
2. Assign the application to all MC environments.
3. In each MC account, set the Default authorization groups to None in Settings → Single sign on — this prevents users from gaining access to an account they should not have.
4. Use SSO group mapping to grant access explicitly: create Authorization Groups in each MC account and map them to the corresponding Entra groups. See Map SSO Groups to Authorization Groups.

📘

Note on SCIM with multiple environments

SCIM provisioning with Entra ID requires a separate enterprise application per MC environment. This is a separate concern from SSO — you can use SSO group mapping (shared app) alongside separate SCIM apps per environment.

Migrating to a new identity provider

Switching your SSO configuration from one IdP to another has three common failure modes:

1. Attribute names differ between IdPs

Each IdP has its own default attribute name conventions. MC requires specific URI attribute names regardless of which IdP you use — do not assume the new IdP will send attributes the same way as the old one. Verify the new IdP's attribute mapping before cutting over. See Required SAML attributes for all IdPs and How to inspect your SAML assertion.

2. The cutover is immediate

Saving new SSO metadata in Settings → Single sign on takes effect instantly — if the new configuration is wrong, all SSO users are locked out immediately. Before switching, request a recovery user from Monte Carlo Support so you can regain access without needing Support intervention if something goes wrong. See SSO fallback and emergency access.

3. SSO group mapping must be reconfigured for the new IdP

Authorization Group mapping configured for the old IdP will not carry over automatically. Each IdP sends group attributes differently, and the values your new IdP sends may not match what is configured in Monte Carlo. If group mapping is not reconfigured before the cutover, all users will fall back to the Default authorization groups setting on their next login and may appear to lose access.

Before switching, verify in your new IdP's admin console that the group attribute name and filter are configured correctly — many IdPs provide a SAML preview or test tool that shows you what would be sent without requiring a live login. For full setup guidance see Map SSO Groups to Authorization Groups. If users land in the wrong group after the cutover, use How to inspect your SAML assertion to confirm what the new IdP is actually sending.

Company email domain change or rebrand

When your organization changes its email domain — for example, a rebrand from oldcompany.com to newcompany.com — Monte Carlo treats the old and new email addresses as completely separate user accounts. Emails are the unique user identifier in MC and cannot be renamed or migrated.

What happens on first login with the new email:

Users signing in with their new email address for the first time will have a new MC account created via JIT SSO. Their Authorization Group will be assigned based on your SSO group mapping, the same as any new user. They will not inherit settings, API keys, or preferences from their old account.

What to do (Account Owner access required):

1. Update the SSO domain in Settings → Single sign on to include (or replace) the old domain with the new one before users start signing in with new addresses.
2. Confirm your SSO group mapping is configured for the new domain — users signing in for the first time will be assigned groups based on what the IdP sends at login.
3. Once users have signed in with their new email and confirmed access is correct, deactivate their old accounts in Settings → Users to avoid duplicate records.
4. If any automated processes or integrations use API keys tied to old user accounts, those keys will need to be regenerated under the new accounts.

The "duplicate key value violates unique constraint" error:

If both the old and new email domain accounts exist in MC at the same time and both resolve to the same identity in your IdP, you may see this error when trying to save SSO configuration changes. To resolve it, delete the stale user record for the old domain first — see "Could not update SSO configuration. duplicate key value violates unique constraint".

New user sign-up and invite issues

"There was an error attempting to sign up. Please try again later or contact support."

This catch-all sign-up error has two common causes:

• VPN or firewall blocking authentication endpoints — see the network issue guidance above.
• Stale invitation link — invitations expire after 7 days. Ask your Account Owner to resend the invite and use the new link promptly.

"This invitation has already been accepted. Please sign in with your email"

The invitation link was already used to complete sign-up. You already have a Monte Carlo account.

To resolve:

• Sign in at getmontecarlo.com/signin.
• Use Forgot password if you don't remember your password.

"The invitation has expired"

Monte Carlo invitations expire 7 days after being sent.

To resolve:

Ask your Account Owner to resend the invitation and click the new link promptly after it arrives.

"You've received an invitation. Please use the invitation to confirm your identity"

You have a pending invitation but tried to sign up without clicking the invitation link. Check your inbox (and spam folder) for an invitation email from Monte Carlo and click Accept invitation.

"Invalid invite token" / "Invalid invite state"

The invitation token is incorrect or the invitation was invalidated. This commonly happens when:

• The user was deleted and re-invited while a stale record remained
• Multiple invitations were sent and an older link was used

To resolve:

1. Ask your Account Owner to cancel any existing invitations for the email address in Settings → Users and send a fresh invitation.
2. Use only the most recent invitation email.
3. If the problem persists after a fresh invite, ask your Account Owner to contact Monte Carlo Support — resolving this may require cleanup in the authentication backend.

"Too many failed invite validation attempts"

The invitation was used too many times with incorrect details and has been automatically invalidated as a security measure.

To resolve:

Ask your Account Owner to send a new invitation.

SCIM or SSO is not automatically recreating a previously removed user

Monte Carlo soft-deletes users when they are removed from an account. A subsequent JIT SSO login or SCIM provisioning event will not automatically recreate a previously deleted user. Provisioning tools do not resurrect deleted records.

To resolve:

A fresh invitation is required to restore access:

1. An Account Owner must re-invite the user via Settings → Users → Invite.
2. The user accepts the new invitation and completes the sign-up flow.
3. Once the account is recreated via invite, SSO login and SCIM sync will both work normally. Select None as the group when re-inviting on SSO accounts — SSO group mapping will assign the correct group on first login.

SCIM provisioning issues

📘

SCIM setup documentation

For full setup instructions, see SCIM Provisioning.

SCIM-provisioned user cannot sign in (no SSO configured)

If your organization uses SCIM to provision users but does not use SSO, provisioned users will not have a Monte Carlo password set automatically. They need to create a password before they can sign in.

To resolve:

1. Navigate to getmontecarlo.com/signin.
2. Enter the email address that was provisioned via SCIM.
3. Select the password sign-in option.
4. Click Forgot password and follow the password reset flow to set a new password.
5. Check the email inbox for the reset email (and spam folder).

SCIM provisioning has stopped working

If SCIM provisioning was working and then stopped, the most common cause is that the SCIM bearer token has expired or been rotated.

To resolve (Account Owner access required):

1. Go to Settings → SCIM in Monte Carlo and generate a new endpoint token.
2. Update the bearer token in your IdP's SCIM provisioning settings with the new value.
3. Use the Test connection option in your IdP's SCIM settings to verify the token is accepted. Both Okta and Microsoft Entra ID provide this — it sends a test request to the endpoint and confirms the token is valid before you trigger a full sync.
4. Trigger a manual sync in your IdP to confirm provisioning is working again.

If the token is valid and provisioning is still failing, check the provisioning error logs in your IdP for the specific error message.

SCIM provisioning is failing with "email already belongs to a user"

Before assuming a duplicate user problem, check your SSO domain configuration. A malformed or partial domain entry in Settings → Single sign on (for example, company instead of company.com) can silently break SCIM user association and produce this error even when no actual duplicate user exists.

To resolve (Account Owner access required):

1. Go to Settings → Single sign on and review the domains list.
2. Remove any entries that look like partial or bare domain names (e.g., just company instead of company.com).
3. Retry the SCIM provisioning operation.
4. If the error persists after checking domain configuration, contact Monte Carlo Support.

SCIM-provisioned user does not appear in Monte Carlo yet

Changes made in your IdP — such as adding a user or updating a name — are not sent to Monte Carlo instantly. The IdP controls when it syncs those changes:

• Okta typically syncs within a few minutes.
• Microsoft Entra ID can take up to 40 minutes to sync changes, depending on your tenant configuration.

Monte Carlo reflects changes as soon as it receives the request from the IdP. If the user has not appeared after the expected sync window, trigger a manual sync in your IdP's provisioning settings.

SCIM-provisioned user was unexpectedly removed

If a user who should have access is not appearing in Monte Carlo, they may have been deprovisioned from the IdP application — either intentionally or accidentally.

To resolve:

1. Check in your IdP that the user is still assigned to the Monte Carlo application and is active.
2. If they were removed from the IdP application, re-add them and trigger a manual sync.
3. If the user should have permanent access regardless of IdP group membership, consider also inviting them directly in Monte Carlo (Settings → Users → Invite) as a fallback.

SCIM-provisioned user has incorrect permissions or is missing access

When SCIM creates a new group in Monte Carlo, it is assigned the default role and domain restrictions configured in Monte Carlo's SCIM settings — not in the IdP. If those defaults are not correct for all groups, permissions may not match expectations.

To resolve (Account Owner access required):

1. Go to Settings → Authorization groups and review the role and domain assignments for the affected group.
2. Update the role and/or domains as needed — you can override the SCIM defaults at any time.
3. For future groups, update the SCIM default role in Settings → SCIM to reflect the intended baseline.

Password reset issues

Not receiving a password reset email

The password reset form always shows a success message regardless of whether the email address is registered — this is intentional and protects account privacy.

If you do not receive an email within a few minutes:

1. Check your spam or junk folder.
2. Confirm you are using the exact email address associated with your Monte Carlo account.
3. If your organization uses SSO, you do not have a Monte Carlo password to reset — sign in via your company's SSO provider by entering your email on the sign-in page.
4. Ask your IT team whether emails from @montecarlodata.com are being filtered or blocked.

"Error trying to reset password. Please check your e-mail"

The password reset link is missing required parameters — usually because a link-rewriting email client broke the URL.

To resolve:

Go back to the sign-in page, click Forgot password, enter your email, and request a new reset link. Click directly from your email client; do not copy and paste the URL.

"Could not reset your password. Please contact us."

The password reset code has expired or was already used.

To resolve:

1. Request a new password reset from the sign-in page.
2. Complete the process promptly after receiving the email — codes expire after a short window.
3. If the issue persists, contact Monte Carlo Support.

Password doesn't meet requirements

Monte Carlo's password policy requires at least 8 characters, including one uppercase letter, one lowercase letter, one number, and one symbol. Update your password to meet these requirements and try again.

I use separate email addresses per environment (plus-addressing)

If you use plus-addressed email aliases to access multiple Monte Carlo environments — for example, [email protected] for production and [email protected] for development — each address is treated as a completely separate user account in Monte Carlo's authentication system.

This means:

• Resetting the password for one address does not affect the other.
• Each address requires its own invitation, acceptance, and group membership.
• Each account has separate API keys.

Manage each address independently as if it were a different user.

Not receiving emails from Monte Carlo

Emails from Monte Carlo (invitations, password resets, notifications) are sent from @montecarlodata.com. If you are not receiving expected emails:

1. Check your spam or junk folder.
2. Search for emails from montecarlodata.com — some clients thread or filter them unexpectedly.
3. Ask your IT team to confirm that @montecarlodata.com is not on a block or quarantine list.
4. Confirm that your email address in Monte Carlo is correct — an Account Owner can check Settings → Users.
5. If you use SSO, most Monte Carlo workflows do not require email confirmation — sign in via SSO directly.

SSO fallback and emergency access

What happens if SSO becomes unavailable?

If your SSO provider experiences an outage, users who rely on SSO will not be able to sign in until SSO is restored. To plan for this scenario, Monte Carlo can create a recovery account for your organization: a separate user with email/password authentication that is not subject to SSO enforcement, allowing sign-in even when SSO is unavailable.

Recovery accounts can only be created by Monte Carlo Support — they are not self-service. Contact Monte Carlo Support to request one. When requesting, provide an email address outside your SSO-covered domain (for example, a +recovery alias). Once created, store the credentials securely in your organization's password manager. The recovery account can be used to sign in and make SSO configuration changes if the primary SSO path is broken.

📘

Proactive setup recommended

This is a step to take before an SSO outage, not a self-service action during one. We recommend setting it up as part of your SSO onboarding.

Account Owner accidentally lost admin access after configuring SSO groups

Adding an SSO group mapping to an Authorization Group replaces existing manual user assignments — members of that group who don't belong to the mapped SSO group in the IdP may lose their access on their next login. If an Account Owner accidentally removes themselves from the account this way, they will not be able to self-recover.

To resolve:

Contact Monte Carlo Support with the Account Owner's email address and your account name. Support can restore Account Owner access without requiring a sign-in.

Duplicate or conflicting accounts

I have two Monte Carlo accounts (email/password and SSO)

This typically happens when a user created an email/password account before their organization enabled SSO. After SSO was configured, a second SSO-linked account was created for the same person.

Symptoms include:

• Seeing different data or group memberships depending on how you sign in
• Being prompted to choose between two sign-in methods

To resolve:

Contact Monte Carlo Support with the email address(es) associated with both accounts. Account consolidation requires backend assistance.

Access issues after signing in

If a user can sign in but is missing access to features, data, or settings, the cause is almost always their Authorization Group configuration.

For deeper investigation of allow/deny results — for example, a user has the right role but a specific action is still denied — see Authorization for how policy statements, roles, and domains interact.

Still need help?

If you can sign in, use the in-app Support Agent (click the ? icon at the bottom of the app) or visit getmontecarlo.com/support to open a ticket directly. Full documentation on the support process is available at docs.getmontecarlo.com/docs/in-app-support.

If you cannot sign in, you cannot access the in-app support agent. Ask your Account Owner to open a support ticket on your behalf — they have access to Monte Carlo and can describe the issue and provide your email address to the Support team.