Skip to main content

Self-service portal

The build side is service requests.

The self-service portal is where a business user runs the automation a Builder has published — without seeing workflows or jobs. They pick a request, fill in a short form, and submit.

What the user sees​

One page, grouped by category. Each category the user has a button in is a section headed Category: and the category's name; the buttons that are in no category are gathered into a General section at the end. The sections and the buttons inside them appear in the order an administrator arranged them on Order Buttons in Category — and where nobody has arranged them, by name. A category given a band colour there draws its cards on a tinted band.

Above the sections are two ways to narrow the page:

  • A search picker — a list of the button names the user can reach. Typing filters the list; choosing a name opens that button rather than filtering the page down to it. Clearing the picker returns to the whole page.
  • Tag pills, one per tag the visible buttons carry, used as toggles. Select several and a button matching any of them is shown.

Each card shows the button's name, the Builder's documentation as the note beneath it, and its tags along the bottom — past three, the rest are summarized as a +N chip. The input and event counts earlier builds drew are gone: what a button is for is more use to a requester than how many pieces it has.

Selecting a card opens the button's request dialog over the page: any documentation and confirmation message the Builder set, then the input fields. On Submit, a confirmation appears; confirming fires the request's events and shows a success or error result. Closing the dialog leaves the page — and the tag filter — exactly as it was.

A field asking for a workflow or a job is a picker, not a text box: the user types to narrow the list and chooses a real workflow, or a real job from the one workflow the Builder chose. Reading that list is a separate permission from using the portal, so a user who is allowed to submit the request but not to read workflows gets the plain text box instead and types the name — see Workflow Selection and Job Selection.

A link to one button still works

The dialog is part of the address, not just of the page, so /self-service/<id> opens the page with that button's dialog already open. A link somebody bookmarked or shared keeps working, and closing the dialog returns them to the full page.

What happens on submit​

The user's answers are substituted into the request's events, which are then fired. The user sees whether it succeeded.

The events fire one at a time, in the order the Builder arranged them. That matters whenever one event sets something up for a later one — a $PROPERTY:SET followed by a $JOB:ADD that reads the property, say. Earlier builds submitted them as a batch that ran several at once, so a chain like that could run out of order and the job could be added with the old value. One event failing still does not stop the rest.

A request that partly failed is not offered a retry. The result says which events failed and that the others ran, because submitting again would run those a second time. The same reasoning covers a submission that gets no answer in time: rather than inviting a retry, the portal reports Request Outcome Unknown and asks the requester to check the event log first — some of the events may already have run.

Some of what reaches the automation is about the requester, not from the form. A Builder can put ${SM.USER.EMAIL} or ${SM.USER.NAME} into an event, and the portal fills it in from whoever is signed in — so a request can record who asked for it without asking them to type their own name. See System variables.

A placeholder the portal cannot fill in stops the submission rather than sending blank or sending the placeholder text. The message names the field or the variable at fault, so it reads as a request the Builder needs to fix rather than as something the requester did wrong.

Good to know
  • The catalog is environment-scoped — a user only sees requests deployed and active in their environment. "I can't see request X" usually means it isn't deployed there.
  • The page lists at most 1,000 requests, the newest first. An environment with more than that says so — "Not every service request in this environment could be listed. The newest ones are shown." — rather than quietly omitting the rest. If you are near that number, retiring deployments you no longer need is what keeps the page complete.
  • The portal opens only for people whose roles grant self-service-portal.view, and that permission is enforced by the service behind it rather than only hiding the page. A requester who holds no role reaches nothing. See Roles and permissions.
  • Submitting needs more than seeing the page. The requester also needs self-service-portal.execute in the button's workspace and environment, the permission each of the request's events requires in the workspace of the object it names, and properties.view for every property the events name. If any one is missing, nothing is sent and the result shows only permission.denied — or, when self-service-portal.execute is the one missing, that the request is not available. See What a requester needs permission for.
  • A submission fires events; the actual work is the automation those events trigger, so a "submitted OK" result means the events were accepted, not that the downstream work is finished.
  • The page groups by category, and a category with no visible button draws no section — including one that is empty only because a rule hides every button in it. Both the sections and the buttons inside them follow a saved position, then name; a page nobody has arranged is therefore alphabetical.
  • If one of your own categories is called General, the uncategorised section takes a different name — Uncategorised, then No Category — rather than presenting two sections a requester cannot tell apart.
  • Hidden and Disabled on a button are applied here. A hidden button is not on the page at all — it is not in the search picker, its tags are not offered as pills, and a link straight to it reports not found. A disabled one is shown but inert, with a tooltip saying so, and its request dialog opens read-only. Both are decided by a rule a Builder writes over the tenant's properties, so the answer can differ by environment and can change between one visit and the next. Both rules are checked again when a submission arrives, so a button hidden or disabled since its dialog opened is refused, with nothing sent.
  • If a button shows a warning icon in its card header, its rule could not be evaluated. The button stays usable — the platform would rather let you submit than hide something wrongly — but the answer is not trustworthy, so tell an administrator.

Related topics