Summary: This article is for users who sign in to AXP via Single Sign-On (SSO) through their organisation — for example, clicking Login with SSO or being redirected via your company's Microsoft or Okta login. If you log in with an email address and password instead, this article doesn't apply to you — see Why Can't I Log In to AXP via Email and Password? instead.
If you're an SSO user seeing an error, it's usually down to one of three scenarios below:
Your account was previously removed and needs recreating - your Brand Admin can fix this directly in AXP.
Your sign-in record is out of date - your Brand Admin can also fix this directly in AXP.
Your organisation's IT team hasn't added you to the right access group yet - this needs your own IT team, as it is outside of AXP
Permissions Required:
Only a Brand Admin or IT Admin can carry out the fix depending on the scenario.
Error: "Request failed with status code 412" or "422"
What you'll see: "Your SSO sign-in worked, but we couldn't access your AXP account. Please contact your property's AXP Brand Admin — they may need to request a re-invite or reset for your account." (You may see this with either status code 412 or 422 — both mean the same thing and have the same fix.)
or
What it means: Either your AXP account was previously removed and needs recreating, or your sign-in record is out of date. Only your Brand Admin can fix this — it isn't something you can do yourself.
If you're the person who can't log in:
Take a screenshot of the error message.
Reach out to your Brand Admin and let them know the email address you're trying to log in with.
After your admin confirms they've taken action to fix your account, clear your browser's cache and cookies, then try logging in again.
Still stuck? Let your Brand Admin know — they can seek help from the support team, along with the actions they've already taken.
If you're the Brand Admin fixing this:
Get the exact email address the person is trying to log in with.
Go to Settings > Users in AXP. Set the filter as 'All locations'.
Search for that email address.
Depending on what you see, do one of the following:
No matching user shows up:
Click + Invite User, confirm the email address and brand, then confirm.
This adds them back to AXP, though with no role assigned yet — open their profile and assign the right role so they have full access. See What Is "No Role" (Null User) Status in AXP for more on this.
Ask them to clear their browser's cache and cookies, then try logging in again.
An account with that email address shows up, but they still can't log in:
Still no luck? If they don't show up even after being invited, or resetting their identity doesn't help, this is likely the "We couldn't sign you in to AXP" error below instead — ask them to check with their own IT team.
Error: "We couldn't sign you in to AXP"
What you'll see: "We couldn't sign you in to AXP. Please ask your property's IT team to add you to the correct SSO group, then try logging in again."
You might also see an error from your organisation's own login screen before you even reach AXP — for example, a Microsoft sign-in screen with an error message like: "Your administrator has configured the application Alliants Experience Platform to block users unless they are specifically granted access to the application. Please contact your administrator to assign access to this application."
Both point to the same underlying issue below.
What it means: Your organisation's IT team hasn't added you to the correct SSO access group yet. This isn't something AXP, AXP support, or your Brand Admin can fix — it has to happen on your organisation's side.
Steps to fix it:
Take a screenshot of the error message.
Contact your property's IT manager, or whoever manages your organisation's SSO system, and ask them to grant your account access to AXP. Include the screenshot.
Once your IT team confirms they've made the change, try logging in to AXP again via SSO.
If you're still unable to log in after your IT team has made the change, contact your AXP support team and let them know the steps already taken.
Common Questions
Q: How do I know which error applies to me?
A: Check the exact wording on your screen and match it to one of the sections above. If you're not sure, take a screenshot and share it with your Brand Admin — they can tell you which one it is.
💡 Tips: If you're not sure who your Brand Admin is, ask your IT manager.
Q: As a Brand Admin, how do I know whether to use "Re-invite user" or "Reset Cognito identity"?
A: Search their email under Settings > Users first. If nothing comes up, use + Invite User. If they do show up but still can't log in, use Reset Cognito identity from their ··· menu instead.
Q: Is "Reset Cognito identity" safe to use? What does it actually do?
A: Yes, it's safe. It just clears out the person's sign-in record with our identity provider so it gets rebuilt fresh the next time they log in. Their AXP profile, role, and history aren't touched at all.
Q: If a Brand Admin re-invites someone, do they lose any of their existing data?
A: No. Re-inviting adds them back to AXP, but they'll come back with no role assigned at first (sometimes shown as a "null user"). The Brand Admin will just need to assign them a role afterwards so they have full access again. See What Is "No Role" (Null User) Status in AXP for more on this.
Q: I've been using AXP before — why is this happening now?
A: This can happen if your organisation has made changes to their SSO configuration, such as reorganising teams, offboarding or onboarding users, or updating access permissions. Even if you had access previously, your account may have been removed or moved to a different group.
Q: Can AXP support fix the "status code 424" issue for me directly?
A: No — access permissions within your organisation's SSO system are managed entirely by your IT team. AXP support can't make changes to your company's identity provider. Your IT team is the right people to contact. If they need further technical detail about how AXP integrates with your SSO, they can liaise directly with AXP support.







