@* Salesforce Administrators * @Salesforce Best Practices Does anyone want to share their criteria and reasoning on what Salesforce changes can bypass the Production Release Managment cycle. These are items you put directly into Production without having to put it in Dev, QA sandboxes first. For us, we are pretty strict with this however we struggle to define that fine line of what needs to be in a Sandbox first. For instance, we can assign existing permission sets to users. You can even include items you "Fast Track" across all your sandboxes and into Production without a formal QA process, because they really don't warrant one. Thanks in advance as always i appreciate all responses and perspectives. Thank you!
I understand the desire to formalize this. However, it is tricky to give concrete guidelines that are safe. The reason is that there are so many factors to consider. The whole point of sandboxes is to provide a chance to test things to identify and correct regression before it appears in production.
Here are some principles.
1. don't break things that can cause harm
2. Use sandboxes and testing for things where the risk is moderate or high so we can be sure not to break things that can cause harm.
But that is so vague, right? So lets' drill down.
Some risk is present if you change something on which other things depend.
A high-risk change would be to change an object (e.g. fields, relationships). This is risky because this could be used by automation and reports, and testing all of them takes a lot of time and effort. So you hate to have it wrong in production while people discover the flaws. Better to test in a sandbox.
This is one reason that mature change management processes have techniques and tools for identifying dependencies. This is called impact analysis. "What else could break if we mess this up?"
In contrast, a dashboard depends on things, but rarely do things depend on a dashboard. So the risk of making a dashboard change in production is lower
Or a new report is clearly not yet used by any dashboard, so introducing a new report and possibly a new dashboard are low-risk events. But changing existing ones is higher. And the thing about reports is that usually, the person who requested the change checks it immediately for the desired result. So you can detect and correct it quickly. This is why breaking a single report, with a small audience, is a low-risk event. It's not a no-risk event. But if it's internal, and the user checks it in prod, then what harm is there?
So at this point you are thinking: "Great. I'll add reports and dashboards to our official list of things that are safe to change in production." But of course, you can already think of exceptions. That's why having a formal list of things to change in production may be a bad idea. The underlying principles must be understood so you can recognize when it is safe to make exceptions.
The questions to ask are like these: "What is the risk if we break something? How likely are we to catch it right away? What are the consequences if we get it wrong?"
Imagine you allow reports to be changed without testing. But now, imagine one of your reports is a financial report available to board members directly without management review and intervention in the distribution. Now you can see why I would hate to just have a simple list and say "Reports are safe to change in prod." even though they often are.
I know this is not the simple list you wanted. But it shows you some of the criteria and reasoning you asked about. And now you know why it may be hard to find someone who has a dependable, proven list of what is safe to change without testing in a sandbox.
By the way, our team agreed it would be safe to create custom objects that support report snapshots. But again, the risk is in the exceptions.
In my opinion, the best strategy is to develop automation to make it easy to test in a sandbox and deploy to production with the proper level of testing. It might be a little testing or a lot, depending on complexity and risk. But "no testing" is usually not a wise choice.
