Why can't a user get into the platform? ("Permission Denied", "Your email is not allowed", SSO)
The message on the screen usually tells you the cause. Match it with the cases below before resetting passwords or creating new accounts.
"403 – Permission Denied"
The page says You don't have the required permission to access this page. The user signed in, but their account does not have the Regular User profile, which every user needs to use the platform.
Fix: open the user in the Backoffice and check their roles. Make sure Regular User is included, then save. If the profile was removed on purpose, confirm with your organisation before adding it back.
"Your email is not allowed. Please contact support."
Your platform only accepts registrations from approved emails (a whitelist), and this email is not approved. This also happens with company sign-in (SSO): the first time a person signs in, the platform creates their account, and the whitelist applies to that registration.
Fix: add the email, or a rule that covers it, to the whitelist:
the General Whitelist, under Community Management, or
the whitelist of the group or team the person should join.
Rules can use wildcards, for example *@yourcompany.com for everyone with a company address. Administrators can edit the whitelists; a group manager can edit the whitelist of their own group.
Company sign-in (SSO) works but the user reaches the wrong account, or a registration page
The platform matches the SSO account to a GFoundry account by email address. If the email sent by your identity provider is different from the one in GFoundry, for example after a change of company domain, the platform does not find the account. Update the user's email in GFoundry to the one used by your identity provider.
If the error screen comes from your company's sign-in page (Microsoft, Google or another provider) rather than from GFoundry, the cause is on your identity provider's side. Contact your IT team.
The account is inactive
If your users are created by an HR integration, a user who is no longer in the HR file is deactivated at the next synchronisation. Users with Backoffice roles, and users created directly in the Backoffice, are not deactivated this way. Check with your HR team that the person is in the file.
What not to do
Do not create a second account for the same person to get around the problem. Fix the role, the whitelist or the email of the existing account.
When should I contact Support?
Contact Support when the user has the Regular User profile, their email is covered by the whitelist, and they still cannot get in. Include the user's identifier, how they sign in (email and password or company sign-in), the exact message and a screenshot.
Related articles
Company codes and whitelists: how whitelists work.
Edit User: general information, backoffice roles, segmentation, and permissions: where the user's roles are.
Why can a user sign in but not see a module, cycle, or action?: when sign-in works but something is missing.