Approval & Rejection Reasons
When every approver writes rejection reasons from scratch, guests get inconsistent explanations and your organization can’t report on why requests are approved or rejected. Reason catalogs fix both: you define a standard set of reasons, and approvers pick from it when approving or rejecting a request.
Travel and expense requests use separate catalogs. Travel reasons appear on flight, hotel, rental car, and rail card limit approvals; expense reasons appear on expense approvals.
Adding a Reason
Open the catalog
Go to Settings → Approval & Rejection Reasons and pick the Travel or Expense tab.
Add the reason
Click Add reason and fill in:
- Applies to — Travel or Expense. This can’t be changed after creation.
- Used when — Rejecting or Approving. Approvers only see reasons matching the action they take. This can’t be changed after creation.
- Display label (required) — What approvers see in the reason list, e.g. “Outside travel window”.
- Code (optional) — A stable value for reporting and integrations, e.g.
OUT_OF_WINDOW. Never shown to guests. Codes must be unique within a catalog. - Guest email language (rejection reasons only) — Pre-fills the details shared with the guest when this reason is picked. Approvers can still edit it per decision.
Save
Click Add reason. The reason is immediately available to approvers.
How Approvers Use Reasons
Once at least one rejection reason exists in a catalog, rejecting a matching request changes from a free-text box to a required Reason select listing your catalog plus a built-in Other option, with a Details field below it:
- Picking a reason pre-fills Details with its guest email language, which the approver can edit.
- Picking Other requires the approver to write details themselves.
Approval reasons work the same way on the approve side: once at least one approval reason exists, approving a matching request asks for a reason from the catalog.
With no rejection reasons configured, rejecting keeps the classic free-text reason box. Approving is different: with no approval reasons configured, approving doesn’t ask for a reason at all — add at least one approval reason if you want approvals to record one.
What Guests See
When a request is rejected, the guest sees the Details text — the approver’s edited or written explanation, or the reason’s guest email language if the approver left it unchanged, or the display label as a last resort.
Guests never see reason codes, and approval reasons are never shown to guests — they’re an internal record of why an out-of-policy request was accepted.
Editing and Archiving Reasons
- Edit a reason’s display label, code, or guest email language at any time. Changes apply to future decisions only — past decisions keep the reason exactly as it was recorded at decision time.
- Archive a reason to remove it from the list for new decisions. Past decisions that used it are unaffected.
- Applies to and Used when can’t be changed after creation — archive the reason and add a new one instead.
Reporting
The selected reason’s label and code are recorded on the approval decision. Integrations read the stable reason code through the Developer API on approvals and approval events — the display label isn’t exposed there, so give your reasons codes if you plan to consume decisions downstream.
Related
- Approving Expenses — The expense review flow where these reasons appear
- Rental Car Approvals — Review and act on rental car approval requests