Skip to main content

Hand off to the automation

AdvancedLabAutomationsCRMIntegrationsWire your AI Workforce to act · Step 4 of 8
Estimated time · about 12 minutes|Required · A test account with the WeatherCheck build running

Outcomes

Match a trigger's scope to the record you are acting on
Guard a trigger so it fires on exactly the records you mean
Build the follow-up that picks up where the conversation ends
Log engagement as an activity the next automation can act on

The trigger decides what you can do

An AI Employee stops when the conversation stops. Everything that should happen afterward, reliably and without anyone remembering, belongs to an automation, and the trigger you choose sets the rules for everything that follows it.

Trigger scope is the mechanism. A trigger scoped to a contact gives you contact steps; one scoped to a company gives you company steps; a trigger with no scope reaches less than either. When a step you expect is not in the list, the scope is the reason, and changing the trigger brings it back.

Guard the trigger

A trigger with no condition fires on every matching event, including the test record you made two minutes ago. A condition is what aims it: the record's source, a tag, a field value. Conditions group with and and or when one line is not enough.

Three pieces make every automation, and each one answers a different question. Flip each one:

A guarded trigger with a scope that reaches its steps is the difference between an automation you leave running and one you feel you have to watch.

Build the follow-up

You are here: Partner Center. The automation lives in your workspace, and it acts on the test account's records.

The build so far ends when the visitor closes the chat. The follow-up is what makes a booked job feel handled: the client hears something, and a person has a task waiting.

Labbuild Rain delay follow-up

Go to AutomationsMy automations, then Create automation.

A booking made in conversation now leaves a task behind it, and a contact from any other source does not.

Log activities, not notes

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

That is the same handoff you just built, one level up: the employee announces, the automation acts, and what the automation logs is what the next one listens for.

What carries the rest

Two pieces cover the jobs a contact and a company cannot.

Custom objects model what a business actually tracks. A veterinary clinic tracks a pet, with its own name, vaccination record, and chip number: a record type you define with its own fields, separate from anything on the contact. They power automations and smart lists the same way built-in records do, and they bulk-import from a spreadsheet.

Data expressions reshape a value mid-flow, when what arrives is not quite what the next step needs: a first and last name to combine, one field to pull out of a larger payload, a number to reformat. They are compact by design and they fail softly, so a missing field returns an empty result rather than stopping the run. The data expressions guide has the full syntax.

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 one you leave running.

Knowledge Check

Three quick questions on trigger scope, guarding a trigger, and what other automations can act on.