Catalogue Request Approvals

Catalogue Request Approvals

Set it up: Forms → the 🛡️ shield icon on a form's row → Approval settings Approve requests: Forms → Approvals What the customer sees: their portal dashboard → Your requests

Some requests shouldn't go straight to the service desk. A new laptop, a software licence, access to a system — these often need a manager or a budget-holder to say yes first. A catalogue item can now be set to wait for approval, and only become a ticket once someone signs it off.

This is optional and per-item: leave it off and the catalogue behaves exactly as before.

Requiring approval on a catalogue item

A catalogue item is a form you've offered in the portal (see Portal Request Catalogue). On the Forms list, each row has a 🛡️ shield button — Approval settings:

1. Tick Require approval before a ticket is raised.
2. Choose an approver — the member of staff who signs these off.
3. Save.

The form's row then shows an amber Needs approval pill.

💡 Approval only bites on catalogue (portal) requests. If the form isn't in the catalogue yet, the setting is saved but does nothing until you publish it — the modal says so. A member of staff filling the form in internally is never gated; there's no customer to raise the ticket for.

💡 A form set to "require approval" but with no approver chosen does nothing. It's treated as unconfigured rather than trapping requests with nobody able to clear them.

What happens when a customer submits

Instead of the request sitting in Forms → Submissions waiting for someone to notice, it goes to the chosen approver as a pending approval. The approver — and only the approver (or an administrator) — can decide it.

The person who was named as approver is fixed at the moment of submission. If you later change the catalogue item's approver, requests already waiting stay with the person the customer was originally told would handle them; only new requests go to the new approver.

Approving or rejecting

Open Forms → Approvals. Three views down the side:

• For me — requests waiting on you.
• All pending — every request awaiting anyone (oversight).
• Decided by me — your recent approvals and rejections.

Each card shows the request, who asked, when, and every answer they gave. Add an optional note, then:

• Approve → a ticket is raised automatically. It's opened as the requester, under their company, with the submitted answers in the body, and the request is linked to it. The desk picks it up like any other ticket.
• Reject → the decision is recorded and no ticket is raised.

🔑 Approving is how the request becomes a ticket. There's no separate "raise a ticket from this submission" step for a gated request — approval is that step.

What the customer sees

A pending request isn't a ticket yet, so it would otherwise vanish from the customer's view until it was approved. Their portal dashboard now has a Your requests section showing each request they've submitted and its state:

• Awaiting approval — submitted, waiting on the approver.
• Approved — with a link straight to the ticket it became.
• Declined — the approver turned it down.

The section only appears when they actually have requests.

The approver's note stays internal for now — a declined request shows as Declined without the reason. If you want the reason shared with the requester, that's a small future change.

Who can approve

The assigned approver, or an administrator. Everyone else is refused — the whole point of naming an approver is that they're the one who signs it off.

⚠️ An approver needs access to the Forms module to open the Approvals inbox — the same rule as Change Management's approvals page. If you name someone who doesn't normally use Forms, give them Forms access, or the requests will wait unseen.

Worked example

Equipment Request is in the catalogue and set to require approval, with Priya (IT Manager) as approver.

1. Tom requests a docking station. His dashboard shows Docking station — Awaiting approval.
2. Priya opens Forms → Approvals → For me, sees Tom's request and his answers, and clicks Approve.
3. A ticket RPT-402-11890 is raised as Tom, with his answers in the first message. Priya's inbox no longer lists it; Tom's dashboard now shows Approved → RPT-402-11890, linking to the ticket.

Had Priya clicked Reject, Tom would see Declined and no ticket would exist.

What this version does not do (yet)

• The approver is a member of staff, not the requester's manager. Routing to "whoever the requester reports to" needs a manager relationship the portal doesn't hold yet — a later step.
• One approver, not a board. There's no multi-approver / majority vote here (Change Management has that for changes).
• No approval reason shown to the customer (see above).

See also

• Portal Request Catalogue — offering forms to customers in the first place
• Forms — building forms and reading submissions
• Catalogue Request Approvals — Developer Guide — how it works under the hood
• Self-Service Portal — the customer's side