Skip to content
mcomtask User Guide

How workflows work

Many things in mcomtask move through steps before they are finished: an expense claim is submitted, reviewed, approved and paid; an advance, a leave request or a sales invoice follows its own steps. One shared system, the workflow engine, runs all of them. This page explains the idea. The screens to change a workflow are covered in Approval workflows and Who approves each step.

What a workflow is

Section titled “What a workflow is”

A workflow belongs to one kind of request and has three parts:

Part Meaning Example (an expense claim)
States The steps a request can be in Draft, Pending review, Reviewed, Approved, Paid
Actions The buttons that move it from one state to the next Submit, Mark reviewed, Approve, Mark paid
Who may act Who is allowed to press each button, and up to what amount The claimant’s superior reviews; the unit head approves

Every kind of request has its own workflow, so an advance can have a step an expense claim does not.

Who uses it

Section titled “Who uses it”

These parts of mcomtask run on workflows. Each organization starts with one standard workflow per kind, which its administrator can change.

Area Kinds of request
Expenses Expense claims
Advances Advances, advance top-ups
Petty cash Spends, float top-ups, float close-outs
Selling Quotations, sales orders, sales invoices, credit notes, debit notes, customer receipts
Buying Purchase requisitions, purchase orders
Inventory Stock movements such as adjustments
People Leave requests, vacancies
Payroll Payroll runs, payslips
CRM Leads, opportunities

Your administrator’s Workflows list shows the kinds that exist in your organization. Some appear under an internal name such as crm_lead.

Why it matters to you

Section titled “Why it matters to you”
  • The steps are the same for everyone, the people are not. A step is given to a role in the organization, such as “the claimant’s superior” or “the head of the unit”, not to a fixed person. Each claimant’s request goes to their own manager, and the setting survives a resignation or a reshuffle.
  • You never choose your own approver. An administrator configures who may act at each step, and the system works out the person.
  • Amounts can change who approves. A step can give different people authority up to different amounts, so a small claim and a large one reach different approvers.
  • Everything is recorded. Each move records who did it and when, and a reason where one is required (for example when something is rejected). You see it under Approval progress.
  • Out of office is handled. An approver can delegate, and a step moves past someone who is on leave. See Notifications and delegations.

What happens when an administrator changes a workflow

Section titled “What happens when an administrator changes a workflow”
  • A request keeps the version it started on. When an administrator publishes a new version of a workflow, requests already in progress carry on under the old one. Only new requests use the new steps.
  • The books are not affected by names. You can rename a step, translate it or add a step without changing how the accounts are posted, because posting is tied to what a step means (for example “money has been paid out”), not to its name.
  • The editor will not let a broken flow be published. For example, every step must be reachable and have a way out, and every step that needs an approver must have one. It lists what to fix.
Section titled “Related pages”