Before you build
- Write the step in one sentence: when X happens, do Y.
- Confirm the manual version works and someone actually does it today.
- Identify the record type and the exact event that starts it.
- List the exceptions people currently handle by judgement.
- Decide whether any part of it needs a human decision. If yes, keep that part human.
While you configure
- One trigger. Add the previous-state condition where the trigger is a transition.
- Narrow the conditions until the rule can only touch records you intend.
- Order actions: internal record changes, then internal notifications, then external sends.
- Confirm consent and permission gates apply to any external step.
- Decide the failure behaviour for each action — retry, stop, or notify a person.
Before you enable it for everyone
- Test against records you own, never a live customer.
- Verify it fires exactly once for one qualifying event.
- Verify it does not fire for the nearest non-qualifying record.
- Check the execution history shows what you expect, per action.
- Enable it for one team, one pipeline or one region first.
After a week, and every quarter
- Read the execution history: how many runs, how many failures, on what.
- Ask the team whether the notifications are useful or already being ignored.
- Check for duplicate effects — two rules doing the same job.
- Confirm the rule still matches the process, which has probably changed.
- Retire anything that has not fired, or that nobody defends.
The questions that prevent the expensive mistakes
- What is the worst thing this rule can do if the conditions are wrong?
- Who finds out if it fails, and how?
- What happens if it runs twice?
- What happens if the record moves backwards after it fires?
- Can a customer receive something we cannot take back?