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 under the Workflow & Scheduling section click Workflows.

Navigation path: Dashboard → Settings → Workflow & Scheduling → 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.

Click Add Field to pick a field from the list for that entity type. Fields are organized into groups — Identity, People, Dates, Financial, Detail, Classification, and Actions — and most carry a short description explaining when locking them makes sense.

Locks aren't limited to data fields. The Actions group lets you lock buttons: lock Add Resource to stop new resource rows while still allowing existing ones to be edited, lock Log Time to stop time being booked against a task, or lock Save for a fully frozen state where nothing is persisted at all.

Which item types support field locks

Field locks are available for four entity types:

• Projects
• Tasks
• AR Invoices
• Purchase Orders

For Payrolls, Clock Log, and Sales Opportunities the Field Locks tab opens but the field list is empty — those item types don't have lockable fields yet. Everything else on those workflows (states, transitions, guards, triggers) works normally.

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. On every one of the four types, a locked field is greyed out and can't be typed into, and a locked action button is hidden or disabled.

On AR Invoices, locks go a step further and are also enforced on save: if a locked field somehow reaches the server with a changed value, the whole save is rejected and the user is told which field was locked — for example "Tax rate can't be changed on a posted invoice." Nothing is partially written.

🔒 Invoice money fields have a floor. On AR invoices, the amount-bearing fields — invoice date, tax rate, subtotal, tax amount, invoice total, line item price and quantity, and adding or deleting line items — are protected on every state past the first one, whether or not you configured a lock for them. This is deliberate: a missing or mis-edited lock rule can't quietly reopen the numbers on a posted invoice.

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. Pick it from the dropdown — start typing to filter the list. Conditions are shown by their friendly name (Has Open Tasks), and the full list is 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 (choose one from the Condition dropdown):

The dropdown lists every condition, whatever entity type the workflow governs. A condition that doesn't apply to the item type simply never fires — so check the Applies to column before picking one, or your guard will look configured but do nothing.

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.

⚠️ Read the "Fires when" column, not just the name. A few conditions read backwards from how they behave. Has Bill Type fires when a task has no bill type; Account Linked fires when no account is linked; Parent Project Sold fires when the parent project is not sold. In each case the condition is checking for the problem, so a Blocker on it means "you can't move on until this is filled in."

Two of the newer conditions are worth calling out:

• Has Bill Type (Tasks) — a blocker on the move into Sent to AR stops a task reaching invoicing without anyone having said how it bills. It only checks that some bill type is selected; you can't require a particular one.
• Task Already Billed (Tasks) — best used as a Warning rather than a blocker. A task that's already on an invoice won't generate a second one, so the warning tells the user no new draft is coming instead of leaving them to wonder why nothing happened.

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.

Sending a notification — and choosing who gets it

One trigger action deserves its own walkthrough: Send Notification, which emails or in-app notifies people whenever an item reaches (or leaves) a state. Pick it as the Trigger Action and a Notification configuration panel opens underneath the row with everything the message needs.

Subject and Body are the message itself. Both accept variables that get filled in with the real item's details when the notification goes out. Rather than memorizing them, put your cursor where you want the value and click Insert variable — a menu lists what's available for this item type, and the token drops in at the cursor. Every item type offers from_state and to_state; most add their own fields and related records, such as a task's project, account, or assigned team. A subject like "Task {{entity.name}} moved to {{to_state}}" arrives as "Task Rooftop Unit Swap moved to Done." The body is plain text — line breaks become paragraphs, and any HTML is shown as text rather than rendered.

The Send to box is where you choose the recipients. It's one combined picker holding three different kinds of recipient, and you can mix as many as you like in a single trigger:

• Roles on the item — the most useful kind. Instead of naming a person, you name a position on the item, and include GO looks up whoever holds it at the moment the trigger fires. Pick Responsible on a task workflow and each task notifies its own responsible person — no per-item setup, and it stays correct when the assignment changes.
• Named users — a specific include GO user who should always be told, whatever the item says. Start typing a name or email address and pick from the results. Only active internal users appear here; client-portal users are never offered.
• Typed email addresses — for someone who has no include GO login at all, such as an outside adjuster or a client's AP inbox. Use the second box, "Or type email addresses", and separate multiple addresses with commas. Anything that isn't a valid address stays in the box with an error so you can correct it rather than losing it.

Everyone you select is notified once, even if the same person is picked twice (say, they're both the Responsible person and a named user).

Which roles you can choose depends on the item type:

Note that Consulted, Informed, Billing Contacts, and All Invoice Contacts can each cover several people at once — everyone on the list is notified.

For Payrolls and Sales Opportunities no roles are registered yet, and the panel says so — notify a named user or a typed address instead.

A role only reaches someone who has an include GO login. If the person filling a role has no user account, there's nobody to notify and they're skipped — add them as a typed email address if they still need the message.

Finally, choose the Channels — Email, In-app, or both. At least one is required. In-app notifications can only reach real include GO users, so if your only recipient is a typed email address you must include the Email channel; the panel warns you when the in-app channel would go nowhere.

Notifications are best-effort and deliberately never block the move itself. If a message can't be delivered — a bad address, a mail outage — the item still changes state and the remaining recipients still get theirs.

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.
• Notify roles, not names. Picking Responsible or Project Manager keeps working when people change jobs or an item is reassigned. A named user is the right choice only when that specific person should be told regardless of who's on the item.
• Check the "Fires when" column before saving a guard. Several condition names read backwards from what they check, and a guard pointed the wrong way silently allows exactly what you meant to prevent.
• 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
• Purchasing & Payables — where the built-in, system-managed purchasing flow runs
• AR Invoices — the built-in, system-managed invoice flow