A common pain point I'm seeing across threads is teams struggling with ad-hoc budget approvals in Runway. The default settings often aren't enough for enforcing proper financial controls, leading to confusion and process gaps.
This guide outlines a method for building a custom approval chain for budget sign-offs, using a tiered approver model. The goal is to create a clear, automated path based on the request amount. For example:
* Requests under $1k route to the department lead.
* Requests between $1k and $5k require additional VP approval.
* Anything over $5k must be flagged for the finance controller.
The key is configuring separate "Budget Approval" stages for each tier and using conditional logic based on a custom "Request Amount" field. You'll set the approvers for each stage and define the conditions under which each stage becomes active. This moves the process beyond a single, generic approval step.
Remember, the effectiveness hinges on your field setup and conditional rules being airtight. Test this workflow with dummy data before rolling it out to live budgets. I'll monitor the thread for specific configuration questions or edge cases teams have encountered.
—AF
—AF
This tiered approach makes a ton of sense. Have you run into issues where the 'Request Amount' field gets changed *after* the first approval stage triggers? I've seen workflows break when someone edits the number midway, and the conditional logic doesn't re-evaluate.
Might be worth adding a validation rule to lock that field once the first approval stage is initiated. Or even better, having a separate audit log field that captures the original submission amount.
Data is the new oil - but it's usually crude.
That's a good point about the amount changing mid-process. Wouldn't the conditional routing break if someone edits the request amount field from, say, $500 to $6000 after it's already sent to the department lead?
Maybe a system could copy the original amount into a separate locked field when the request is first submitted. That way the approval logic always checks against the initial number, even if the main field gets updated later for record-keeping.
PipelinePadawan
Good start on the tiers, but you're missing the trigger. Conditional logic based on a field is only half the battle.
Where does the "Request Amount" value come from? If it's manually entered in a form, you need a validation step before any approval stage runs. Otherwise, you'll fire approvals based on typos or placeholders.
Your first stage should be a system check, not a human approval. Validate the amount is a number, is positive, and matches your required format. Then lock it. After that validation passes, kick off your tiered approval chain.
Thanks for putting this together. I'm new to setting up workflows in Runway, and seeing a clear example like this is super helpful. It makes the whole conditional logic thing click for me.
The tiered model seems like a perfect fit for how our team handles purchases. I can already think of a few old requests that got stuck because no one knew who should sign off.
Quick question - when you set the approvers for each stage, can you assign a backup person in case someone's out of office? That's a hiccup we run into a lot.
The locked field idea just shifts the problem. What happens when you need a legitimate update? Say you budgeted $500 for a license but the vendor quote comes in at $550 during the approval process. With a locked "original amount" field, you either can't update the record or your workflow is evaluating against a stale, incorrect number.
The core issue is a process that allows unilateral edits mid-stream. The better fix is proper permissions, not another field.
Show me the TCO.