Contracts expose the weakness of a badly designed flow faster than any other document: values change, thresholds change, managers move roles. A flow that hard-codes those rules must be rewritten at every change. This model avoids that.

Data structure

Three artefacts, none of which is the flow itself:

  • Contracts library: columns for counterparty, value, term, area, status and owning manager.
  • Thresholds list: minimum value, maximum value and the approver group for each stage.
  • Approval history list: an immutable record of each decision - document, stage, approver, outcome, comment and date.

The thresholds list is the heart of the design: it turns a volatile business rule into data the business itself can edit.

Stage 1 - Trigger and input validation

The flow triggers on creation or change. Its first action approves nothing: it validates. If value, counterparty or manager are empty, the document returns to its author marked Incomplete and the run ends.

This check removes the biggest source of rework: approvers receiving documents that should never have entered the queue.

Stage 2 - Resolving the threshold

With the value at hand, the flow queries the Thresholds list for the matching band and retrieves the sequence of approver groups. The result is an array of stages - one, two or three levels - without the flow knowing in advance.

Stage 3 - Sequential approval loop

An Apply to each walks the resolved stages. On every iteration it:

  1. Sends the approval to the current stage group, including the document link and a summary of the data.
  2. Writes the decision to the History list, with a mandatory comment on rejection.
  3. On rejection, sets the status to Rejected, notifies the author and breaks the loop.
  4. On approval, moves to the next stage.

When the loop completes with no rejection, the status becomes Approved, the document is published as a major version and the retention label is applied.

Stage 4 - Deadline escalation

A parallel branch monitors response time. At D+3 with no decision it reminds the approver; at D+6 it notifies the registered delegate; at D+10 it escalates to the process owner with the document flagged critical.

This branch is what separates a demo flow from a production flow - and it is usually the missing piece when people complain the process stalls.

Stage 5 - Audit trail

Each decision written to the History list forms the trail auditors ask for: who approved, when, against which value and with what justification. Because the list is separate from the library, it survives deletion or archiving of the document.

If answering "who approved this contract in March?" requires opening Power Automate run history, the design is wrong. The answer belongs in a queryable list.

Maintenance

Threshold changed? Edit one row. Area manager changed? Update the group. The flow stays untouched - which is the whole point of keeping business rules out of code.