Agiled Docs

Create a workflow when a repeatable business process should run automatically.

Start with the business outcome, not the automation tool. Write down what should start the process, which record should change, who should be notified, and what the successful result looks like.

If the process cannot be described clearly in plain language, document it first and automate only the parts that are consistent.

Use a workflow only when the same rule should run repeatedly. One-off cleanup work is usually safer as a task or manual checklist.

Create From The Workflow List

Open Workflows.
Select Create.
Add a workflow name.
Choose a trigger or start from a template.
Add the first action.
Save the workflow as a draft.

Keep the first version small. A workflow with one trigger and one action is easier to test than a large automation built all at once.

After the first action works, add conditions, delays, or more actions one at a time and review run history after each change.

Do not publish a large workflow before testing the trigger and first action. Early mistakes can create duplicate records, noisy notifications, or customer messages at scale.

Name And Description

Use a name that explains the outcome, such as Create task from form submission or Notify team when invoice is overdue.

Use the description to explain when the workflow should run and who owns it.

Include the business owner in the description when the workflow affects finance, customers, HRM, or external systems.

Before Building

Confirm:

The module that owns the trigger is enabled.
Required fields exist on the source record.
The workflow owner understands the process.
Connected apps are installed if an action needs them.
Customer-facing messages have approved copy.
The first test can run on one safe record.

Also decide how the workflow will be stopped if it misbehaves. High-impact workflows should have an owner who can pause them quickly.

Write down the expected result before building. For example: "When a high priority ticket is created, notify support and create a follow-up task assigned to triage." This makes the first test easy to evaluate.

Draft First

Keep workflows in draft while you configure triggers, actions, conditions, and delays. Publish only after simulation or a controlled test shows the workflow creates the expected result without duplicate records or messages.

After publishing, watch the first real run and inspect run detail. Do not assume a published workflow is healthy until a real trigger has completed correctly.

Build one branch at a time. Add the trigger, one action, test, then add the next condition or action. This makes failures easier to trace in run detail.

Troubleshooting

If a workflow cannot be saved, check required trigger and action fields.

If a workflow creates duplicates, pause it and review trigger conditions before running another test.

If notifications go to the wrong place, review recipient, channel, and connected app settings in the action.

If the workflow should stop temporarily, pause it before editing high-impact triggers or customer-facing actions.

Workflow Design Checklist

Before publishing:

one clear business outcome exists
trigger is narrow
first action is tested
customer-facing copy is approved
connected apps are healthy
duplicate behavior is understood
owner and pause path are known

Create A Workflow