Approval Workflows

Retrieves an approval workflow

Changed on

Returns one approval workflow: the conditions that decide which entries it applies to, and the ordered layers of approvers that must sign off. This is the control definition, not a record of approvals given. Approval workflows are not versioned — the response describes the workflow as it stands now, and an update overwrites it in place.

get/approval-workflows/{approval_workflow_id}

Request

Path parameters

approval_workflow_idstring uuid required

UUID of the approval workflow to be used in this operation.

Response

OK

idstring uuid required
namestring required
type'JOURNAL_ENTRY' | 'CONTRACT' | 'INVOICE' | 'BILL' | 'CHARGE' | 'CHARGE_REVERSAL' | 'REIMBURSEMENT' required

The kind of record a workflow applies to. Contract and Invoice are retained for backward-compatible reads but cannot be updated through this endpoint.

activeboolean required

Only active workflows are evaluated. Read-only here: a workflow is activated and deactivated in Rillet, so this value can change without a definition update.

priorityinteger required

Evaluation order among the active workflows of the same type, ascending and zero-based — the first workflow whose conditions match is the one applied, and later ones are skipped. Assigned by the server: a workflow is put last when created, and again when reactivated. Not necessarily unique; ties are resolved by id.

methodsApprovalWorkflowMethod[] required

How approvers are asked to act. IN_APP is the only method Rillet acts on today; EMAIL and SLACK can appear on workflows configured before they were withdrawn, and no notification is delivered for them.

submission_sourcesApprovalWorkflowSubmissionSource[]
updated_atstring date-time required

ISO 8601 timestamp in UTC timezone (must end with 'Z'). Covers activation and reordering as well as definition changes.

Changes