Publishing an Acumatica GI to the Self-Service Portal

The Acumatica Self-Service Portal is one of those features clients ask about constantly and consultants under-use: it lets external users — customers, vendors, partners — log into a stripped-down site and see data you choose to expose, without burning full user licenses. Generic Inquiries are the workhorse for that exposure. A GI published to the portal is the fastest way to give a customer a live view of their open invoices, order history, or case backlog without writing a single line of C#.

I have set this up for distributors in Nairobi who wanted customers to self-serve on "where is my order" questions, and the pattern is always the same: build the GI, scope it to the current business account, publish it to the portal sitemap, and then spend the remaining time on the part everyone forgets — making sure a logged-in customer can only ever see their own rows.

The portal has its own sitemap

The first thing that trips people up: the Self-Service Portal is a separate site with a separate sitemap. Adding a GI to the ERP sitemap on the Site Map screen (SM200520) does nothing for portal users. The portal reads from the Portal Site Map (SP200520 on the portal side), and a GI only appears there if you explicitly expose it.

The mechanics on a modern build (2021 R1 onward, and unchanged through 2024 R2):

1. Open the Generic Inquiry screen (SM208000) and load your inquiry.
2. Tick Expose to the Portal — this is a separate checkbox from Expose via OData and from the plain sitemap settings.
3. On the portal instance, add a sitemap entry under an appropriate workspace pointing at the GI's screen ID.
4. Grant access to the portal user role on the Access Rights by Screen screen — portal users typically carry the Portal User role plus whatever custom roles you define.

If the GI does not show up, it is almost always one of those four steps skipped, in my experience most often the role grant. The portal fails silently: the menu item simply is not there, with no error anywhere.

Scoping data to the logged-in customer

Portal users are linked to a business account via their Contact record. Acumatica gives you the @me-style access through the Current<> pattern — in GI conditions you can reference the current portal account with the AccessInfo parameters. The practical recipe is a condition on the GI's Conditions tab:

Data Field:  ARInvoice.CustomerID
Condition:   Equals
Value 1:     =[AccessInfo.AcctID]  -- resolves to the contact's BAccount

In practice I usually do not rely on the raw AccessInfo expression alone. For anything financial I build the GI on top of a projection or add a relation to BAccount restricted by the current user's contact, because AccessInfo.AcctID behaves differently for users linked to a parent account with child accounts. Test with a real portal login, not your admin account — an administrator bypasses most restrictions and will happily show you every customer's invoices, which proves nothing.

Parameters, filters, and what portal users actually tolerate

Portal users are not ERP users. They will not discover the filter row, they will not build reusable filters, and a GI with eight parameters gets abandoned. My rules of thumb after a few of these projects:

• Two parameters maximum, usually a date range. Default them sensibly — last 90 days, not blank.
• Pre-sort by the column they care about (document date descending, almost always).
• Keep it under ten columns. Reference number, date, status, amount, balance covers 90% of "customer statement" style inquiries.
• Enable the side panel or a navigation link to the portal-visible document (portal invoice view, case view) rather than the ERP screen — a link into the full ERP screen produces an access-denied page for a portal user and a confused phone call for you.

Licensing and performance notes

Portal users are licensed separately (and far more cheaply) than ERP users, which is the whole commercial argument for this setup. But they share the application database and, depending on deployment, can share the app tier. A popular portal GI is effectively an unauthenticated-adjacent query endpoint hammered by people outside your company. Two things follow:

First, make the GI cheap. Every join you add runs per request. A GI joining ARInvoice to ARTran to show line detail on the list view will crawl once a customer has a few thousand historical invoices; show headers in the list and push line detail to a second GI or the document view.

Second, watch the SELECT TOP behaviour. GIs page server-side, but a portal user hitting Export to Excel pulls the full result set. If exports are enabled, cap the data with a date-range parameter that has a default, so the unfiltered worst case is bounded.

When a GI is not enough

A GI gets you read-only lists. The moment the requirement becomes "and the customer should be able to click a button to request a copy invoice" you are into portal customization territory — a customization project deployed to the portal instance, with a PXGraph behind a custom screen. That is a legitimate path (the portal is the same platform underneath), but it is a step change in effort, and I always make clients confirm the read-only GI version is insufficient before quoting for it. In more than half the cases, the list plus a mailto link closes the requirement.

Wrapping up

Publishing a GI to the Self-Service Portal is genuinely quick — an afternoon including testing — as long as you remember that the portal has its own sitemap, its own roles, and its own security model. Spend your care on row-level scoping and on testing with a real portal login. The feature earns its keep the first month your accounts team stops emailing PDF statements by hand.