"Self-service config" GIs are the ones I build so that end users — often non-technical department leads, not ERP admins — can adjust a report's scope themselves through ordinary GI parameters, instead of filing a ticket every time the definition of "recent" or "my team" changes. It is less about the Self-Service Portal specifically (covered elsewhere) and more about designing any GI so a business user can safely reconfigure its output within guardrails you set once.
Parameters are the entire self-service surface
A GI has exactly one mechanism for end-user-driven configuration without touching the designer: parameters. Anything you want a department lead to be able to adjust without calling you needs to be a parameter, not a hardcoded condition — the inverse is equally true, anything that should never be user-adjustable (row-level security scoping, for instance) must stay a hardcoded condition, never a parameter, because a parameter is by definition something the user can change.
-- Self-service: user-adjustable, exposed as a parameter with a default
@MinDaysOverdue Default: 30 -- department lead can widen/narrow this
-- Locked: never a parameter, always enforced
SOOrder.BranchID Equals =[AccessInfo.BranchID] -- hardcoded conditionDesigning parameters non-technical users will actually use correctly
The gap between "technically a parameter exists" and "a department lead can use it without calling me" is mostly about types and labels:
- Use selector-type parameters over free text wherever a valid list exists. A free-text "Status" parameter invites typos that silently return zero rows with no error; a dropdown selector cannot be typed wrong.
- Label parameters in business language, not field names — "Minimum Days Overdue" not "MinDaysOverdue", set via the parameter's Display Name property.
- Give every parameter a working default so the GI is useful unconfigured, and self-service becomes optional refinement rather than a prerequisite (see the parameters-and-defaults piece for the mechanics).
- Bound numeric and date parameters where a wildly out-of-range value would be either meaningless or expensive — there is no hard "min/max" enforcement on a plain parameter, so where this matters I add a Conditions-tab check that produces an empty, clearly-labeled result rather than an enormous or nonsensical one.
Document what is and is not configurable
The recurring support ticket on self-service GIs is not "I can't configure it" — it is "I didn't know I could" or the opposite, "I changed something and now it's wrong and I don't know what I changed." A short description directly on the GI (the Description field, or a callout on the dashboard hosting it) listing the two or three parameters a user is expected to touch, in plain language, cuts this dramatically. I treat that description as part of the deliverable, not an afterthought — a self-service GI without a one-line "you can adjust the date range and minimum amount here" note is not actually self-service, it is just a GI with hidden knobs.
Many GI configurations persist the last-used parameter values per user. That is usually a good default-experience feature, but it means a user who once entered an odd filter (a typo'd branch, an accidental huge date range) keeps getting that same broken view on every subsequent visit, with no obvious way to reset short of re-entering correct values. Make sure your defaults documentation also tells users how to get back to the intended default state, not just how to change it.
Wrapping up
Self-service configuration in a GI is entirely a parameter design exercise: expose only what should be user-adjustable as a parameter, keep everything else as a hardcoded condition, favor selectors over free text, and document the configurable surface in plain language as part of the deliverable — not as a follow-up nobody gets around to.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.