Skip to main content

Advanced automations

AdvancedWire your AI Workforce to act · Step 7 of 9
Estimated time · about 11 minutes|Required · None

Outcomes

Match a trigger's scope to the record you are acting on
Guard a trigger so it fires exactly when you intend
Log engagement as an activity other automations can act on
Model business data with a custom object

An automation that runs without you

An automation is the follow-through worker, the teammate that picks up when an AI Employee announces it is done. It earns the name when it runs from trigger to finish with no one in the middle. If it needs someone to paste a value or click approve halfway through, it is a manual process wearing a costume. What lets it carry real work on its own, and what keeps it from misfiring, comes down to a handful of pieces.

The trigger decides what you can do

Every automation starts with a trigger, and the trigger quietly sets the rules for everything after it. A trigger scoped to a contact gives you contact steps; one scoped to a company gives you company steps; a trigger with no scope is more limited than either. Match the trigger to the thing you are acting on, and the steps you need are there.

This is worth saying plainly because it is the most common snag in the builder: when a step you expect is missing, it is almost always because the trigger's scope does not reach it. Change the trigger, and the step appears.

Guard the trigger

A trigger with no condition fires on every matching event. Create a single test contact to see what happens, and it fires on that one too. So guard it. Add a condition, on the record's source or a tag, so the automation runs on exactly the records you mean and no others.

Conditions can be grouped with "and" and "or" for finer aim. A guarded trigger is the whole difference between an automation you trust to run unattended and one you feel you have to watch.

TriggerStart
The event that starts the workflow. Its scope decides which steps you can use.Start
ConditionGuard
The guard that decides whether to run on this record. Without it, the trigger fires on everything.Guard
ActionDo
A step the workflow takes: send, create, log, wait. They run top to bottom.Do

Log activities, not notes

When your automation records that something happened, make it an activity, not a note dropped into a field. An activity is anchored in time, and, more importantly, other automations can trigger on it. A value hidden in a message field is invisible to the rest of your system; an activity is something the platform can act on later. Building on activities is what lets one automation hand off cleanly to the next.

Model what the business tracks: custom objects

Contacts and companies cover most of the CRM, but not everything a business runs on. A veterinary clinic tracks a pet: the pet has its own name, its vaccination record, its chip number. That is a custom object, a record type you define with its own fields, separate from any field on the contact. Custom objects power automations and smart lists the same way built-in records do, and you can bulk-import them from a spreadsheet to get started.

Shape a value mid-flow: data expressions

Sometimes the value you receive is not quite the value you need to pass on: a first and last name to combine, one field to pull out of a larger payload, a number to reformat. A data expression reshapes it in the middle of the workflow. They are compact by design, with a length limit, and they fail softly: a missing field returns an empty result rather than crashing the run, so a small mistake never takes the whole automation down. When you need the full syntax, the data expressions guide has it.

Try it now

Take one automation you run, or want to. Write the single condition that would keep it from firing on the wrong record: a source, a tag, a field value. That one line is what turns a noisy automation into a reliable one.

Knowledge Check

Three quick questions on trigger scope, guarding a trigger, and modeling data.