In short
- If the value can be calculated and no one edits it, use a formula field.
- If the choices depend on another field, use a dependent picklist.
- If the value should be stored and set on save, use a before-save record-triggered flow.
- If a related record must change, use an after-save flow, and test it against validation rules.
The problem: fields that should update themselves
Reps fill in the same fields again and again. A value they could look up from another field. An owner that follows a rule. A source that is already in the URL. Each one is a chance for a typo, and a field left blank.
Salesforce can fill these in. The trick is choosing the right tool, so the field updates when it should and nothing else breaks.
Pick the right way to auto-update a Salesforce field
Formula field
Calculates the value each time the record is read. Good for values no one should edit, like a full name or a days-since date. It cannot be overwritten by a rep.
Dependent picklist
Limits one picklist by another. Pick a facility, and only that facility’s levels of care show. The rep still chooses.
Before-save flow
Sets fields on the same record as it saves. Fast, and no second save. Use it to set the level of care from the facility, or the website from the landing page URL.
After-save flow
Changes other records: the parent account, the related contacts, a new task. Use it when the change must reach beyond the record that was saved.
Apex trigger
For logic flows cannot handle well, like large data volumes or complex matching. Salesforce can be changed in any way, and code is the right tool for some jobs.
Example: set one field from another with a before-save flow
Start the flow
Create a record-triggered flow on the object. Run it when a record is created or updated, and choose "Fast Field Updates" (before save).
Set the entry condition
Only run when the source field changed. In Flow Builder, use the condition that the field "Is Changed" equals true, so the flow does not run on every save.
Decide the value
Add a Decision element, or a lookup to a mapping (custom metadata works well), to turn the facility into a level of care.
Assign it
Use an Assignment element to set the target field on the triggering record. No Update Records element is needed in a before-save flow.
Test it
Test create and update, by a rep and by an integration user, so records from forms and calls get the same value.
Talk through your project
A free call about your integration, your CRM or whatever you are stuck on. Honest advice, even if you never hire us. No obligation.
More field updates we build with flows
- Set the website field from the first landing page URL, for first click attribution.
- Reassign the lead owner when a rule says the lead belongs to another team.
- Set an "SMS responded" field when an inbound or outbound text is logged.
- Copy the account type and owner email down to the related contacts.
- Copy the phone into an "original phone number" field on create, so the first number is kept.
Show the update without a page refresh
A flow updates the record, but a custom component on the page may still show the old value. Lightning Web Components can listen for record changes and refresh. We build this into our widgets: change a phone field, and the Send SMS number list updates on the spot.
Things that break auto-updates
- Validation rules on the related record. An after-save flow fails if the parent cannot save.
- Required fields that are blank on old records.
- Two flows that set the same field. Pick one owner for each field.
- Running on every save. Use "Is Changed" entry conditions.
- No error alerts. Send flow errors to an admin, so a failure gets fixed.
Where to start
List the fields your reps fill in by hand that could be set from another value. Start with the one they get wrong. Book a free call and we will pick the right tool for each with you.
Want help with this?
Book a free call about your CRM, integrations or reporting, or map your systems first with our free tech stack diagram builder.