Okta and Azure AD SSO setups on Acumatica look nearly identical from the outside - both configure through the same SAML/OIDC provider screens in the Site Map - but the two identity providers surface genuinely different gotchas in practice, and Okta's are specifically around group-to-role mapping and how it handles deprovisioning. This is what I've run into standing up Okta SSO for a few clients, distinct from the Azure AD side of things.
Pick SAML or OIDC deliberately, not by whichever Okta app template loads first
Acumatica supports both SAML 2.0 and OpenID Connect for federated login, and Okta can act as the identity provider for either. I default to OIDC for new setups now - it's the newer, simpler protocol to debug when something goes wrong, and Okta's OIDC app integration wizard maps more directly onto Acumatica's connected-application concept. SAML is still the right call when the client already has a mature Okta SAML app catalog and IT wants to stay consistent with how every other SAML-federated app in the org is configured; forcing OIDC purely for its own sake onto an org standardized on SAML creates an inconsistency their identity team then has to explain.
Okta group claims need an explicit mapping step Acumatica doesn't do for you
The part that trips people up: Okta can push group membership into the SAML assertion or the OIDC ID token as a claim, but Acumatica doesn't automatically translate an Okta group name into an Acumatica role. That mapping is your responsibility, done either through Acumatica's SSO configuration screen (mapping claim values to roles) or, for anything more conditional than a straight name match, in code:
protected virtual void _(Events.RowInserted<Users> e)
{
if (e.Row == null || !IsSsoProvisionedUser(e.Row)) return;
var oktaGroups = GetClaimValues(e.Row, "groups"); // pushed from Okta token
if (oktaGroups.Contains("Acumatica-AP-Clerks"))
AssignRole(e.Row.Username, "AP Clerk");
if (oktaGroups.Contains("Acumatica-Finance-Managers"))
AssignRole(e.Row.Username, "Finance Manager");
}
Skip this step and every SSO-provisioned user lands with whatever default role your connected application config assigns - usually far too permissive or far too restrictive, and either way, not what the client's Okta group structure was supposed to express.
SSO login working is not the same as deprovisioning working
Clients evaluating Okta SSO almost always focus the demo on login working smoothly, and almost never ask upfront how a departed employee's Acumatica access actually gets revoked. SAML/OIDC federated login authenticates against Okta, but unless you've also wired Okta's SCIM provisioning (or a scheduled sync job) to deactivate the corresponding Acumatica user record, deactivating someone in Okta stops them from getting a fresh SSO token - it does not touch an already-active Acumatica session, and depending on session timeout configuration, that can be a meaningfully long window.
I now ask every client explicitly, before SSO goes live: when someone is terminated in Okta, what deactivates their Acumatica account, and how fast? If the honest answer is "nothing does, automatically," that's a gap worth fixing with SCIM provisioning or a nightly reconciliation job before the SSO project is called done, not after HR asks why a terminated employee's ERP session was still active three days later.
Keep a non-SSO admin path, deliberately, and lock it down separately
Every Okta SSO rollout I've done keeps exactly one local admin account outside the SSO flow, with a strong password and MFA on the account itself, specifically for the day Okta has an outage or the SSO configuration gets misconfigured and locks everyone out simultaneously. This account should not be a convenience back door for daily use - it's a break-glass account, and I document it as one explicitly so a future admin doesn't quietly start using it as their regular login and defeat the point of having SSO at all.
Wrapping up
Okta SSO on Acumatica is straightforward on the login path and easy to get wrong on the two things that aren't login: mapping Okta groups to Acumatica roles explicitly rather than trusting a default, and making sure deprovisioning in Okta actually revokes Acumatica access rather than just blocking new tokens. Confirm both before calling the integration done, and keep one deliberately separate break-glass admin account for the day the identity provider itself is the thing that's down.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.