Acumatica GI Parameters and Default Values

A GI parameter with no default value is a trap that only springs the first time someone loads the inquiry cold — the grid comes back empty, or worse, unfiltered and enormous, and the user has no idea a parameter even exists until they scroll up and notice a blank field. Default values are not a nicety on GI parameters; they are what makes the difference between a GI someone opens once, and one they bookmark.

Setting defaults on the Parameters tab

Each parameter on the GI Designer's Parameters tab has a Default Value expression, evaluated when the GI is first opened without an explicit value supplied (via URL, dashboard filter, or user memory of the last value used, depending on the "remember last filter" setting). The expression language supports both literals and functions:

@FromDate   Default: =FirstDayOfMonth([today])   (function-based, relative)
@ToDate     Default: =[today]
@BranchID   Default: =[AccessInfo.BranchID]      (current user's branch)
@Status     Default: 'Open'                       (literal)

Function-based relative defaults (first day of month, today, current fiscal period) matter more than literals for anything used regularly, because a literal date default is correct on the day you built the GI and wrong every day after. I almost never ship a literal date default outside of a one-off historical report.

Required parameters versus optional-with-default

These solve different problems and people reach for the wrong one constantly. A required parameter with no default forces the user to make an explicit choice before the GI runs at all — appropriate when there is no safe assumption (which specific customer's statement do you want?) and when running unfiltered would be actively dangerous, as covered in the large-export piece. An optional parameter with a sensible default lets the GI be immediately useful on first load while still letting a power user override it — appropriate for the much more common case of "last 30 days unless you say otherwise".

Defaults scoped to the current user

AccessInfo expressions let a default reflect who is asking rather than a fixed value — current branch, current user ID, current company. This is what makes one GI usable across an entire sales team without per-user copies: each rep's default filter is naturally their own branch or their own customer set, with no per-user configuration required. Combine this with row-level security (covered in the row-level-security post) rather than relying on the default alone for anything that must actually be enforced — a default is a convenience the user can change; a security condition cannot be.

-- Convenience only — user CAN clear this filter and see other reps' orders
@SalesPersonID  Default: =[AccessInfo.ContactID]

-- Enforced — this condition is not a parameter at all, always applies
SOOrder.SalesPersonID  Equals  =[AccessInfo.ContactID]   (hardcoded condition, not a parameter)

Wrapping up

Give every optional parameter a sensible, ideally relative default so the GI is useful on first open, reserve required-with-no-default for cases where an unfiltered run would genuinely be wrong or dangerous, and always test the blank-parameter path explicitly. Use AccessInfo-based defaults to make one GI work naturally per user, but remember a default is convenience, not security — enforce actual restrictions as hardcoded conditions instead.