What you’ll find in this blog
- Why some parts of Salesforce become things nobody wants to touch
- How to investigate unfamiliar automation and its dependencies
- Who to involve when deciding whether a process should change
- What to test and prepare before putting a change live
With Halloween approaching, what’s the one thing in your Salesforce org you’d rather nobody touched?
Perhaps it’s a Flow built by someone who left years ago. A validation rule that blocks users but apparently prevents something worse. Or an integration that occasionally needs restarting, following instructions passed between colleagues.
Ask why it works that way and the answer is: “There was a reason. I just can’t remember what it was.”
Being cautious makes sense. Salesforce supports real work, and an apparently small change can affect people beyond the team requesting it.
But leaving something alone indefinitely has consequences too. Requests get postponed, users find workarounds and each new change has to navigate another area nobody fully understands.
The useful question is what you need to find out before you can make a decision.
What, exactly, are people worried will happen?
“Something might break” is a reasonable concern, but a difficult one to investigate.
Try to make it more specific. Could changing a required field leave delivery without information? Could adjusting an opportunity stage affect forecasting? Could a new picklist value cause a connected finance system to reject a record?
Each concern gives you something to check.
It also helps distinguish between a known dependency and an assumption. Someone may remember an incident involving a process that has since changed. Equally, a rule that looks unnecessary may still protect an important exception.
Write down the concern and who raised it. You can then investigate the likely impact rather than treating the whole component as untouchable.
Follow a real example through the process
Opening a complex Flow and trying to understand every branch at once can be a slow starting point.
Choose a recent record that passed through the process. Establish what triggered the activity, which information it used and what happened afterwards. Check whether other automation or connected systems use the same fields or resulting records.
Then speak to the people who rely on the output. Did they receive what they expected? Did they have to correct anything? Are there situations where the process behaves differently?
A technical review and a conversation with users answer different parts of the question. You need both to understand whether the current behaviour is intentional and whether it still serves the business.
Keep a record of what you find, including anything you haven’t yet confirmed. That uncertainty needs to be visible when someone decides what happens next.
Find the person who can confirm the business rule
The person who maintains Salesforce may be able to explain how a process works without having the authority to decide whether it should work differently.
Take a validation rule that requires a delivery date before an opportunity can progress. Sales wants the requirement removed because customers cannot always confirm a date that early. Delivery uses it to plan capacity.
The Admin can explain the technical options. Sales and delivery need to agree when a reliable date should become mandatory and how exceptions will be handled.
Until that decision is made, changing the rule risks moving the problem from one team to another.
Identify the person who can approve the intended business outcome. For a process crossing teams, they may need input from several colleagues. Make that responsibility explicit in the change request.
Decide whether it needs changing at all
An unfamiliar component isn’t necessarily a bad one. Age alone is no reason to replace it.
Your investigation might establish that the existing process is still appropriate. In that case, documenting its purpose, dependencies and owner is useful progress. The next person will have evidence to work from.
You might find that a small adjustment would resolve the problem. Or that the original requirement no longer exists and the component can be considered for retirement.
Sometimes the investigation reveals a wider process disagreement that Salesforce cannot settle. That needs resolving before anyone starts building.
The decision should reflect what you’ve learned. Avoid turning every unknown into a redesign project.
Test the concern that made people hesitate
Once a change is agreed, build the testing around its likely consequences.
If delivery is worried about incomplete information, test what happens when that information is missing. If an integration uses the field, check how the receiving system handles the changed value. If the process has exceptions, include them.
Use an appropriate sandbox to investigate and test before changing the live org. Choose representative examples and involve the people who use the results, alongside those checking the technical behaviour.
Agree what a successful result looks like before testing begins. “The Flow ran” may be one condition. The business may also need to confirm that the right record was created, the information arrived in time and someone could carry out the next step.
Where testing has limits, record them. A sandbox may not reproduce every connection or condition in production, so those gaps need to inform the release plan.
Prepare for what happens after activation
Before putting the change live, agree who will check its behaviour and when.
Some effects should be visible immediately. Others may only appear during a scheduled integration, a renewal cycle or month-end reporting. The person responsible for checking needs to know which result to expect.
Also agree what would trigger a pause or correction, who can make that decision and how affected users will be informed.
Think through recovery before you need it. Reverting configuration may be possible, but it won’t necessarily reverse records already created, information sent to another system or messages already delivered. The response needs to account for those effects.
That preparation gives the team a clearer basis for proceeding than “we’ll keep an eye on it”.
Leave the next person with a better explanation
When the work is complete, capture the reason for the decision alongside the technical change.
What did the process do before? Why was it changed or retained? Which dependencies were checked? Who approved the outcome? What should someone monitor afterwards?
Keep the explanation proportionate and somewhere colleagues can find it.
The aim is to reduce the number of decisions that depend on someone remembering an old conversation. Over time, that makes Salesforce easier to maintain and gives the team more confidence when the next request arrives.
If there’s a part of your org everyone avoids, start with one specific concern and one real example. Establish what happens, who relies on it and what evidence you need before making a change.
For help investigating existing configuration and managing ongoing improvements, explore Xenogenix Salesforce Managed Services.
Samantha Mathie is a Senior Digital Marketing Executive at Xenogenix and has been part of the business for four years. Before joining Xenogenix, she spent more than eight years working independently as a marketing consultant.
With a background in IT, telecommunications and video conferencing, Samantha specialises in B2B technology marketing, digital campaigns, content and connected customer journeys. She is particularly skilled at turning complex subjects into clear, engaging communications.
As an author for Xenogenix, Samantha shares practical guidance on digital marketing, campaign planning, content and communicating technology effectively.