Triggers, Jobs & Pages

Triggers: run on save

A trigger function runs automatically whenever records on an object are inserted, updated or deleted — no button, no schedule, no person clicking anything. The save itself is the trigger.

This is how you keep data honest without anyone thinking about it: stamp a field on insert, roll a total up to a parent on update, archive children on delete. Wire it once and it just happens, every time, forever.

The one fact that shapes every trigger

Here's the rule that catches everyone the first time. When a trigger fires, its start node does not hand you the one record that changed — it hands you the list of all affected records. Save one Lead and you get a list of one; a bulk update of fifty Leads fires the trigger once with a list of fifty.

So a trigger function always loops over that list — exactly the loop you met in Modules 04 and 05. You read the list, you iterate, and you write back after the loop:

Notice the shape: the loop walks each record and an assignment sets values on it, but the update sits after the loop and writes the whole list at once. That's Module 05's bulkify rule, and it is not optional in a trigger — a trigger that ran on fifty records and put a write inside the loop would do fifty separate database calls.

// the start node hands you a LIST — always
[{ name: 'records', datatype: 'object',
   objectApi: '<object-api>', isList: true }]

Before vs After

Triggers fire at one of two moments: before the record is saved, or after. They look almost identical on the board, but they behave very differently — and choosing the wrong one is the single most common trigger mistake.

The difference comes down to two questions: does an assignment to the triggering record persist on its own, and what does a notification do? Here is the whole story, side by side.

One thing is the same in both: writing to other objects is always allowed. Updating a parent record, creating a child, deleting a related row — fine in Before, fine in After. The Before-vs-After rules above are specifically about the record that triggered the function.

The recursion trap in After triggers

If an After trigger on an object updates that same object, that update can fire the trigger again, whose update fires it again… a loop that never settles. The fix is a condition: before you write, check whether the work is already done, and skip the update if it is.

Wiring the trigger

Building the function is only half the job. A trigger function does nothing until it is connected to record events through workflow wiring — and the wiring has a few exact rules that, if you miss them, fail silently.

The wiring tells the platform three things: which function to run, what to pass it, and which events to listen for. It looks like this:

{
  function: 'flag_overdue__fx',        // note the __fx suffix
  functionParams: [
    { name: 'records',          // MUST match the function's input param
      value: 'list-new',
      type: 'list',            // MUST be 'list', never 'object'
      useContext: true }
  ],
  triggers: [
    { label: 'On Create', name: 'onAfterInsert', enabled: true },
    { label: 'On Update', name: 'onAfterUpdate', enabled: true }
  ]
}

Read it top to bottom. The function is the one you built (with its __fx suffix). functionParams is the bridge that hands the event's records into your input parameter. And triggers is the list of events to fire on — each with a human label, an event name, and an enabled flag so you can turn individual events on and off.

Scheduled jobs

Some work isn't triggered by a save at all — it just needs to happen on a schedule. Nightly cleanups, hourly reminders, end-of-day rollups: that's a scheduled job, a function that runs on a cron timer with nobody watching.

Because no user and no record kicked it off, the scheduled_job context is the most self-contained of all. It takes no inputs and returns no outputs — there's nowhere for data to come from or go to. And critically, it may not contain page nodes: there is no user session, no screen, nobody to answer a prompt.

It's almost always a batch

A scheduled job's whole job is usually "find the records that need attention and act on all of them." That is exactly Module 05's batch shape — query the set up front, loop to decide, write back in bulk after the loop:

One query before the loop, one bulk update after it — never a write inside. A nightly job can touch thousands of records, so bulkify isn't a nicety here; it's the difference between finishing in seconds and timing out.

Interactive functions (pages)

Sometimes a button action needs to ask the user something partway through — "which warehouse?", "are you sure?", "enter a reason." When that happens, the function itself pauses and shows a screen by adding a page node.

The instinct of someone coming from other tools is to build a separate custom page that collects the input and then calls a function. On this platform, don't. The page lives inside the function as a node, and the flow continues right after the user answers:

The page node collects input, a condition branches on what they chose, and the rest of the flow finishes the job — all in one function, one continuous flow.

The whole trail

That's it — you've reached the end of the trail. Look back at how far you've come: you can now build all four ways a function runs, the right way, with the rules that keep them fast and correct.

The journey, module by module

The four ways you can now make a function run

• A button — context layout_button. A user clicks; the function acts on a record (Module 02, and the Zero Rule throughout).
• An automation — context trigger. A save fires it with the list of affected records; you loop and write after (Unit 1).
• A scheduled job — context scheduled_job. A cron timer runs a no-input batch; query before, bulk write after (Unit 4).
• An interactive flow — a function with a page node that asks the user mid-flow, then carries on (Unit 5).

Across all four, the same instincts carry you: declare your intent and call context first; read before you write; branch with conditions; loop over lists; and keep every query/create/update/delete out of your loops. That toolkit builds most of a platform.

Keep the Function Reference open in another tab as your companion — every standard function and formula, searchable, for when you need the exact name or signature. And the whole trail is always one click away from all modules if you want to revisit a unit.

Earn the Automator stamp

Five questions to complete the trail.