Workflows

A workflow is the path an item follows from start to finish — the named stages it moves through, the rules about which moves are allowed, and the automatic steps that happen along the way. include GO uses workflows to drive projects, tasks, purchase orders, AR invoices, payrolls, and sales opportunities.

include GO ships with built-in workflows so you're productive on day one. Some of those — like the Purchasing and AR Invoice flows — are managed by Include and can't be changed, because their steps are tied to accounting and approval logic that has to behave consistently. Others you're free to edit, clone, or replace with workflows of your own.

This article explains how workflows work and walks you through building one.

This is the administrator's guide to setting up workflows. If you just need to move an item through its stages day to day, see How to Use Workflows.

The Building Blocks

Every workflow is made of five parts. Understanding these five ideas is most of the battle — the builder is just a place to fill them in.

Keep these five in mind as you read the rest; the workflow builder has a tab for each.

Where to Find Workflows

From anywhere in include GO, open Settings, then go to Workflows.

Navigation path: Dashboard → Settings → Workflows

You'll see a list of every workflow in your business unit, with at-a-glance counts of how many States, Transitions, Guards, and Field Locks each one has, plus its status (Active or Inactive).

Two badges tell you what you're allowed to do with a workflow:

• DEFAULT — this is the workflow new items of that type start on. Each entity type has exactly one default.
• SYSTEM — this workflow is managed by Include and is read-only. You can open it to see how it's built, but you can't change it. (This is how the Purchasing and AR Invoice flows are protected.)

Things you can do from the list

Double-click any workflow to open it. Right-click a workflow for the full menu:

• Edit Workflow — open it for changes
• Clone Workflow — make an editable copy (great for starting from an existing one — see below)
• Make Active / Make Inactive — turn a workflow on or off without deleting it
• Archive — hide it from active lists but keep it for historical reference
• Delete Workflow — remove it permanently (this can't be undone)

For a SYSTEM workflow, the only option is View (System workflow — read-only).

The Fastest Way to Start: Clone an Existing Workflow

Building a workflow from a blank slate means defining every state and every allowed move yourself. Most of the time you don't need to — you just want a tweak on something that already works.

Right-click a workflow that's close to what you want and choose Clone Workflow. include GO creates an editable copy named "… (Copy)" with all the same states, transitions, guards, field locks, and triggers. Rename it, make your changes, and you're done. You can even clone a SYSTEM workflow to use it as the starting point for your own editable version.

If you genuinely need something different, build from scratch using the steps below.

Building a Workflow from Scratch

Click New Workflow at the top of the list. A builder opens with a few details at the top and a row of tabs — States, Transitions, Field Locks, Guards, Triggers — for the five building blocks. Work through them roughly in that order.

Step 1 — Name it and choose the entity type

At the top of the builder, fill in:

• Name — what this workflow is called (e.g. "Fast-Track Projects").
• Entity Type — what kind of item it governs: Projects, Tasks, AR Invoices, Purchase Orders, Payrolls, Clock Log, or Sales Opportunities.
• Status — Active or Inactive. Leave it Active when you're ready for it to be used.
• Default — check this if new items of that type should start on this workflow.
• Description — optional, but a sentence here helps the next administrator.

⚠️ Entity Type is permanent. Once a workflow is created you can't change what kind of item it governs. If you picked the wrong type, delete the workflow and start again. (You'll see Entity Type fixed in place when you edit an existing workflow.)

Step 2 — Define the States

On the States tab, list the stages an item can be in. A new workflow starts with a single Draft state; add the rest.

For each state you set:

• Code — a short internal identifier (e.g. in_progress). Used behind the scenes; keep it lowercase with no spaces.
• Name — the label users actually see (e.g. In Progress).
• Type — an optional category hint, where the entity type offers one.
• Initial — turn this on for the one state new items start in. Every workflow needs exactly one initial state.
• Terminal — turn this on for end states (e.g. Closed Out, Cancelled). A terminal state is where an item's journey ends.
• Color — the color of the state's pill, so users can recognize it at a glance. A live Preview shows how it'll look.

For Tasks, you'll also see Sales and Production toggles on each state. These control which view bucket a task appears in on the Tasks page — flip them on for the states that belong to each view.

Order matters for readability: arrange states in the sequence work naturally flows.

