Configuring Approval Workflows

Approval workflows decide which documents need sign-off and who has to sign. You configure them once, in the Access Control → Approval Workflows screen, and every matching document is then routed automatically.

You need the Approval Workflows permission to open this screen. The built-in Owner and Admin roles include it. Custom roles can be granted it from Access Control → Roles.

What a Workflow Defines

A workflow has three parts:

• A subject type — the kind of document it reviews. Today: Purchase Order, Sales Order, Inventory Adjustment.
• A match condition — the rule that decides whether this workflow applies to this document. Empty matches everything; you build it from one or more conditions joined with AND, OR, or NOT.
• A chain of steps — the ordered list of approvers who must sign before the document is final.

When a user submits a document, Beelocity evaluates every active workflow’s match condition against the document, picks the highest-priority match (lowest priority number), and runs its steps in order.

Creating a Workflow

1. Go to Access Control → Approval Workflows.

2. Click Create Workflow.

3. Fill in the basics:

   • Name — e.g. “Big POs over 5M DZD”.
   • Subject Type — pick the document this workflow approves.
   • Priority — lower runs first. Use 100 for catch-all, 10 for specific overrides.
   • Default SLA (hours) — applied to any step without its own SLA. Blank = no escalation.
   • Active — leave checked. Uncheck to retire a workflow without losing history.
   • Auto-approve when no steps configured — a matching workflow with zero steps approves the document on the spot. Useful for “below this threshold, no human review”.

4. Build the Match condition in the rule builder.

5. Click Create Workflow. The drawer closes and your new workflow appears in the list.

Tip — start with a catch-all. Every subject type needs at least one workflow whose condition is empty (matches everything). Otherwise documents that match nothing get rejected at submit time. A common pattern: priority 100 catch-all with one default approver, plus priority 10 specific overrides for large amounts or risky partners.

The Rule Builder

A rule is built from condition rows joined by a combinator:

• All of (AND) — every condition must match.
• Any of (OR) — at least one condition must match.
• None of (NOT) — wraps a single condition or sub-group and inverts it.

Each row has three parts:

You can nest groups by clicking Add group inside an existing group. Use this for combinations like “PO over 1M AND (warehouse is W1 OR warehouse is W2)”. The compiled rule is shown live below the builder so you can verify the shape before saving.

Examples

“Purchase orders of 5 000 000 DZD or more”:

• All of (AND), one row: Total Amount ≥ 5000000.

“Sales orders to a strategic client OR over 10M”:

• Any of (OR), two rows:
  • Client is one of [Acme, Globex] (or whoever your strategic clients are).
  • Total Amount > 10000000.

“Damage adjustments above 100 000 DZD in absolute value”:

• All of (AND), two rows:
  • Adjustment Type is DAMAGE.
  • Total Cost Impact |x| ≥ 100000.

Adding Steps

Open a workflow from the list to see its detail page. The steps grid is below the workflow header. Click Add Step to add an approver.

Each step has:

• Level — sequence (1, 2, 3, …). Steps run in level order.
• Approver Type — three options:
  • Specific user — pick one organization member by name.
  • Anyone with a role — anyone holding the named role can approve. The first to act wins.
  • Originator’s manager (N levels up) — +1 is the direct manager, +2 is the manager’s manager, etc. Resolved via your hierarchy at submit time.
• SLA (hours) — overrides the workflow default for this step.
• Escalation — what happens if the SLA expires with no decision. Same three approver options, plus “No escalation” (the request just stays pending).
• Notes — free-form text shown to admins; not visible to approvers.

Steps can be edited or deleted at any time. Changes only affect future submissions — in-flight requests keep the chain they were assigned at submit time.

Common Patterns

Two-tier approval by amount

• Workflow A — priority 10, condition Total Amount ≥ 5000000, two steps: department manager → finance director.
• Workflow B — priority 100, condition empty (catch-all), one step: department manager.

Auto-approve below a threshold

• Workflow C — priority 50, condition |x| < 5000 on Total Cost Impact (for adjustments), zero steps, Auto-approve when no steps configured on. Tiny adjustments approve automatically; everything else falls through to higher-priority workflows.

Credit-checked sales orders

• Workflow D — priority 10, condition Client credit limit exceeded (named expression that compares the client’s outstanding balance + this order against their credit limit), one step routed to a “credit_controller” role.

Editing and Retiring Workflows

• Edit — click the workflow name (or use the row’s Edit action). Changes apply to new submissions; in-flight requests are unaffected.
• Retire — uncheck Active in the workflow form. Inactive workflows are skipped during matching but their history is preserved. Prefer this over deleting.
• Delete — only if the workflow has never been used. Deleting a workflow with active or historic requests can break audit trails.

What End Users See

Once a workflow is in place, the people who submit the documents and the people who approve them don’t need to know any of this configuration exists. They use the document screens (Purchase Orders, Sales Orders, Inventory Adjustments) and the Approvals → Inbox. The workflow runs invisibly between them.