Building and Testing

Workflows act on real records the moment they are active. The sequence below is how to avoid finding that out the hard way.

Where to find it

Architect Panel → Automation:

• Workflow Builder — the canvas, nodes and edges
• Worklist — what is waiting on a person

Build in this order

1. Write down the process in sentences first. If you cannot, the workflow will not help.
2. Create it as a draft with its trigger.
3. Prove the trigger fires with a single harmless node.
4. Add the happy path, end to end.
5. Add branches, connecting both ports of every condition.
6. Add waits and timers, with short durations.
7. Test every path with real records.
8. Set the real durations and activate.

Prove the trigger before anything else

It removes the largest unknown. A workflow that is not running at all and one that is running and failing look identical until you know a run was created.

Test on records that do not matter

The workflow sends messages, changes statuses and creates records. Use test records, and make sure any e-mail address involved is one you control.

A workflow tested against real customer records has contacted real customers.

Test every path

Not the one you expected. Each branch, each SLA outcome, each approval decision. The untested branch is always the one that handles the difficult case, which is where it matters most.

Read the run history for each test

It records every step and its outcome. That is where you see a node that succeeded but did nothing, or a branch that went the way you did not intend.

Activating is a live change

From that moment it acts on real records, including ones already in flight. Consider what a workflow triggering on status change does to a hundred records somebody bulk-updates that afternoon.

Watch the first day

Look at the runs that happened, not at whether anybody complained. Most workflow problems are visible in the first day’s history and invisible to users until later.

Change it the same way

A change to a live workflow is a live change. There is no draft copy of an active workflow, so significant changes are best made by building a replacement and switching over.

Tell people

A workflow changes what the system does to their work. Somebody who receives an unexpected automated message about their own case will raise it as a fault.

Worked example

A team wrote its process down, proved the trigger, built the happy path, then tested each of five branches with test records and read the run history for each. It activated on a Tuesday morning and reviewed every run that afternoon, which caught a condition branching the wrong way for one case type.

Recommendations

• Prove the trigger first.
• Test with records and addresses you control.
• Test every branch, reading the run history each time.
• Review the first day’s runs after activating.