Change a rule or flow without breaking it
Validation rules, flows, and approval steps are the changes most likely to break something you did not touch, because automation reaches across objects. They travel the same route as everything else: described, diffed, run in a sandbox, reversible.
The change is one rule. The effect is three objects away.
The request looks contained. "Change the validation so Amount is only required once the Opportunity reaches Proposal, not before." One rule, one field, a minute of work.
Edit it in production and watch. You make the change live and keep an eye on Slack. What you cannot see from the rule itself is the flow on a related object that assumed Amount was always set, or the integration that writes Opportunities overnight and now trips the new condition at 2am, when nobody is watching. The rule was simple; its reach was not.
Test it in your head. You trace the logic mentally, decide it is fine, and ship. This works until the one path you did not think to trace is the one a real record takes. Automation fails in the cases you did not imagine, which is exactly the set a mental test cannot cover.
Automation is testable if you run it somewhere real first
Automation is the change class where a sandbox earns its keep. A field change you can mostly reason about; an automation change you need to watch execute. Deploying to a real org that is not production lets you save the record that should now pass, and the one that should now fail, and see what the automation actually does rather than what you meant it to do.
The exact change matters more here than anywhere else. A validation rule that is right in spirit and wrong in a single condition still saves cleanly and still breaks records the next morning. Reading the precise diff, not a summary of it, is how you catch the off-by-one before it catches you.
What a safe automation change looks like
Described in plain English
"Only require Amount once Stage is Proposal or later." You state the behavior you want; it becomes the specific edit to the rule or flow.
Returned as an exact diff
The precise logic added, removed, or altered, in your repository, so you review the condition itself rather than a description of it.
Run in a sandbox
It deploys to a real org first, where you try the records that should pass and the ones that should fail, and confirm the automation behaves before any real save meets it.
Held behind approval, and reversible
Nothing reaches production without your explicit go-ahead, and the previous version of the rule or flow is in your repository, so a 2am misfire is a redeploy of the prior state rather than a rushed re-edit.
The two things automation gets wrong — an unhandled path and a subtly incorrect condition — each have a step aimed at them. The sandbox catches behavior; the diff catches intent.
Who this is for
Anyone who has changed one rule and broken something two objects away.
Alone, the sandbox is the test environment you would not otherwise stand up for a one-line change, and the history is the undo you would otherwise not have. On a small team, the diff is where a second person reads the condition before it ships, in one place instead of a Slack description. With an engineering team nearby, your automation change arrives as a pull request in the same repository as their code, so the logic that runs on save is reviewed the way the rest of the org’s logic is.
Run your next rule change in a sandbox first
Take a validation rule you have been meaning to adjust, describe the change, and try it against the records you know should pass and fail.
Start free in 2 minutes