This article explains what happens when more than one approval rule could apply to the same trip—for example, several rules with different conditions, or two-step approval rules if you have advanced approval setup.

Use it to design your approval setup and to understand why a specific person may or may not be able to approve a given request.

Perk first determines which approval process applies to a traveler: 

• No process → no approval; 
• One process → that process; 
• Multiple processes → most restrictive. 

For more information, see Travel approval processes in Perk. Within that process, when multiple rules match the same trip, one rule is taken to determine the approval path.

One rule decides the approval path

Your company can have multiple approval processes and multiple rules inside them (e.g. different rules for out-of-policy trips, for specific cost objects, or for different traveler groups). 

When a trip is sent for approval, Perk evaluates which rules apply. If more than one rule matches the trip, only one of them is used to determine who must approve. The others do not apply for that request.

In practice: several people may receive an approval notification (one "first approver" per applicable rule). As soon as one of those people approves, that rule is locked in. The request then follows that rule only—for example, it moves to that rule's second approver in a sequential flow, or waits for the other approver in a parallel flow. The other rules no longer apply. The people who were first approvers for the other rules can no longer approve that request.

One-step approval rules can still apply independently in some mixed setups.

For example, you may set up an approval process with two rules:

• Rule 1 - One-step: Approve by Ellie
• Rule 2 - Two-step (Pro only): Approve by line manager and then finance person

In this case, if Ellie approves, the trip can be booked. No approval is needed from the line manager and finance, as Perk takes the first rule as the one to determine approval. If Ellie was also a line manager for that person, then the two-step flow takes precedence, meaning it would have to be approved by her and then by the finance person.

Why this can feel complex

• Multiple notifications. If you have rule A (e.g. Marina then Craig) and rule B (e.g. Rocky and also Lynn), and a trip matches both, Marina, Rocky, and Lynn might all get a notification. Only one of them should approve first; once they do, the path is fixed and the others cannot approve.
• Different outcomes. Who approves first changes which rule runs. If Marina approves first, Craig becomes the second approver. If Rocky approves first, Lynn must still approve. So the same trip type can end up with different approval paths depending on who acts first.
• Declines and notifications. When someone declines, the requester always gets a notification. In sequential flows, the first approver is notified if the second approver declines. In parallel flows, if one approver had already approved and the other declines, the one who approved gets a notification. With multiple rules, it may not be obvious to everyone why they can or can't act—documenting your rules and testing with sample trips helps.

Recommendations

• Keep rules simple where possible. Prioritize one-step rules. Where your business needs require complex approval, use clear two-step rules (e.g. "out-of-policy: line manager then finance") instead of many overlapping rules.
• Document who should act first. If multiple people receive a request, agree internally who is the intended first approver (e.g. "for this cost object, the line manager approves first").
• Test with real traveler and cost object data. Create a test trip that matches multiple rules and confirm who gets the request and what happens when the first person approves or declines.
• Use conditions to narrow rules. Restrict rules to specific cost objects, traveler groups, or in-policy/out-of-policy so that fewer rules apply to the same trip.