Record Update
Record Update in Salesforce is the operation of changing the field values on an existing record.
Definition
Record Update in Salesforce is the operation of changing the field values on an existing record. The operation is the same on the database, but the platform exposes many ways to invoke it: the user editing a field on a record page, a Flow's Update Records element, a Process Builder action, an Apex DML statement, a REST API PATCH call, the Data Loader, or a mass-edit on a list view.
Each invocation path produces the same database effect (the record's fields are written, the LastModifiedDate is bumped, the order-of-execution runs) but differs in the constraints and behaviour around the write. Flow updates run inside a flow interview's governor limits. Apex updates run inside the calling transaction's limits. UI updates run as the user's session. REST API updates run under the connected app's bandwidth. The right path depends on who is triggering the update, where the trigger comes from, and what side effects the update needs to produce.
How a Salesforce record update behaves across every invocation path
What happens when Salesforce updates a record
An update to any record triggers the Salesforce order of execution. The platform runs system validation, before triggers, custom validation rules, the database write (without commit), after triggers, assignment rules, auto-response rules, workflow rules, processes, flows that fire after-save, and finally commits the transaction. Every update path runs this sequence, so a Flow update and an Apex update produce the same downstream side effects. The differences between the paths are how the update is initiated and what context it runs in, not what the platform does once the update reaches the database engine.
Declarative update paths: Flow, Process Builder, Quick Action, Workflow Field Update
Salesforce's declarative tools all offer record update primitives. Flow has the Update Records element, which selects records by criteria and writes field values to them. Process Builder (legacy) has an Update Records action that fires from a record-triggered process. Quick Actions can update fields on the host record via a layout-driven form. Workflow Field Updates (legacy) write specific fields when a workflow rule fires. The Flow Update Records element is now the canonical admin-level path because Salesforce has retired Process Builder and is phasing out workflow rules in upcoming releases.
Programmatic update paths: Apex DML, REST PATCH, SOAP update
Code paths produce updates through three main mechanisms. Apex DML uses the update keyword on an sObject or List of sObjects. The REST API offers PATCH on /services/data/vXX.X/sobjects/Account/001xxx with a JSON body of the new field values. The SOAP API offers an update call with the same semantics. All three paths share the platform's governor limits, the order of execution, and the row-locking model. The differences are in how the caller authenticates and what bulk batching is available; the bulk API is the right path for very large updates that would exceed Apex DML row limits.
Bulkification and the cost of single-record updates
Single-record updates inside a loop are the most common Apex anti-pattern. A loop that updates one record per iteration consumes one DML statement per iteration and hits the 150-DML limit after 150 records. The bulkified pattern collects records into a list inside the loop and runs one update on the list outside the loop. The same principle applies to declarative tools: a Flow that updates one record per loop iteration burns the same DML allowance. The For Each loop in Flow has the same limit semantics as an Apex for-loop with DML inside.
Update triggers, recursion, and the importance of guards
Every update fires the relevant triggers on the object. If those triggers themselves issue updates, the platform handles them in the same transaction and can produce recursion if the update modifies the same record that fired the trigger. The standard pattern is to use a static recursion guard in the trigger handler: a Set of Ids that records which records have already been processed in the transaction, and a check at the top of the handler to skip records already in the set. Without a guard, an apparently simple update can cascade through workflows and triggers until Apex CPU time runs out.
Field history tracking and audit
Records with Field History Tracking enabled on specific fields create a history row each time those fields change in an update. The history captures the old value, the new value, the user who made the change, and the timestamp. Field history is the canonical audit trail for who-changed-what-when investigations. Tracking is enabled per field, with a maximum of 20 tracked fields per object. History rows are retained for 18 months by default; longer retention requires Field Audit Trail, a paid add-on that extends retention up to 10 years for compliance-sensitive industries.
Order of execution interactions and surprises
An update can be modified by validation rules, before triggers, formula fields, and processes that fire after-save. The classic surprise is a validation rule that rejects an update the user expected to succeed because a downstream field's value moved out of the validation rule's allowed range. Another is a before trigger that silently overwrites a field the user set, which produces a record with the old user-set value visible in the UI until the page refreshes. Understanding the order of execution is the only reliable way to debug surprising update behaviour; the Apex Debug Log shows the actual sequence of events when a record updates.
Update a Salesforce record from each available path
A Salesforce record can be updated through Flow, Apex, REST API, or the UI. The steps below cover the most common paths an admin or developer chooses between.
- Update a single record in the UI
Open the record page, click the field's pencil icon to edit, change the value, and click Save. The UI runs the user's profile permissions and any field-level security; validation rules and triggers fire as normal.
- Update records in a Flow
Add an Update Records element to the flow. Pick the object, supply a record collection or filter criteria, and set the field values. The Flow's transaction handles the DML; bulk-loaded flows pass a record collection in one DML call.
- Update records in Apex with DML
Write Apex code that calls update on an sObject or a List of sObjects. Wrap the call in a try-catch if you want to handle DmlException explicitly. Bulkify by building the list inside the calling logic and calling update on the list outside any loops.
- Update a record via REST API
Send a PATCH request to the sObject endpoint with a JSON body containing the fields to update. The API runs under the connected app's user context and obeys the same validation and triggers as the UI.
- Mass update via Data Loader or Inline Edit
For bulk admin updates, use Data Loader with a CSV of record Ids and new values. For ad-hoc list view updates, enable Inline Edit on the list view and edit cells directly. Both paths run the full order of execution per record.
The canonical declarative update path. Picks records by criteria or collection and writes field values.
The canonical programmatic update path. Runs on an sObject or List with full governor-limit cost.
The canonical external integration update path. Authenticates via OAuth and produces the same database effect as Apex update.
- Single-record updates inside a loop hit the 150-DML governor limit after 150 records. Bulkify by collecting records into a list and updating the list once outside the loop. The same rule applies to Flow For Each loops.
- Validation rules fire on every update, not just on user-initiated updates. A Flow or Apex update can be blocked by a validation rule the user did not realise was active; the failure surfaces as a runtime exception.
- Field History Tracking only captures changes on the fields you explicitly enabled, up to 20 per object. The rest of the field changes are invisible to history reporting; broader audit needs Field Audit Trail or platform events streamed to an external store.
Trust & references
Cross-checked against the following references.
- Flow Element: Update RecordsSalesforce Help
- Apex DML StatementsSalesforce Developers
- REST API: Update a RecordSalesforce Developers
- Triggers and Order of ExecutionSalesforce Developers
Straight from the source - Salesforce's reference material on Record Update.
- Update Records (Flow Element)Salesforce Help
- Field History TrackingSalesforce Help
Hands-on resources to go deeper on Record Update.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Record Update?
Q2. Which tool is preferred for new record updates?
Q3. What can record updates modify?
Discussion
Loading discussion…