Report Designer on SSO-Only Sites: Mover, Bridge, Studio
The three-tier fix for the one reporting problem Acumatica has left open
since 2018 – for Acumatica and JAMIS Prime tenants on Entra ID / Okta / ADFS /
FedRAMP single sign-on. Written June 2026.
The offer in one sentence – Your SSO-only site means Report Designer
cannot log in at all, so every report change runs through the
build-elsewhere / export ZIP / re-import / publish loop. We remove that loop
three ways – a one-command Report Mover, a loopback SSO Bridge for
the real Report Designer, and a browser-based Studio where SSO is the
front door – each shipping a verification evidence packet with every change.
The diagnosis (independently verifiable)
This part is not our claim to take on faith – it is on the public record:
- Report Designer supports only native Acumatica and LDAP/Active Directory
credentials. There is no Entra ID, Okta, ADFS, SAML, OIDC, or OAuth login
path in the desktop tool. - Its login dialog parses
@as the tenant separator, so an email-format
username is mis-split into a login and a tenant that doesn’t exist. - On many secured tenants, a native account with 2FA enabled is also
blocked – so the workaround account must be native and 2FA-exempt,
exactly the account a FedRAMP/CMMC posture forbids. - The limitation has been documented in the community since 2018, and no
authentication change shipped through 2025 R2.
The full write-up, with the workaround loop everyone hates spelled out, is in
our companion guide: Acumatica Report Designer Doesn’t Work With SSO – Here’s
Why, and How to Fix It.
Why this offer exists at all
As of June 2026, no vendor, VAR, or community project in the Acumatica
ecosystem ships a Report Designer SSO fix – the nearest prior art solves a
different surface entirely. The gap stays open because the framing looks
impossible (“make the desktop tool speak SSO”). The reframing that makes it
tractable: the limitation lives entirely in Report Designer’s client-side
login dialog. Acumatica’s own server APIs take the tenant out-of-band and
accept OAuth sessions. Bypass the dialog and you bypass the whole problem.
The three tiers
Tier 1 – Report Mover: kill the export/import loop
Keep designing in the real Report Designer against any native-auth dev site.
Then one command pulls the report definition, validates it proven-safe
against the field/schema catalogs, publishes it to your SSO site through
Acumatica’s own report API under an interactive OAuth browser sign-in (your
SSO user, with MFA – no native account, no 2FA exemption), 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.
Tier 2 – SSO 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, established through your normal SSO + MFA browser flow. Report
Designer points at a local address with a dummy non-@ username – which is
discarded, so it can never be mis-split – and every request is forwarded
with the upstream session attached. The author keeps the exact desktop tool
they know, with no second site and no export/import loop at all. Loopback-only
bind, tokens in memory only, nothing persisted: designed to live inside a
FedRAMP boundary.
Tier 3 – Studio: the SSO-native browser editor
A browser-based report editor where SSO is the happy path by construction
– it’s a web app; your Entra login is the front door, not the obstacle. Upload
or load a report, make the five most common changes (relabel / add / remove a
field, text and formula edits, parameter defaults, clone-a-variant) through
form-based controls, and get a proven-safe diff plus a validation gate
before anything can be downloaded or handed to publish. The edit core
is proven not to alter anything beyond the requested change. Publishing stays deliberately
operator-fired – a human is in the loop on every change.
How they relate: Mover is the immediate pain-killer, Bridge keeps the full
desktop tool, Studio dissolves the problem. They share the same proven
plumbing – OAuth sign-in, the report API, byte-fidelity validation, the
verification engine – so they’re a portfolio, not competing bets.
Every tier ships evidence
Each delivered change carries a verification packet – parse check,
vanilla-vs-working diff, side-effect screen, human-gated readiness – the same
discipline as our Verified ERP Reporting
service. On an SSO-only site you don’t just need the change to be possible;
you need it to be provably the intended one, because these are exactly the
environments with real change control.
The claims ceiling (read this before you buy)
We hold this page to the same standard as the evidence packets:
- Validated in our lab against a non-SSO sandbox. The OAuth sign-in, the
report-API publish round-trip, the byte-fidelity validation, and the
verification engine are built, tested, and have been validated live against
a vanilla, native-auth Acumatica sandbox. - Live SSO validation is the first step of your engagement – not a thing
we claim already happened. The same round-trip over an OIDC/SSO-fronted
site, with the real desktop Report Designer driving it, runs first, in a
sanctioned window, on a sandbox. - We never test against your production. You validate your own production
site; we hand over a validated tool plus a checklist. - Nothing here modifies, patches, or repackages Report Designer, and none of
it carries an Acumatica support entitlement – it works with Acumatica’s
supported server APIs and around the unsupported desktop login dialog.
We would rather show you a validation than sell you a claim.
Next step
Book a consultation
or email [email protected]
– the first engagement step is the live SSO validation on a sandbox you
sanction, so the first thing you receive is proof on your own terms.
Contact
A walkthrough and a sandbox validation, on your terms – live SSO validation is the first step of every engagement.
Or email [email protected].