Workflow

The workflow engine is what makes Project Four configurable rather than fixed. A transaction type is defined by its states, the transitions between them, and who may perform each transition.

Concepts

Workflow building blocks

Field	Type	Required	Description	Notes
State	Definition	Yes	A named position in the lifecycle, e.g. Draft or Approved.	Exactly one state at a time
Transition	Definition	Yes	A permitted move from one state to another.	Named after the action, e.g. Submit
Guard	Rule	No	A condition that must hold for a transition to be offered.	E.g. total is within the approver limit
Action	Rule	No	Something that happens as a side effect, such as a notification or a posting.
Role binding	Permission	Yes	Which roles may perform the transition.

Workflow building blocks

The default transaction workflow

Project Four ships with a four-state workflow that covers most approval processes.

Default workflow

Step	Action	Who	Result
1	Create	Originator	Draft
2	Submit	Originator	Pending Approval
3	Approve	Approver	Approved
4	Return	Approver	Draft, with comments
5	Reject	Approver	Rejected (terminal)
6	Close	Originator or Approver	Closed (terminal)

Default workflow

Note

Return and Reject are different on purpose. Return sends the transaction back for correction and keeps it alive; Reject ends it. Using Reject where you meant Return forces the originator to start again.

Approval routing

Routing is driven by the transaction value against the approver’s limit.

The transaction is submitted

The engine reads the transaction total and the originator’s organisation unit.

Candidate approvers are found

Every user whose role grants Approve on this transaction type, and whose approval limit is at or above the total, within the same organisation unit.

The transaction is routed

If one candidate is found, it goes to them. If several, it goes to all of them and the first to act decides.

Escalation

If no candidate has a sufficient limit, the transaction escalates to the next organisation level until one does.

Warning

A transaction with no possible approver anywhere in the hierarchy stays in Pending Approval indefinitely. The Unroutable Transactions report lists these — check it weekly.

Expected result

The transaction shows Pending Approval with the named approver (or approvers) visible on the transaction, and each of them sees it on their dashboard.

Customising the workflow

Add a stateAdd an approval levelChange who can approve

Open Configuration → Workflow, select the transaction type, and add the state with a name and a type (in-progress or terminal). Then add at least one transition into it and one out of it — a state with no way in is unreachable, and the validator will reject the workflow.

Add a second approval state and route between them with guards on value. Two-level approval is the most common customisation: one level up to a threshold, two above it.

Edit the role binding on the transition rather than the workflow itself. Changing a binding takes effect immediately for transactions already in flight; changing the state graph does not.

Danger

Editing a live workflow affects transactions already in flight. A transaction sitting in a state you delete becomes unroutable and has to be moved by an administrator, one at a time. Make workflow changes in a test organisation first.

Frequently asked questions

QCan a transaction skip a state?

Only if a transition exists that goes directly there. The engine never skips — if it looks like it did, there is a transition you had forgotten about.

QWho can approve their own transaction?

Nobody, unless self-approval is explicitly enabled for the transaction type. It is off by default and turning it on is recorded in the audit log.

QWhat happens if the approver is on leave?

Use delegation on the user record. Delegated approvals are recorded against both the delegate and the original approver.

Related documentation

• Creating a Transaction
• Approving a Transaction
• Roles