Skip to content

CapEx approval workflow

Configure who signs off on CapEx claims and the gates each claim has to pass before it lands as a completed booking.

The CapEx approval workflow is org-wide — one workflow per organisation, applied to every project under capitalisation review. You configure it once at Settings > CapEx approval, and every claim from that point on follows the same path.

The two-stage shape

Every CapEx workflow has the same fixed shape:

StageTypePurpose
ApprovalAPPROVALReviews the rationale and the classification. Claim moves from PENDING_RATIONALE / IN_REVIEW to APPROVED here
CompletionCOMPLETIONMarks the claim as booked. Claim moves to COMPLETED here

You cannot add or remove stages. You can change who is on each one.

Adding approvers

For each stage:

  1. Click Add member.
  2. Pick a user from the org. The combobox filters out users already on that stage.
  3. Save.

Approvers are users, not roles. If someone leaves the team, remove them from the stage and replace them — the workflow does not auto-route by role or manager hierarchy. (For role-based or manager-based routing, see the budget approval workflow, which has more flexibility.)

What each stage gates

Stage transitions are server-validated. A user not listed on a stage cannot move a claim through that stage, regardless of other permissions. This is intentional — capitalisation decisions need to be auditable to a named individual.

The states a claim moves through:

AI_DRAFTING
   -> PENDING_RATIONALE   (rationale writer not yet submitted)
   -> IN_REVIEW           (rationale submitted, waiting on Approval stage)
   -> CHANGES_REQUESTED   (Approval stage rejected, sent back to owner)
   -> APPROVED            (Approval stage accepted)
   -> COMPLETED           (Completion stage marked as booked)

REJECTED is a terminal state for claims that should never have been raised.

Saving the workflow

The page saves changes in place. First-time setup creates the workflow; subsequent edits update it. After each save the page re-reads the workflow from the server so what you see matches what's live.

Permissions

Configuring the workflow requires SETTINGS_FINANCIAL_CONFIG_*. Approving a specific claim requires being on the relevant stage as an approver — that is checked separately at the per-claim mutation, not at the settings page.

What this does not configure

  • Who can raise a claim — that is governed by ROADMAP_PROJECTS_UPDATE and the per-project owner.
  • The rationale prompts — those live in the rationale writer and are framework-driven, not configurable per org.
  • Notifications — approvers are notified through the standard in-app and email channels when a claim hits their stage. No per-stage notification config today.

Flowstate Documentation