Catalogue Request Approvals - edmozley/freeitsm GitHub Wiki

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:

Tick Require approval before a ticket is raised.
Under Who decides, choose A person or A team (see Approval by a team below).
For a person, choose the approver — the member of staff who signs these off.
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.

The approver cannot approve their own request

Under the approver there is a tick box, The approver cannot approve a request they made themselves. It is off unless you turn it on, so existing forms behave as they always have.

FreeITSM matches on email address: it applies when a member of staff makes a request through the portal using the address they log in with. With it on, their own requests are not theirs to decide - they show as Stuck until an administrator moves them to someone else.

Approval by a team (4.3.0)

Choose A team under Who decides when one person's say-so is not enough - a purchase that needs two of the three budget holders, access that needs two of the security team.

Setting	What it does
Team	Any active team from People → Teams. The dropdown shows how many members each has.
Approvals needed	How many different members must approve. 1 to 20.
Rejections needed to decline	How many must reject before the request is declined. Starts at 1 - one rejection stops it. Raise it when one person should not be able to block a request alone.

How it works:

Each member votes once. A vote cannot be changed or cast twice.
Whichever number is reached first decides it. Reach Approvals needed and the ticket is raised (or the form's own When approved actions run); reach Rejections needed and it is declined. The ticket is raised once, even when the last two votes land at the same instant.
A rejection needs a reason. An approval's note is optional.
The requester never votes, even if they are in the team. In team mode this is always on.
Membership is checked at every vote. Somebody who leaves the team can no longer vote on requests already waiting; somebody who joins can. Votes already cast still count.
The policy is fixed when the request is made. Changing the form's team or numbers affects new requests only, just as changing a named approver always has.

The approval window warns when the team has fewer members than the approvals needed, because its requests could never be approved.

💡 Switching a form from a person to a team keeps the person. Switch back to A person and the approver you had is still chosen.

Team members do not need Forms access

Being in a team that approves a form is enough to open Forms → Approvals, exactly as being a named approver is (see Who can approve).

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, including votes on team requests that are still waiting for others.

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.

A team request's card also shows the team, how far it has got (1 of 2 approvals, and rejections when more than one is needed) and every vote so far - who, when, and their note. Once you have voted it leaves For me. Your click is one vote: a toast says Your approval is recorded - 1 of 2, and the request stays pending until enough others agree.

🔑 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

For a person request: the assigned approver, or an administrator. For a team request: any current, active member of the team who did not make the request. Everyone else is refused.

When an administrator steps in

Override

On a person request, an administrator's Approve or Reject decides it, as it always has.

On a team request, an administrator's click is not a vote. An administrator who is not voting as a member sees a note on the card: their Approve or Reject overrides the team, and the note box becomes the reason, which must be filled in. The override decides the request at once and is recorded on it - who, when, which way and why.

(An administrator who is a member of the team votes like anyone else in For me.)

Move

A waiting request can be sent somewhere else with Move, on its card - to another team (with its own Approvals needed) or to a named person. A reason is required. Use it when the approvers are away, the team was wrong, or a request is stuck.

Votes cast before the move stay on the record but no longer count - the new approvers start from nothing. A move is recorded on the request like an override.

Stuck requests

A request that can no longer be decided by its approvers is marked Stuck on its card:

the team has no active members left, or too few to reach either number;
the named approver made the request themselves, and the form excludes the requester.

A stuck request is never approved automatically. An administrator moves or overrides it.

An approver does not need the Forms module (since 3.8.0). Being named as the approver of a form that requires approval, or of a request, is enough to open the Approvals inbox: they get a Form approvals tile in the launcher and on the landing page, see For me and Decided by me, and decide their own requests. They do not see All pending (every request and every answer in it), the designer, or anybody else's submissions - those stay with Forms users. Somebody given Forms Read only access can approve too, when they are named.

To keep approvers out of the designer altogether, turn on Forms → Settings → Access → Only people with "Design forms" - see Roles & Permissions.

Worked example

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

Tom requests a docking station. His dashboard shows Docking station — Awaiting approval.
Priya opens Forms → Approvals → For me, sees Tom's request and his answers, and clicks Approve.
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.
No approval reason shown to the customer (see above).
One stage of approval. A request goes to one person or one team; there is no "line manager, then finance" chain.