Acumatica Report Designer Doesn’t Work With SSO – Here’s Why, and How to Fix It
A practical guide for Acumatica and JAMIS Prime administrators on SSO-only (Entra ID / Okta / ADFS / FedRAMP) tenants.
TL;DR – Acumatica’s desktop Report Designer cannot log into an SSO-only
site. It only supports native (Acumatica) and LDAP/Active Directory credentials,
and its login dialog treats@as the tenant separator, so an email-format
username is mis-parsed. This is an Acumatica platform limitation that has been on
the record since 2018 and has not changed through 2025 R2. The common
workaround – build the report on a second site, wrap it in a customization
project, export the ZIP, re-import on the live site, publish, repeat for every
change – is the standing tax on every report edit. There is a better way. The
limitation is entirely client-side in Report Designer’s login dialog;
Acumatica’s own server APIs (/reports, OAuth bearer) take the tenant
out-of-band and don’t care about the@parsing. Any approach that bypasses the
desktop login dialog bypasses the whole problem. Three such approaches exist –
move, bridge, and studio – described below.
Does Acumatica Report Designer work with SSO?
No. Out of the box, Acumatica Report Designer does not work with single
sign-on. Acumatica’s own published guidance states that Report Designer (and
DeviceHub) support only native Acumatica accounts and LDAP / Active Directory
credentials – there is no Entra ID, Azure AD, Okta, ADFS, SAML, OIDC, or generic
OAuth login path in the desktop tool. On a tenant where users sign in exclusively
through SSO, there is no password to type into Report Designer’s login box, so it
simply cannot connect.
This is not a misconfiguration on your side and not something a customization or a
setting can switch on. It is a limitation of the desktop Report Designer client
itself, confirmed repeatedly by Acumatica support and unchanged across releases.
Why can’t I log into Report Designer with my email address?
Because Report Designer’s login dialog parses the @ character as the
tenant (company) separator, not as part of an email address. The desktop tool
expects a username in the form loginID@TenantName. When you type an
email-format username such as [email protected], the dialog splits it at the
@ and treats everything after it as a tenant name that does not exist – so the
login simply fails rather than telling you the real problem.
Two things follow from this:
- Email usernames are structurally broken in Report Designer. Even on a site
that still has native accounts, if your usernames look like email addresses,
the@-parsing works against you. - The “SSO button” in the desktop tool does nothing useful for you. Where any
SSO affordance appears, the credentials it would produce are not credentials
Report Designer can actually authenticate with against the report surface. The
button is effectively a dead end for SSO-only sites.
As of 2025 R1 and later, multi-tenant instances still require the login@Tenant
form; the only related change in 2025 R1 was dropping the tenant suffix for
single-tenant instances. The @-as-separator behavior remains.
Why is Report Designer blocked even with a native account and 2FA?
It gets worse than “use a native account instead.” On many secured tenants, a
native Acumatica account that has built-in two-factor authentication enabled is
also blocked from Report Designer’s login surface. That means the workaround
account has to be native AND 2FA-exempt at the same time – which is exactly the
kind of account a FedRAMP, CMMC, or generally security-conscious posture is
designed to eliminate. So the “just use a local account” advice quietly asks you to
create the one kind of account your security policy forbids.
On top of that, Report Designer’s version must exactly match the target site
build. If your development site and your production site are on different builds,
you need two separate Report Designer installations to author against each.
How do I edit reports on a FedRAMP (SSO-only) Acumatica site today?
The workaround almost everyone ends up using – and hating – looks like this:
- Build or fix the report on a second site that still allows native login
(a development or scratch tenant). - Wrap the report in a customization project so it can be carried between
sites. - Export the customization project to a ZIP file.
- Re-import that ZIP on the live SSO site.
- Publish and test.
- Repeat the entire loop for every single change – every logo swap, every
field, every label, every formula tweak.
Around that core loop sit additional standing costs on SSO-only and FedRAMP
tenants:
- A separate test/development site frequently has to be provisioned and then
SSO-enabled by the client’s own IT team before authoring can even begin –
often with multi-week lead times. - The 2FA-exempt native account problem above, if anyone tries to shortcut the
loop with a local login. - The version-match requirement, which can mean maintaining two Report
Designer installs.
This is not one annoying ticket. It is a tax on every report change, forever, for
every SSO-only client.
Why hasn’t Acumatica fixed Report Designer SSO?
Because, on the record, it is not on their roadmap – and has not been for years:
- Acumatica’s own developer blog (2022) states that Report Designer and
DeviceHub support only Active Directory (LDAP) and native Acumatica
authentication. - Acumatica support, answering a case directly, put it plainly: the report
designer only supported native users. - An MVP / community confirmation corroborates that the SSO-button credentials
cannot be used to log into Report Designer. - The limitation has been documented in the community since 2018 – including an
organization that authenticated only through Google OAuth2 asking Acumatica to
open-source Report Designer so they could fix it themselves. - No authentication change shipped through 2025 R2. The “redesigned report
designer” in recent releases is a layout/UX refresh – it does not add SSO to the
login path.
So this is a genuine, durable gap in the platform, not a temporary bug awaiting a
patch. And notably, no vendor, VAR, or community project in the Acumatica
ecosystem ships a Report Designer SSO fix. The nearest analogous prior art solves
a different surface (an Excel add-in’s “Sign in with Acumatica”), not Report
Designer. The gap is open across the entire SSO-only Acumatica install base.
What actually makes this solvable?
The reframing insight: the limitation lives entirely in Report Designer’s
client-side login dialog. Acumatica’s server surfaces take the tenant
out-of-band:
- The OAuth bearer-token flow doesn’t care about the
@-username parsing at all. - The Report Designer report API (
/reports) accepts and returns report
definitions under an authenticated session, regardless of how that session was
obtained. - Tenant selection can be expressed on the server leg of the connection rather
than being crammed into a desktop username field.
So the real problem is not “make Report Designer’s login dialog speak SSO.”
It’s “bypass the desktop login dialog entirely and authenticate through the
SSO/OAuth path the server already supports.” Once you frame it that way, several
working approaches open up.
What are the ways to fix Report Designer SSO?
There are three complementary approaches. They share the same underlying parts
(OAuth/OIDC sign-in, the report API, byte-fidelity report validation, and an
evidence/verification step), and they differ mainly in how much of the existing
Report Designer experience you keep.
1. Move – kill the export/import loop directly
Keep designing reports in the real Report Designer against any native-auth
development site you control. Then, instead of the customization-project ZIP loop,
run a single command that:
- pulls the report definition from the dev site (with an automated
customization-export fallback for the pull leg), - validates it (byte-fidelity, against the field/schema catalogs),
- publishes it to the SSO/FedRAMP site through Acumatica’s own report API under an
OAuth browser sign-in (your SSO user signs in interactively, once), and - emits an evidence packet recording exactly what was validated and pushed.
Change a report? Re-run the command. No customization project, no export ZIP, no
second publish cycle. You still design on a dev site, but the maddening
round-trip dies. This is the fastest path to relief and the cheapest to stand up.
2. Bridge – run the real Report Designer against your SSO site
A small loopback proxy runs on the authoring workstation, inside your security
boundary. It holds an OIDC (Entra / Okta / ADFS) session to your live site, signed
in through your normal SSO + MFA flow in the system browser. Report Designer is
pointed at http://127.0.0.1:<port> with a dummy, non-@ username, and the proxy
forwards every request to the real site with the upstream session attached.
The desktop-typed username is discarded – it never reaches the server, so it
can never be mis-split on @. The author keeps the exact Report Designer they
already know, with full functionality, and there is no second site and no
export/import loop at all. Because it runs loopback-only on the in-boundary
workstation and holds tokens in memory only, it is designed to fit inside a FedRAMP
boundary.
3. Studio – dissolve the problem with an SSO-native editor
A browser-based report editor where SSO is the front door, not the obstacle –
because it is a web app, your Entra/OIDC login is the happy path by construction.
It loads a report, lets you edit it with form- and tree-based controls, and
validates the result offline against the field/schema catalogs – only a
parse-clean report can be published. Publishing itself stays deliberately
operator-fired: the studio hands you the exact one-command publish to run under
your OAuth sign-in, so a human stays in the loop on every change. Scoped to the most common
real-world need – modify an existing report (logo, field, label, formula,
section) and generate standard variants – it can be a better experience than the
desktop tool for those cases, with validation and verification built into the loop.
How they relate: Move is the immediate pain-killer. Bridge gives you the
full desktop tool against the live SSO site. Studio is where the approach
compounds into a managed, SSO-native product. They reuse the same proven plumbing,
so they’re a portfolio, not competing bets.
What’s the honest maturity of this – does it actually work?
Straight answer, because credibility matters more than hype:
- The core is proven in the lab. The OAuth sign-in, the report-API publish, the
byte-fidelity report validation, and the verification step have been built and
tested, and the publish round-trip has been validated live against a vanilla,
native-auth Acumatica sandbox. - Live SSO/FedRAMP validation is pending – and we will not claim otherwise.
The same round-trip over an OIDC/SSO-fronted site, with the real desktop Report
Designer driving it, has not yet been validated. It is the next step, and it
needs a sanctioned validation window – not a poke at anyone’s production site. - We do not test against your production. The approach is designed so that you
validate your own production site; we hand over a validated tool plus a checklist.
In short: this problem is solved in principle and the approach is validated in
our lab – it is ready to validate on your site. That is a very different (and
more honest) claim than “download this and it works on FedRAMP today.”
What does the evidence/verification packet give me?
Every change can ship a verification packet: a parse check, a
vanilla-vs-changed diff, a side-effect/readiness screen, and a render/regression
check – that last one a human validation step the packet gates and records.
For a change-control reviewer – exactly the kind a FedRAMP or CMMC
environment requires – that means the report change is provably the intended
one, not just “trust me, I edited it.” Verification is the point, not an
afterthought.
FAQ
More questions are answered in the companion FAQ: Acumatica Report Designer + SSO – Frequently Asked Questions.
Is this supported by Acumatica? Are you modifying Report Designer?
No and no. Acumatica does not support SSO for Report Designer – that is the whole
reason the problem exists. None of the approaches modify, patch, or repackage
Report Designer. The bridge is a separate loopback proxy; Report Designer runs
unmodified and just points at a local address. The move approach uses Acumatica’s
own documented report API and OAuth – the same surfaces Acumatica ships for
programmatic access. So nothing depends on Acumatica supporting something they have
said for years they won’t; the approach works with their supported server APIs
and around the unsupported desktop login dialog. It is third-party
consulting/tooling, not an Acumatica product feature, and carries no Acumatica
support entitlement.
Does my data leave my security boundary?
No. The bridge is a pass-through proxy between your workstation and your own
Acumatica site – both inside your boundary. There is no external/third-party server
in the data path. Report bodies are forwarded as-is and not persisted by the
bridge; tokens live in memory only and never touch disk.
Do I need a native or 2FA-exempt account?
No – avoiding that policy-violating workaround account is a core point of the
approach. Authentication is your normal SSO user completing an interactive browser
sign-in with MFA. There is never a need for a native account or for 2FA to be
turned off.
Is this just the customization-project export/import loop with extra steps?
No – it eliminates that loop. That loop is the status-quo pain this removes. The
move approach publishes directly to the SSO site via the report API in one command
(the customization-export path is kept only as an automated fallback). The bridge
removes the second site entirely.
What happens at version upgrades?
Report Designer is version-matched to the site build – that’s an Acumatica
requirement, not ours, and the approach doesn’t add to it. A major site upgrade
(e.g. a v8→v9 or a 2026 Rx jump) is a re-validation event: the tooling should be
re-checked against the new build before the next change, because login or API paths
can shift between major versions.
What if Acumatica eventually fixes it – do I lose the investment?
Unlikely on the timeline that matters (no auth change shipped through 2025 R2, and
vendor attention is on the 2026 R2 migration cycle). And even if they did ship SSO
for Report Designer, the move approach and the verification layer stay valuable –
they kill the export/import loop and ship change-control evidence regardless of how
the desktop tool authenticates. The studio is SSO-native by construction and
unaffected. The part most exposed to a vendor fix is structured as a cancellable
support subscription, not a large up-front build.
Has this run against a real FedRAMP/SSO site yet?
Not yet, and we will not say otherwise. It is proven in the lab and validated live
against a non-SSO sandbox. The OIDC/SSO leg is the pending validation step.
Related: if the reporting pain at your site goes past Report Designer – an
ERP and a second operational system that never agree on the same numbers –
the unowned layer between them is its own solvable problem, covered in our
companion guide: When Your ERP and Your Second System Don’t Talk –
Owning the Data Layer Between Them.
Next step
If you administer an SSO-only Acumatica or JAMIS Prime tenant and you are living
the Report Designer login wall and the export/import loop, this is solvable – and
we would rather show you a validation than sell you a claim.
Get in touch to arrange a walkthrough and a sandbox validation on your terms.
Contact
A walkthrough and a sandbox validation, on your terms – we would rather show you a validation than sell you a claim.
Or email [email protected].