Create, Update & Bulkify

Writing data: create, update, delete

So far you've read data with query and changed it in memory with assignment. To make those changes stick — to actually touch the database — you use one of three nodes.

• create — adds brand-new records to an object.
• update — saves changes to records that already exist.
• delete — removes records.

There is no single, generic “write” node — you always pick the specific one that matches what you mean to do. Each of the three shares the same three settings:

• object — the target object's API name (e.g. task__m, lead__m; yours may differ).
• recordVariable — the variable holding the record (or records) to write. It must be a variable you've already declared and filled.
• isList:true — flip this on when the variable holds a list and you're writing many records at once.

That's the whole shape of writing data: change a value, then commit it with the matching write node. The rest of this module is two ideas — how to use each node, and where not to put them (inside a loop).

Creating records

To create a record you do two things in order: build it in an object variable with assignments, then place a create node that writes it.

The create node never makes data out of thin air — it persists whatever you've assembled in the variable you point it at. So the pattern is always “fill the variable, then create it.”

Single record vs. a list

The only difference between writing one record and many is the shape of the variable and one checkbox:

• One record → an object variable. Leave isList off.
• Many records → an object-list variable, and set isList:true so the node writes the whole list in one go.

Example: create a follow-up Task

Say a button should drop a follow-up task onto a lead. Declare an object variable task (of object task__m), fill its fields with assignments, then create it:

1. Build the record in a variable

   Declare an object variable named task. With assignment nodes, set the fields you need — task.subject = "Follow up", task.dueDate, task.relatedTo = lead._id, and so on. (Field API names vary by org; you'll pick them from dropdowns.)

2. Add a create node

   Place a create node after your assignments. Set object to Task (task__m) and recordVariable to task. Since it's a single record, leave isList off.

Updating & deleting

Updating a record is a three-beat rhythm you already met in Module 02: load it, change it, save it. Deleting is simpler still — you just remove the record(s).

Updating: load → change → save

You can only update what you've loaded, so an update almost always follows a query:

1. Query to load the record(s)

   Run a query to pull the record into a variable — a single record into an object variable, or many into an object-list.

2. Assignment to change the values

   Use assignment nodes to set the fields you want to change — lead.status = "Stale". Nothing is persisted yet; you're editing in memory.

3. Update to save

   Add an update node. Set object to the target API and recordVariable to your variable. For a single record, leave isList off; for a list, set isList:true.

Deleting: remove the record(s)

A delete node takes the same object + recordVariable settings — point it at the record (or list) you want gone. As with the others, set isList:true when the variable is a list. You generally query first so you know which records you're removing.

The bulkify rule

This is the most important performance rule on the whole platform, so read it twice: never put a query, create, update or delete node inside a loop.

Why it matters

Each of those four nodes is an expensive database operation — a round trip to the data store. That's fine once. But put one inside a loop over N records and you've just asked for N separate database operations. Two things go wrong:

• It's slow. A thousand records becomes a thousand trips. What should take one operation now takes a thousand.
• It hits governor limits. The platform caps how many database operations a single function may perform. Loop-inside writes blow through that cap and the function is stopped.

The fix is to do one operation on the whole list instead of one operation per record.

The pattern

It's three moves, and the order is everything:

1. Query BEFORE the loop — pull all the records you'll need in one go.
2. Inside the loop, only cheap nodes — condition, assignment, and addToList to collect records into a list. No database nodes here.
3. Write AFTER the loop — a single create / update / delete on the collected list with isList:true.

The loop's only job is to decide and collect. The expensive write happens exactly once, outside it, on the list you built.

A bulk update, end to end

Let's build the real thing: take a list of leads, mark every open one as Stale, and do it the bulkified way — one query, one update, no matter how many leads there are.

1. Query the open leads — BEFORE any loop

   Start with a query on Lead (lead__m). Include the fields you'll touch — at least _id and status — and filter to the ones you care about (status Equal Open). Use take mode all and store the result in an object-list variable, say openLeads. One trip to the database, every record you need.

2. Loop over them — collect, don't write

   Add a loop over openLeads. Inside the loop, use an assignment to set the current lead's status — currentLead.status = "Stale" — then addToList the current lead onto a second object-list variable called toUpdate. No query, create, update or delete lives in here — only cheap, in-memory work.

3. Update once — AFTER the loop

   After the loop closes, add a single update node. Set object to Lead, recordVariable to toUpdate, and turn on isList:true. Every collected lead is saved in one operation.

Whether openLeads holds five records or five thousand, this function makes exactly one query and one update. That's the bulkify rule paying off.

Earn the Bulk Master stamp

Five questions to lock in Module 05.