Salesforce automation works best when each rule has a clear purpose. Oblytech maps your current sales process first, then builds record-triggered flows, approvals and integrations that remove repeated manual steps without creating hidden logic that is hard to maintain.
Many Salesforce automation problems start with a tool choice made in a hurry. A sales manager asks for a stage change to trigger an email, and someone builds it as a trigger because a trigger was the fastest thing to write. A year later the org holds three overlapping automations on the same object, none documented, and nobody can say which one runs first when an opportunity changes owner and stage in the same save. The decision that matters is less about which feature is fashionable and more about which mechanism the team can read, test, change and hand over to someone else.
In practice the choice is usually between declarative tools that administrators can maintain, such as record-triggered flows, scheduled flows, approval processes and screen flows, and code such as Apex triggers and classes, which is reserved for logic the declarative tools cannot express cleanly. Declarative automation is usually a sensible default. Code earns its place when the logic runs at high volume, needs complex data manipulation, calls external services under tight control, or depends on behavior the declarative tools do not expose.
| Requirement | Usually fits | Watch for |
|---|---|---|
| Update a field or create a related record when a record changes | Record-triggered flow | Recursion when the same object is updated again within one transaction |
| Act on records that meet a condition at a set time, such as a renewal reminder | Scheduled flow | Batch volume and the time zone the schedule runs in |
| Route a discount, quote or contract for sign-off | Approval process | Who can recall or reassign an approval, and what the record can do while it waits |
| Guide a user through a multi-step data entry task | Screen flow | Whether the same logic must also run when records arrive by import or integration |
| Complex calculation across large record sets or external callouts | Apex | Test coverage, platform execution limits and a named developer who will maintain the code |
When two automations act on the same field, the outcome depends on execution order, and that order is not something a business user should have to memorize. A workable rule is one primary automation per object and per trigger moment, with every other requirement either folded into it or deliberately separated into a scheduled or asynchronous path. The design should list every automation that touches each object, its trigger, the fields it writes and the owner who can change it. Without that register, the first change request after go-live becomes an archaeology exercise.
Four failure patterns recur. The first is recursion, where an update fires an automation that updates the same record again and the second pass writes values nobody intended. The second is bulk behavior: an automation tested with one record works, then fails when a data load or a mass update touches thousands of records and hits platform limits. The third is silent failure, where a flow errors on an edge case, nobody is notified, and users only discover the gap when a report looks wrong weeks later. The fourth is ownership drift, where the person who built the automation leaves and the business keeps relying on logic nobody can explain.
Each of these is preventable with choices made early. Entry conditions should be explicit so an automation does nothing when it is not needed. Fault paths should send a notification to a named support queue rather than failing quietly. Bulk tests should use realistic data volumes in a sandbox, and the change record should state who approved each automation and the business reason it exists.
These answers feed directly into the stage and approval design covered on the sales workflow design page, because stage definitions and approvals are the inputs an automation depends on. If the answers are unclear, building the automation first only moves the disagreement into production, where it is more expensive to resolve.
Automation needs the same release discipline as code, even when it is assembled with clicks rather than typed. Test the happy path first, then the cases where a required field is blank, the user lacks access to a related record, the record is locked by a pending approval, the record is changed by an integration user, and the record is changed by a bulk operation. Keep the test script in a form that a tester can rerun after each release, and record the version that is live so that a rollback is possible.
Deploy from a controlled path rather than editing production directly. A flow that has been deactivated but not removed still appears in the org and still confuses the next administrator, so retire unused automation deliberately and note the retirement in the register. Schedule a short review after the first month of live use, because the first real volume of records often exposes a case the test script missed.
Ownership is the part of an automation project that is most often left vague. The internal administrator needs to be able to read every declarative automation, understand its entry conditions, and make a safe change. Any Apex code needs a developer who can maintain it, and that dependency should be agreed before the build rather than discovered during the first incident. The business owner for each process should be named, because the person who understands the outcome is the person who can judge whether a change still serves it.
| Artifact | Purpose after go-live | Who keeps it current |
|---|---|---|
| Automation register | Shows every automation, its trigger, fields written and owner | Internal administrator |
| Test script | Reruns the happy and failure paths after each change | Administrator with a tester |
| Fault notification route | Sends failures to a monitored queue | Support owner |
| Change log | Records approval, business reason and release version | Platform owner |
A strong proposal names the automations it will build, the object each one touches, the mechanism chosen and the reason for that choice. It states what will be tested and who signs off each release. It says what is excluded, such as legacy automations that will be left alone, and it names the support owner after go-live. A weaker proposal lists outcomes such as faster approvals or fewer errors without describing the logic that delivers them. Ask to see the automation register that will be produced, because that document is what the internal team will use long after the project closes.
No. Automate steps that are repetitive, rule-based and well understood. Leave judgment-heavy steps to people, but give them the information and reminders that help them decide consistently.
Often yes, if the automations are declarative, documented and kept to a sensible number. Code needs a developer who can maintain it, so that dependency should be agreed before the build starts.
They should be inventoried before anything changes. Some will be retired, some folded into the new design and some left as they are. Running old and new logic side by side during a transition is a common source of duplicate records and should be planned for explicitly.
Ask the business owner to name the outcome it protects. If nobody can, review it with the support owner before deciding whether to keep it.
Start by listing the manual steps your team repeats most often and the person who depends on each outcome. That list is a practical input for any automation discussion. The Salesforce implementation page describes the wider implementation work, and the support and maintenance page describes ongoing Salesforce support.
When a Salesforce record is saved, before-save flows and Apex before triggers run first, then validation rules, then the record is written to the database, then after-save flows and Apex after triggers act, and the whole transaction commits last. That sequence decides where a field default, a check and a related-record update belong.
Placement follows from the sequence. A before-save flow can set a field on the record being saved without spending an extra update, which makes it the right home for defaults and calculated values. A validation rule runs after that, so it checks the value the flow just set, not the value the user typed. Anything that must create or change a different record belongs after the save, because the new work needs the saved record’s identifier.
| Stage | Typical content | Design consequence |
|---|---|---|
| Before the save | Before-save flows, Apex before triggers | Set or correct fields on this record only |
| Validation | Validation rules | Judges the value after before-save automation has changed it |
| After the save | After-save flows, Apex after triggers, older workflow-style rules | Create or update related records, notify people, start follow-up work |
| Commit | Final checks and the database commit | An error here undoes the whole transaction |
The real sequence has finer steps, such as assignment and escalation rules, so treat the table as a working model. Two habits prevent most surprises: keep one automation per object for each stage, named after that stage, and test with a bulk data load, because one record and thousands follow the same order but meet different limits.
The stage fields that these automations read are designed on the sales workflow design page. When an automation must call another system, the integration architecture work decides whether that call happens inside the save or afterwards. After go-live, support and maintenance keeps the register of what runs at each stage current.
A before-save flow changes fields on the record that triggered it, before it is written, and is faster because it needs no extra update. An after-save flow runs once the record exists, so it can create or update other records and start actions that need the record’s identifier.
A second run usually means something updated the same record again within the transaction, for example an after-save flow or trigger writing a field back. Entry conditions that compare the old and new value stop the repeat, and one automation per stage keeps the cause easy to trace.
After a before-save flow and before the record is written. A validation rule therefore sees the values the flow set. If a rule blocks a save unexpectedly, check whether a flow changed the field that the rule tests.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.