Built-in automations

A built-in automation is the work a feature does on its own, shown as connected steps: what starts the work, which steps follow and where it waits or makes a choice. Where editing is allowed, changing those steps changes how the feature behaves.

It isn't a report of background jobs, and it isn't an extra automation you have to turn on alongside the feature. You'll find built-in automations in Automations, under the Built-in filter, next to Yours for the automations you make yourself.

Start with the name and scope

The name tells you what the automation powers. Data's built-in automation is named Data. A type that runs a process of its own, such as a Store type, has its own built-in automation, named for that type.

One automation can contain several stages. Data has Start assigned agents and Archive Done cards. Those are two jobs within Data, not two separate features.

Tables don't each get their own built-in automation. Several Data tables can use the same archive process while each table keeps its own waiting period. That matters when you make a change: editing the shared process can affect every table it serves, not just the card you were looking at.

Read the automation's description of what it powers and who a published change affects before editing it.

Read a process from its starting point

A trigger is what starts a stage, such as a record changing or a scheduled time arriving. The stage then follows its connected steps. Each time the process runs is a run.

The main pieces answer different questions:

A choice should express a real decision, such as whether a report is complete. A wait should show a meaningful pause. AI work and actions such as sending a message should stay visible rather than disappearing into an unexplained step.

These are ways to understand the process, not a promise that every feature offers every piece in its editor.

Steps pass information to one another

A step does one defined job, with defined inputs and outputs. The editor's connections show where that information comes from and where it goes next. Help lists every automation step.

For example, Data's archive action receives a particular card, the time it entered a Done state and the time it becomes due. It doesn't receive a sentence saying “archive something.” The action has enough information to decide whether that same card should still be archived.

The kinds of information must match. A step expecting a record can't use an unrelated file or a block of text in its place. These defined inputs let different processes use the same step without changing what it means.

Routine safeguards belong inside the action

You shouldn't have to add a permission check before every action or remember a separate step that prevents duplicate work. The feature performing the action enforces its own rules.

Data's archive action checks whether the card still qualifies when the wait ends. If the card has moved on or the archive rule has changed, it leaves the card alone. That's an expected result, not necessarily a failed run.

The same applies to an action with an outside effect. Putting an email send in an automation doesn't grant access to an email account or get around sending restrictions. A connected step must still be allowed to do its work at the time it acts.

This keeps the visible process about the business decision while keeping the checks every caller needs.

Visible doesn't mean running

You can see a feature's built-in automation before you finish setting the feature up. You can read what it would do without starting it.

A stage may need a setting, connection or start action before it runs. In Data, the archive rule belongs to the table, and starting assigned agents is controlled by the assignee column. There's no separate switch for the built-in automation that replaces those settings.

Quote requests is another example. Its staff notification starts paused, and it stays that way until you choose who gets new requests and an approved sender is set up.

A paused or unstarted stage is different from a run waiting for its due date. The first hasn't started that work; the second has reached a deliberate pause in an existing process.

Understand what you can change

What you can edit depends on the feature and your permissions. Some built-in automations are there to read but not to change, including My Business's and the shared Site builder's. Seeing their steps doesn't make them your private editable copies.

For editable ones, changing a setting and changing the steps have different scopes. Changing one table's archive period affects that table. Changing Data's archive stage changes the process used by the tables it serves.

A permitted, published change applies to future runs. Runs already accepted keep the version and inputs they started with, while their actions still check current permission and state. Publishing a new version therefore neither rewrites running work nor lets old work ignore a permission that's been taken away.

When GrowLocal updates the steps a feature comes with, your changes are kept rather than silently replaced.

Built-in isn't every automation

An email campaign sequence you write yourself is your campaign's own program. It stays under Yours, rather than becoming another copy of Email's built-in automation.

Displaying a value that already lives elsewhere, such as your business address on your website, isn't a process to automate either. A built-in automation is for work someone would want to understand or rearrange, not a way to give every visible item a set of steps.

Follow a concrete example

See how Data starts work and archives completed cards. The example connects the table's settings to Data's built-in automation and explains what happens when the record changes while work is waiting.