Create a workflow rule

Available on all plansHow-toOpen in DealJourney
  1. 1Open Workflow Automation from the sidebar and choose Add workflow to start a new rule.
  2. 2Choose the trigger: the record type, then the event on it. Only events that exist for that type are valid. See "What can trigger a rule".
  3. 3Add Conditions to narrow which events count. Do not skip this. No conditions: this runs for every {{entity}} event, not just the ones you have in mind.
  4. 4Add the actions under Actions (in order), in the order they should run.
  5. 5Name the rule after what it does, so the list stays readable when there are thirty of them.
  6. 6Save, then set it Active when you are ready for it to run.

Build it narrow first. Add a condition that limits the rule to one customer or one owner, watch it fire correctly in the run history, then widen it. A rule tested at full scope has already sent the emails by the time you find the mistake.

For an owner condition, choose the assigned-person field and then a teammate by name. On quotes this is Responsible, which also determines sales responsibility. Use equals or does not equal to match a person, or is empty to find unassigned records. Saved conditions keep showing the person's name in both the flow and list views.

Correcting a condition you already saved. Each saved condition has a pencil beside it (Edit condition). It reopens the condition in the form you built it in, with the field, the match and the value filled in, and Save condition puts the corrected version back where it was in the list. Removing it and adding it again also works, but the new one lands at the bottom, which changes the order the rule reads them in.

A condition on what was bought reads one line at a time. An invoice usually carries several lines: the thing that was ordered, and postage, and sometimes a fee. A condition on the products asks whether any one of those lines is the product you named, so a rule for one product still fires on an order that also carries shipping. Match on the product number when two products have similar names, since contains on a name also matches a longer name that starts the same way.

Asking Dealy to build it. You can describe the rule to Dealy using the stage names you see, in your own language. Dealy saves the stage it really is, and the confirmation card shows the stage under the name you know. If no stage matches what you said, Dealy lists the stages you have and asks which one you mean rather than saving a rule that can never run. When a similar rule already exists, Dealy asks whether to replace it, which switches the old one off, or keep both.

Check for a rule that already does this. Several rules can fire on the same trigger, and they all run: {{count}} other active rules also run unfiltered on this trigger, so one event fires all of them. Two overlapping rules means the customer gets two emails, and the second one is rarely traced back to the rule somebody added months ago.

Turning a rule off is a status change rather than a deletion. Deactivate rather than delete when you are unsure: a deleted rule takes its history with it, and its run record is how you work out what it did.

Control repeat entry and stopping. In the trigger settings, turn on Journey controls. Choose whether a record may return after its previous journey finishes, only enter once, or return after a chosen number of days. The same record cannot have two active journeys in the same workflow. These controls also apply when you manually start existing records.

Under Stop when, choose conditions that make further follow-up unnecessary. For example, Received a reply since this journey started can stop reminders after incoming contact, or a changed sales stage can stop follow-up for a lost deal. Stops are checked before a waiting journey continues and before its separately delayed actions run. An action already sent cannot be undone.

Preview existing records before launching. Save the rule, then open Preview existing records. Page through records and see whether each one meets the current entry conditions, stop conditions and repeat-entry rules. Records you do not have access to are excluded. This checks today's state; it does not recreate a historical event or prove that a past field transition happened.

To start selected records, turn the saved rule on and choose Enroll selected records. This is a real manual entry into the saved workflow and can send messages. The records are queued for the scheduled processor. A workflow edited since the preview requires a fresh preview first. Use Test run when you want to inspect action results without starting real journeys.

Open Journeys and approvals from run history to see waiting, completed, stopped and failed journeys, handle your assigned approvals, or cancel a waiting journey. This view shows your own workflows and approvals; workspace administrators can review all journeys.

Was this helpful?

Related