Step 3 — Connect them with Transitions

States on their own don't let anything move. On the Transitions tab, define each allowed move by adding a row with:

• From State and To State — the move being allowed.
• Direction — a label for the kind of move, color-coded for clarity:
  • Forward (green) — normal progress (Draft → Estimate)
  • Lateral (blue) — a sideways move at the same stage
  • Backward — sending something back (e.g. Rejected → Draft)
• Confirm — turn this on to make users confirm before this particular move goes through. Use it for consequential or hard-to-reverse moves.
• Guard Note — an optional reminder note for yourself about this transition.

Only the moves you define here are offered to users. If a user can't move an item from one stage to another, it's almost always because there's no transition between those two states. This is deliberate — it's how you stop items from skipping required steps.

Step 4 — Lock fields per state (optional)

On the Field Locks tab, you can make specific fields read-only depending on the item's state. For each field and state, choose a rule:

• Editable — the field can be changed in this state.
• Locked — the field is read-only in this state.

Common use: lock the contract amount once a project is Sold, or lock a task's costs once it's Invoiced, so finalized numbers can't be changed by accident. Locks are enforced everywhere — a locked field can't be changed through the screen or behind it.

Step 5 — Add Guards (optional)

On the Guards tab, add conditions that must be met before a move is allowed. Each guard row has:

• From State — the state the move starts from. Choose a specific state, or leave it as * to apply the guard to any move into the target state.
• To State — the state the move goes to.
• Type:
  • Blocker (red) — stops the move and shows the message. The user must resolve the issue first.
  • Warning (amber) — shows the message but lets the user continue.
• Condition — the rule to check (entered as a condition code — see the list below).
• Message — what the user sees when the guard fires. Write it as plain, actionable guidance (e.g. "This project still has open tasks. Close them before closing out the project.").

Available conditions (type the code into the Condition field):

Pick the condition that matches what you want to prevent. A blocker on has_open_tasks for the move into Closed Out, for example, keeps anyone from closing a project that still has work outstanding.

Step 6 — Wire up Triggers (optional)

On the Triggers tab, attach automatic actions to a state. Click Add Trigger and set:

• State — which state the action is tied to.
• Direction — On Enter (fires when an item moves into the state) or On Exit (fires when it moves out).
• Trigger Action — the action to run, chosen from the list of available actions for this entity type.
• Description — optional note explaining what it does.
• Active — turn the trigger on or off.

The available actions depend on the entity type. For tasks, for example, an On Enter trigger on the Done state can automatically send the task to Accounts Receivable so it's ready to invoice — no manual handoff.

The Simulator tab is coming soon. Until it ships, test a new workflow by creating a sample item and walking it through the states yourself.

Step 7 — Save

Click Create (or Save when editing). If anything's missing — no name, no initial state — include GO will tell you what to fix. Once saved and Active, the workflow is live: new items of that type will use it if it's the Default, and existing items can be assigned to it.

Editing and Retiring Workflows

• Editing is the same builder — double-click a workflow (or right-click → Edit) and change any tab. Remember Entity Type stays fixed.
• Make Inactive takes a workflow out of use without deleting it; items already on it keep their history.
• Archive hides a workflow from active lists but preserves it for reference.
• Delete removes it permanently. Don't delete a workflow that items are still using — make it inactive or archive it instead.

System workflows can't be edited, archived, or deleted — clone one if you want an editable version.

Tips & Best Practices

• Clone before you build. Starting from an existing workflow is faster and less error-prone than a blank one.
• Map your stages on paper first. Decide the states and which moves are allowed before opening the builder; the tabs then just capture decisions you've already made.
• One initial state, clear terminal states. Every workflow needs exactly one starting state and should have obvious end states.
• Write guard messages as instructions. "Assign a project manager before moving to Sold" beats "PM check failed." The user should know exactly what to do.
• Lock fields that represent commitments. Contract amounts, posted costs, and invoiced totals are good candidates once the relevant state is reached.
• Don't delete live workflows. Inactivate or archive instead, so history and in-flight items are preserved.
• Test by walking an item through it before making the workflow your default.

Related Topics

• How to Use Workflows — moving items through their stages day to day
• Purchase Order Workflows — the built-in, system-managed purchasing flow
• AR Invoices — the built-in, system-managed invoice flow