How to use these examples

These flows are teaching models. They are not your organisation’s published processes or completed test results. Define field codes, assignments and business rules for your own scope.

  1. Describe the business need and intended outcome.
  2. Create variables and forms.
  3. Connect the flow and define assignments/actions.
  4. After structural validation, verify the real result using a test account.

For examples that explicitly assign the process number, place Calculate: Process Number → ProcessNo() → process_no immediately after the start.

Leave request

Purpose: An employee enters dates and a reason; an authorised person reviews the request.

Example variable Type Use
start_date Date Requested start
end_date Date Requested end
leave_type Selection List Organisation’s leave categories
reason Long Text Explanation 
Manual Start → Process Number → Request Form
→ Manager Review → Outcome → End

Set required fields separately for the request and review forms. Approve and Reject are example action names configured on form outputs. Add records and notifications according to your organisation’s rules.

Check: Date order, missing reason, both action paths and assigned user. Do not reduce leave entitlement, days or balances to a simple calendar-day difference; verify the applicable policy and calculation rules.

Add a supplier

Purpose: Collect and check supplier information before writing to a permitted data area.

Example fields: name (Text), tax_number (Text), email (Text), description (Long Text).

Start → Process Number → Supplier Form
→ Query Existing Record → Decision
→ Record / Correction → Outcome → End

Define duplicate criteria first. Map DB Query results to variables. Configure writes in a permitted area with complete parameters. Specify which fields the correction path reopens.

Check: A second request for the same supplier, empty results, multiple matches and repeated execution. If required, design a Counter business number separately from the process identifier.

Fault / improvement

Purpose: Assign a report to the responsible person and track the work through closure.

Example fields: equipment (Text or suitable selection), description (Long Text), priority_choice (Selection List), attachments (File), result_note (Long Text).

Start → Process Number → Report Form
→ Responsible Person Review → Work Form
→ Closure Check → End

Make the assignment source explicit. Work and closure forms may need different required fields. Check that a return action sends work to the correct task.

Check: No matching assignee, missing result note, attachments and return paths.

Procurement request

Purpose: Collect multiple request items, review them and produce a document.

Create an items Table with material, quantity, unit_price and row_total columns. A numeric row formula can be:

%quantity% * %unit_price%

Start → Process Number → Request Items Form
→ Authorised Review → Form PDF → Outcome → End

Use a summary for the total. Approval authorities and monetary thresholds are not defined by this example; follow your organisation’s policy. In Form PDF, select the completed task form and the output variable. If each row needs separate work, consider Run for each table row in Subprocess.

Check: Empty tables, zero/negative quantities, rounding, currencies, approval/rejection and PDF page breaks.

Which pattern should you choose?

Need Starting pattern Pay particular attention to
Sequential review Leave request Assignment and mutually exclusive actions
Controlled record creation Add supplier Duplicates, matching and write scope
Assignment through closure Fault / improvement Owner, return paths and results
Tabular requests Procurement Row calculations, summaries and document output

Return to the Designer checklist after choosing a model. Structural success alone does not prove the process behaves correctly in your organisation.