What a travel approval chain is

This definition is written by the team behind GTOS, the Global Travel Operating System from Voraal, and is built on operating experience across 100,000+ trips. The working design is in the guide approval chains and on the approval chains feature page. We do not invent cycle-time figures.

What a chain has to capture

Each step should record who decided, what they decided, and on which version of the trip. If the itinerary changes after approval, the chain should say whether the existing decision still stands or whether the trip must return to an approver. Delegations should be explicit: when a line manager is away, named cover should be able to act without informal forwarding. Approvers need a view of the trip, the policy reason, and the cost — not a forwarded screenshot.

In GTOS, approvals and approval chains are designed to write to the same trip record as search and issue. Faster approvals come from that design: the approver is asked to decide on a complete file, not to chase missing context. Speed that is gained by skipping the record is not a gain. It is a later audit problem.

How chains relate to policy

The travel policy decides when a chain is required and how long it is. In-policy, below-threshold travel may auto-progress, then auto-issue if the rest of the file is clean. Exceptions should not be quietly booked; they should be routed. A chain that treats every trip the same will either slow the programme to a crawl or be bypassed. A chain that matches role, entity and trip type is more likely to be followed. That is also why unofficial volume is a signal about the chain: if people leave the official path to avoid a slow or unclear step, the workflow needs to be redesigned, not only restated in a memo.

What it is not

It is not a mailbox folder. Email can carry a yes or no, but it rarely stays attached to the current itinerary, and it rarely survives a change. It is not a single named approver for every case, unless the programme is genuinely that small. It is not role-based access on its own — access decides who can see and do, while the chain decides who must decide — though the two have to agree. And it is not a substitute for policy at search. Asking an approver to reject a clearly out-of-bounds option that should never have been bookable is wasted effort.

How to test one

In a demo, walk a low-value in-policy trip that should pass quickly, an exception that needs a second step, and a change that should re-open a decision. Show the trail on the trip after each. If those three cases cannot be shown, the product may still have an “approve” button, but it does not yet have an approval chain in the sense this glossary uses. Also ask how the chain behaves when an approver is away, and how audit reads the same file a month later.