A workflow describes the stages an object passes through, and the moves allowed between them.

What a workflow is #

Most business information does not simply exist — it progresses. A request is submitted, reviewed, approved, and closed. An invoice is received, checked, approved, and paid. An incident is reported, investigated, and resolved.

A workflow captures that progression. It defines the stages, called states, and the permitted moves between them, called transitions. Once a workflow is attached to a dataset, every object in that dataset sits in exactly one state and can only move along the transitions you defined.

The value is not only in recording where something is. It is in making the wrong move impossible. If there is no transition from Draft to Paid, nobody can jump an invoice straight to Paid, whatever they intend.

Workflow states #

A state is one stage in the process. States are the nouns of the workflow: Draft, Submitted, Under review, Approved, Rejected, Closed.

Each state has:

• a name, which is what users see;
• an optional description, explaining what the state means;
• a colour and an icon, so the state is easy to recognize in a table;
• a start state flag, marking where new objects begin.

Exactly one state should be the start state. When an object is created in a dataset with a workflow, Auclio places it there.

Keep the number of states small. Each one has to be understood by the people using the application, and states that nobody can explain the difference between are usually one state.

Workflow transitions #

A transition is a permitted move from one state to another. Transitions are the verbs: Submit, Approve, Reject, Reopen, Close.

Each transition has:

• a name, describing the action — a transition left unnamed is labelled by the state it leads to;
• an optional description;
• a from state and a to state;
• an optional trigger, which decides whether a person performs it or Auclio does.

A transition without a trigger is manual. A user chooses it, and it appears to them as an available next state.

A transition with a trigger is automatic. Auclio performs it on its own, in one of two ways:

• after a number of days — the transition fires a set number of days after the object entered the source state. Zero days means immediately.
• once criteria are met — the transition fires when the object’s values satisfy conditions you define.

Automatic transitions are how a workflow does work rather than just recording it: escalating a request that has been waiting a week, or closing a task when its completion date is filled in.

Where more than one automatic transition could fire, the Evaluation priority decides the order. It runs from 0 to 100, and the lowest number is considered first. Only one transition fires in a single pass.

Transitions are directional. Allowing a move back from Approved to Draft requires a second transition in that direction.

How workflows relate to datasets #

A workflow belongs to an application, and is attached to a dataset through the dataset’s Default workflow setting. Every object in that dataset then follows the workflow.

One workflow can be used by several datasets. A simple Draft, Active, Closed workflow might serve requests, incidents, and tasks alike.

A dataset without a default workflow has no states, and its objects simply exist. That is the right choice for reference data such as countries or industries, where there is no progression to record.

Attaching a workflow to a dataset that already holds objects does not place those objects in a state. Only objects created after the workflow is attached start in the start state. An object that already existed takes a state when someone sets its Workflow value, which places it in the start state at that point.

How workflows appear in widgets #

Attaching a workflow to a dataset makes two extra properties available on it:

• Workflow — which workflow the object follows;
• State — which state the object is currently in.

These behave like ordinary dropdown properties, so they can be added as a column in a Table widget or as an item in a Text Grid widget. They cannot be edited in the dataset dialog, because Auclio manages them.

Where the object’s state is shown as an editable column, users change the state by selecting from it. The options offered are not every state in the workflow — they are the states reachable from the object’s current state, through a manual transition. Automatic transitions are not offered, because they are not a user’s to choose. A row that is still being created has no current state yet, so there every state in the workflow is offered instead.

Because each state carries a colour, a table with a state column is readable at a glance. Assign colours deliberately: one colour family for in-progress states, another for finished ones.

The State property can also be used in filters, so a page can show only the objects awaiting review.

Auclio and M-Files workflows #

Workflows come from two places, and they behave differently.

Auclio workflows are created and edited in the application’s Workflows tab. You define the states, the transitions, and the automatic triggers, and you can change them at any time.

M-Files workflows are synchronized from a connected vault. The vault owns them, so in Auclio they are read-only: their states, transitions, and triggers are maintained in M-Files Admin and appear in Auclio as they are defined there. Opening one in Auclio shows it in preview. Automatic transitions on a synchronized workflow are performed by M-Files, not by Auclio, and any M-Files trigger mode that Auclio does not model arrives as a manual transition.

There is one exception. State colours are an Auclio setting, not an M-Files one, so you can set the colour of each state on a synchronized workflow. The colours survive future synchronizations. Nothing else about a synchronized state is yours to set: it arrives with its name and its start-state flag, and it carries no description or icon in Auclio.

Workflows that are deleted in the vault are removed from Auclio at the next synchronization.

A dataset uses one workflow, and the Default workflow picker offers the workflows belonging to the dataset’s own connection. Workflows you build in Auclio belong to the application’s internal connection, and synchronized workflows belong to the vault’s connection. In practice, then, a dataset stored in Auclio is offered the workflows you built, and an M-Files dataset is offered the workflows synchronized from its vault.

That pairing is normally what you want. An M-Files dataset whose objects already move through a vault workflow should use that synchronized workflow, so that Auclio reflects what the vault is doing rather than tracking a second, separate state.

The restriction lives in the picker rather than on the server, which only requires the workflow and the dataset to belong to the same application. The Workflow property on an individual object is offered the wider list: every workflow in the application, whichever connection it came from.

See Create and manage a workflow for detailed instructions on building a workflow, and Connect Auclio to M-Files for detailed instructions on connected datasets.