Request a Service
Route: /org/resolve/catalog · Permission: Browse and submit service catalog requests.
Authoring: Settings → Service Catalog · Author and manage the service catalog.
1. What a service request is
A service request is a request for something to be provided. Nothing is broken.
That distinction is the whole reason this page exists separately from the queue:
| Incident | Service request | |
|---|---|---|
| The customer is saying | "Something that should work, doesn't" | "I need something I don't have yet" |
| Example | "My laptop won't boot" | "I need a laptop for a new starter" |
| Success means | Service restored | Something delivered |
| Arrives as | An unstructured description | A structured form you designed |
| Usually needs | Diagnosis | Approval, then fulfilment |
| Predictable? | No | Yes — same request, same steps, every time |
Because requests are predictable, they can be productised: you define the item once, decide what you need to know, decide who signs it off, and optionally point it at an endpoint that does the work automatically. That definition is a catalog item.
Those three questions become required intake fields, and you stop having the conversation.
2. How a service request spreads across the application
A request touches six surfaces. Knowing which one you are on saves a lot of confusion.
| Surface | Who uses it | Route |
|---|---|---|
| Service Catalog (authoring) | Admin | Settings → Service Catalog |
| Request a Service | Internal staff | /org/resolve/catalog |
| Customer portal catalog | External customers | /support/catalog (HELP_007) |
| My Service Requests | The requester | /org/service-requests/my · /support/requests |
| Approvals | The approver | Service request approvals |
| Resolution Queue | The agent fulfilling it | /org/resolve/queue |
This is the single most misunderstood behaviour on this screen. For an item marked Needs approval, the drawer says it outright: "It will be routed to your approver and fulfilled once approved — no ticket is created until then."
So a pending request will not appear in the Resolution Queue, will not have an SLA clock running, and will not show in ticket counts. It exists only as a request awaiting approval. If a requester says "I raised it and nothing happened", check the approval step before checking the queue.
3. Ordering a service — step by step
Step 1 · Browse the catalog
| # | On screen | What it is |
|---|---|---|
| 1 | Order a service banner | States the rule and where to change it: "Pick an item below to raise a request — some need approval before fulfilment. Looking to add or change what's offered here? Configure items in Settings → Service Catalog." |
| 2 | Section heading | A catalog section with its own description. Sections are the grouping an admin defines |
| 3 | An item card | Icon, title and description — all three come from the item definition |
| 4 | NEEDS APPROVAL chip | Present when the item's Needs approval toggle is on. Its absence means direct fulfilment |
Only items marked Active and Visible to customers appear to a given audience.
Step 2 · Open the item and fill the form
Clicking a card opens a right-hand drawer titled Order <item title>:
| # | On screen | What it is |
|---|---|---|
| 1 | Description | The item's own description, repeated from the card |
| 2 | Approval notice | Shown only for gated items — "routed to your approver and fulfilled once approved — no ticket is created until then" |
| 3 | A required field | The * after the label marks it required. Label, type and requiredness all come from the item's schema |
| 4 | A Dropdown field | Opens with a Select… empty choice. Its options are typed by an admin — see Where dropdown values come from |
| 5 | Submit Request | Validates, then posts. Reads Submitting… while in flight. Cancel discards |
The four fields in Figure 2 — Employee Name, Job Title, Preferred OS, Start Date — are not built into Orbit. They are this item's schema. A different item shows entirely different fields, and an item with no schema shows "No additional details required. Submit to raise the request."
Step 3 · Submit
Submit Request validates, then posts. The button reads Submitting… while in flight. On success the drawer confirms the request was raised; on failure a red banner shows the reason and the form stays open with your answers intact.
Step 4 · Track it
The requester follows it in My Service Requests — a table of their own requests:
| Column | Holds |
|---|---|
| Request | The item title, with its item key in mono beneath (e.g. escalate_support_ticket) |
| Project | Which project it was raised against |
| Status | Pending Approval (amber) or Approved (green) |
| Ticket | The ticket reference once one exists — or — |
| Requested | Timestamp |
An Approved row carries a ticket number. A Pending Approval row shows —, because no
ticket exists yet. If you ever need to explain to a requester why their request isn't in the queue,
this column is the explanation.
4. Field reference — the order drawer
The drawer renders one control per field in the item's schema. Five control types exist:
| Type | Renders as | Notes |
|---|---|---|
| Text | Single-line input | Honours the field's placeholder |
Single-line input, type=email | Format-validated on submit | |
| Text Area | 4-row textarea | For free description |
| Dropdown | <select> | Opens with a Select… empty choice |
| Checkbox | Checkbox with the label beside it | The label is the whole prompt |
Required fields are marked with an asterisk after the label — EMPLOYEE NAME *.
Where dropdown values come from
This is the answer to "what is the source of this list": a Dropdown field's options are a
comma-separated list typed by the admin on that field, in Settings → Service Catalog. The
placeholder in the authoring UI is literally Options, comma-separated (e.g. 16GB, 32GB, 64GB).
They are not drawn from products, assets, users or any other entity. So the values are exactly as current as the person who typed them — if a laptop model is discontinued, someone has to edit the field. Nothing else keeps that list in sync.
Validation rules
Validation runs on submit, in field order, and stops at the first failure — so a form with three problems reports them one at a time.
| Rule | When it fires | Message |
|---|---|---|
| Required (checkbox) | Ticked box required, not ticked | Please confirm: <label> |
| Required (all others) | Empty after trimming | <label> is required. |
| Email format | Value isn't [email protected] | Please enter a valid email for <label>. |
| Minimum length | Shorter than the field's minimum | <label> must be at least <n> characters. |
| Maximum length | Longer than the field's maximum | <label> must be at most <n> characters. |
| Pattern | Fails the field's regex | The field's own error message, or <label> is not in the expected format. |
Optional fields left blank skip format checks entirely — an empty optional email is valid.
Pattern failures fall back to "…is not in the expected format", which tells the requester nothing. Whenever you set a regex on a field, also set its Error message — that is what the requester actually reads.
5. What an admin defines — the catalog item contract
Everything above is driven by the item definition in Settings → Service Catalog.
| Field | Required | Notes |
|---|---|---|
| Catalog Section | ✅ | The grouping heading. Sections are created separately with a name (e.g. Hardware) |
| Title | ✅ | e.g. Standard Developer Laptop |
| Item Key | ✅ | Auto-slugified from the title, editable. e.g. laptop_request |
| Description | Shown on the card and at the top of the drawer | |
| Fulfilment webhook URL | Optional. Empty means the organisation default is used | |
| Needs approval | Gates fulfilment behind an approver | |
| Active | Off hides the item everywhere | |
| Visible to customers | Controls whether external customers see it, separately from staff |
Item Key is sent to the fulfilment webhook as catalog_item_type. Renaming it after anything is
wired up breaks the receiving end silently — the request still submits, the endpoint just stops
recognising it. Treat it as immutable once live.
Per-field options an admin can set
| Setting | Applies to | Effect |
|---|---|---|
| Label | all | What the requester reads |
| Field key | all | Slugified; the key the answer is stored and sent under |
| Type | all | Text · Email · Text Area · Dropdown · Checkbox |
| Required | all | Adds the * and enforces presence |
| Placeholder | text, email, textarea | Hint text |
| Options | Dropdown | Comma-separated list |
| Default value | all | Pre-fills the field |
| Regex | text, email, textarea | Pattern the answer must match |
| Min / Max length | text, email, textarea | Length bounds |
| Error message | all | Shown when the regex fails |
6. Fulfilment
For items with a fulfilment webhook, Orbit calls your endpoint once the request is approved. The authoring screen explains it plainly: "your endpoint that does the work when a request for this item is approved (create the account, ship the laptop…). Orbit calls it; it doesn't have to be an Orbit thing — any HTTPS endpoint (serverless function, n8n/Zapier, an internal API)."
Orbit sends JSON including the catalog_item_type and the requester's field answers.
The authoring screen is explicit: replying 2xx immediately acknowledges receipt, and "that alone
does not close the ticket." Your endpoint acknowledges fast, does the work, then reports
completion separately. An endpoint that returns 200 and does nothing leaves a request that looks
accepted and never completes.
Items without a webhook are fulfilled by a human agent from the Resolution Queue.
7. Don't confuse this with…
Five screens in Resolve deal with service requests. They are easy to mix up, so:
| Screen | Route | Whose view | What it does |
|---|---|---|---|
| Request a Service (this page) | /org/resolve/catalog | Staff, internal | Browse and order. A shop front. Read-only apart from ordering |
| My Service Requests | /org/service-requests/my | The requester | Track what I ordered — status, approval state, resulting ticket |
| Service Request Approvals | Approvals | The approver | Decide. Approve or reject other people's requests |
| Service Catalog (authoring) | Settings → Service Catalog | Admin | Define what can be ordered — items, fields, approval, webhooks |
| Resolution Queue | /org/resolve/queue | The fulfilling agent | Do the work once a ticket exists |
The two most often confused are the first two:
/org/resolve/catalog vs /org/service-requests/myRequest a Service is where you place an order — a catalog of things available. My Service Requests is where you watch the orders you already placed.
One is forward-looking and item-shaped; the other is backward-looking and history-shaped. If you are looking for "what happened to my laptop request", you want My Service Requests, not the catalog.
Settings → Service Catalog authors the catalog. Request a Service consumes it. Both are called the service catalog in conversation. If someone says "add it to the service catalog", they mean Settings.
8. Troubleshooting
| Symptom | Cause |
|---|---|
| An item you expect is missing | The catalog is project-scoped — check the project switcher. Then check Active and Visible to customers |
| Requester says nothing happened | The item is approval-gated; no ticket exists until approval. Check the approver is set |
| Dropdown shows a stale option | Options are typed per field; someone must edit the field in Settings |
| Pattern error tells the user nothing | The field has a regex but no Error message |
| Webhook fired but the request never closed | 2xx only acknowledges; completion must be reported separately |
Related
- Resolution Queue — where an approved request is fulfilled
- Core concepts — request vs incident
- Overview