"Parameters" and "prompts" get used interchangeably by clients and, honestly, by some documentation, but in the Report Designer they're related concepts with a real distinction that matters the moment a report needs to run both interactively and from a screen action. Getting this wrong is why reports that work perfectly when a user clicks through the sitemap sometimes fail — or worse, silently show wrong data — when triggered from a button on a business document.
A parameter is a typed input the schema can reference; a prompt is its optional UI
A report parameter is declared once, with a name, a type, and optionally a default value and a list of valid values. Every WHERE clause, every layout expression, references it as [@ParameterName]. Whether the end user ever sees a box to type into depends on how the report is invoked: run from the report catalogue via the sitemap, Acumatica auto-generates a prompt screen from the declared parameters. Invoked from a screen's Print action or a workflow via PXReportRequiredException, the calling graph populates the parameter dictionary in code and the report renders directly — no prompt screen appears at all, because the caller already knows the values.
var parameters = new Dictionary<string, string>
{
{ "OrderType", order.OrderType },
{ "OrderNbr", order.OrderNbr },
};
throw new PXReportRequiredException(parameters, "SO641000", PXBaseRedirectException.WindowMode.NewWindow,
"Print Order");Why this breaks reports that assume they're always prompted
A report built and tested only through the sitemap prompt screen gets used to the idea that a parameter is always populated — the prompt validates required fields before letting the user run the report. A report invoked from a screen action has no such gate: if the calling graph forgets to pass a parameter, or passes an empty string instead of omitting it, the report runs anyway with a blank or default value, and depending on how the schema's filter is written, either returns everything (a missing WHERE condition effectively vanishes) or returns nothing (a filter comparing to an empty string that matches no rows). Test every report both ways — through the prompt screen and via a direct action call with deliberately incomplete parameters — before considering it done.
A string parameter left blank and referenced in a filter as Field Equal =[@Param] typically returns zero rows, not an error — the filter just doesn't match anything, which looks to a user like "the report is broken" rather than "you forgot to fill in the box." A numeric or date parameter left blank can instead throw a conversion error at render time. Know which failure mode each of your parameters produces and decide whether that's acceptable or needs a default value.
Defaults and cascading values reduce prompt friction — use them for interactive reports
For reports that are genuinely meant to be run interactively and often, invest in sensible defaults (date range defaulting to current period, not blank) and, where the Schema Builder supports it, cascading parameter lists (selecting a customer narrows a subsequent order-number picklist to that customer's orders) rather than presenting a wall of unconstrained free-text boxes. This is the same UX discipline that makes a good Generic Inquiry filter panel pleasant to use, and it applies just as much to a report prompt screen that a controller runs every Monday morning.
Wrapping up
A parameter is the underlying typed input; a prompt is only the auto-generated UI for it when a report runs standalone from the sitemap — screen-action invocations skip the prompt and populate parameters directly from code. Test both invocation paths, know what an unset parameter does to your specific filter expressions, and give interactive reports sensible defaults and cascading lists so the prompt screen doesn't become the annoying part of running the report.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.