Acumatica Report Designer + SSO – Frequently Asked Questions
Honest answers for administrators of SSO-only (Entra ID / Okta / ADFS / FedRAMP)
Acumatica and JAMIS Prime tenants. Companion to the main guide,
Acumatica Report Designer Doesn’t Work With SSO.
Does Acumatica Report Designer support single sign-on (SSO)?
No. Acumatica Report Designer supports only native Acumatica accounts and
LDAP / Active Directory credentials. There is no Entra ID / Azure AD, Okta,
ADFS, SAML, OIDC, or generic OAuth login in the desktop tool. On an SSO-only tenant
there is no password to type, so Report Designer cannot connect. This is
Acumatica’s documented position, not a misconfiguration on your side.
Why does my email-address username fail to log in?
Report Designer’s login dialog treats @ as the tenant (company) separator. It
expects loginID@TenantName. An email-format username such as
[email protected] is split at the @, and the part after it is read as a
tenant name that doesn’t exist – so the login fails. As of 2025 R1 and later,
multi-tenant instances still require the login@Tenant form.
Why is Report Designer blocked even when I use a native account with 2FA?
On many secured tenants, a native account with built-in two-factor
authentication enabled is also blocked from Report Designer’s login surface. So
the workaround account has to be native and 2FA-exempt – exactly the kind of
account a FedRAMP or CMMC posture is designed to eliminate. Report Designer also has
to version-match the target site build, which can mean maintaining two installs
for a dev/prod pair on different builds.
What’s the workaround everyone uses, and why is it painful?
Build or fix the report on a second native-login site → wrap it in a
customization project → export the ZIP → re-import it on the live SSO
site → publish → test → repeat for every change. On top of that loop,
SSO-only and FedRAMP tenants often need a separate test/dev site that the client’s
own IT team has to provision and SSO-enable first, sometimes with multi-week lead
times. It is the standing tax on every report change.
Why hasn’t Acumatica fixed this?
It is not on their roadmap and hasn’t been for years. Acumatica’s own developer blog
(2022) states Report Designer and DeviceHub support only Active Directory (LDAP) and
native authentication; a support case answer confirmed the report designer only
supported native users; the community has documented the limitation since 2018; and
no authentication change shipped through 2025 R2 (the “redesigned report
designer” is a layout/UX refresh). No vendor or VAR in the ecosystem ships a fix.
So how is it solvable at all?
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 flow
doesn’t care about the @-username parsing, and the report API accepts and returns
report definitions under any authenticated session. So the fix isn’t “teach the
login dialog SSO” – it’s “bypass the login dialog and authenticate through the
OAuth/OIDC path the server already supports.”
Is this supported by Acumatica? Are you modifying Report Designer?
No and no. Acumatica does not support SSO for Report Designer – that’s the whole
reason the problem exists. None of the approaches modify, patch, or repackage Report
Designer. The bridge approach is a separate loopback proxy; Report Designer runs
unmodified and points at a local address. The move approach uses Acumatica’s own
documented report API and OAuth. It is third-party consulting/tooling, not an
Acumatica product feature, and carries no Acumatica support entitlement.
Is it secure inside our FedRAMP / security boundary?
It is designed to run inside your boundary and to add as little attack surface
as possible:
- Loopback-only by default. The bridge binds to
127.0.0.1; a non-loopback bind
is refused unless someone explicitly and deliberately opts in, so it can’t
accidentally listen on the network. - No local password to steal. Report Designer is given a dummy username/password
that the bridge discards. All real authentication is your own SSO/OIDC + MFA
sign-in in the system browser. There is no second credential store. - Tokens never touch disk. The access token, refresh token, and session cookies
live in process memory only; restart and you sign in again. There is no
token-at-rest artifact. - Diagnostic capture is redaction-first. Where a diagnostic capture mode is used,
it records header names and presence flags only – never header values, never
request/response bodies – and strips sensitive query parameters. - Single-session by design. The bridge holds one upstream session and accepts any
local credential, so shared/multi-user deployment is explicitly unsupported until
per-user isolation exists – one analyst, one workstation, one session.
Does our data leave the boundary? What about data residency?
No data goes anywhere except between your workstation and your own Acumatica site,
both inside your boundary. The bridge is a pass-through proxy: it forwards Report
Designer’s requests to your site and returns the responses. There is no
external/third-party server in the data path. Report bodies (.rpx/XML) are
forwarded as-is and not persisted by the bridge. The move approach temporarily
handles the report file it is moving (pull → validate → publish), but that handling
is local to the in-boundary workstation and is the report you’re already authoring.
Do I need a native or 2FA-exempt account on our site?
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, and never a need for
2FA to be turned off.
What happens at version upgrades?
Two honest constraints:
- Report Designer is version-matched to the site build. That’s an Acumatica
requirement, not ours; a dev/prod pair on different builds already needs two
installs today. The approach doesn’t remove that requirement, but it doesn’t add
to it either. - A major site upgrade is a re-validation event. After a move to a new major
version (e.g. a v8→v9 or a 2026 Rx jump), the tooling should be re-validated
against the new build before the next report change, because the login handshake
or report API path could shift.
Is this just the customization-project export/import loop with extra steps?
No – it eliminates that loop. The customization-project approach (build on a second
site, wrap, export ZIP, re-import, publish) 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 by letting Report Designer talk to the live
SSO site through the loopback proxy.
What if Acumatica eventually fixes Report Designer SSO – do we lose our investment?
Unlikely on the timeline that matters, and you’re protected either way:
- The limitation has been documented since 2018, no auth change shipped through
2025 R2, and vendor attention is on the 2026 R2 migration cycle – so a fix is not
on the visible roadmap. - Even if Acumatica did ship native SSO for Report Designer, the move approach and
the verification/evidence layer stay valuable – they kill the export/import loop
and ship change-control evidence regardless of how the desktop tool authenticates. - The studio approach is SSO-native by construction, so it’s unaffected by any
desktop-tool auth change. - The part most exposed to a vendor fix is structured as a cancellable support
subscription, not a large up-front build.
Has this actually run against a real FedRAMP / SSO site yet?
Not yet, and we will not claim otherwise. The approach is proven in the lab –
the auth chain, forwarding, publish, validation, and verification are all built and
tested – and the OAuth → session → report-API publish round-trip has been validated
live against a vanilla, native-auth sandbox. It has not run against an
OIDC/SSO-fronted or client FedRAMP site, nor with the real desktop Report Designer
driving it live. That validation is the next step, and it happens under a sanctioned
window. We validate on a sandbox SSO site first; we do not test against your
production – you validate your own production with a tool and checklist we hand
over.
What do I actually get with each change?
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 in a FedRAMP or CMMC environment, that means the change is
provably the intended one. Verification is built into the loop, not bolted on.
How do I get started?
If you administer an SSO-only Acumatica or JAMIS Prime tenant and you’re living the
Report Designer login wall, the next step is 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].