Your production org is your live Salesforce instance, and keeping it running like a champ is critical to your business and customers. How do you keep your users happy? By following common best practices for governance and application lifecycle management. We could write several Trailhead modules about those topics (and we’re working on that). However, here in this blog post, we focus on some specific recommendations about how your choices in these areas can lead to successful deployments. Like any application, when you make changes to a production environment, you need to consider how your users will be affected.
Administering versus developing
Before we dive in, let’s clarify the difference between two types of tasks you perform in your org, which we’ll call administration and development. Administrative tasks include things like:
Developing email templates. Creating or editing users. Creating or editing permission sets and profiles.
All of these things are often done in a production org, and that’s fine. You aren’t changing or building applications when you do these things.
On the other hand, when you add a field to an object or a tab to an app or move a field around, you are changing an app (or potentially creating a new one). These are all development tasks, and that’s what we are focusing on here, whether these changes are declarative or programmatic. Best practices dictate to perform development tasks outside of your production org.
Pitfalls of developing in production
What can happen if you don’t test your changes in a development environment first?
A workflow rule accidentally creates an infinite processing loop. A change in a field’s type modifies data in ways you can’t undo. A logic error in a validation rule prevents you from saving a record. Page layout changes confuse people instead of improving their experience.
Sometimes a minor edit to one thing can have an unexpected cascading effect on many other things in your production org. For example, each of these tasks has a ripple effect.
Editing any aspect of custom objects or fields. Activating critical updates. Creating a new tab via the Setup UI.
Why? Because even a simple change to your data model may have far reaching consequences.
For example, let’s say you change a field’s type. This change can modify the data in ways you can’t undo, and it’ll likely cause a lot of Apex code to recompile.
The types of changes you make to develop an app could invalidate Apex bytecode, the pre-compiled, ready to execute representation of your Apex. The invalidated code needs to be recompiled. When your end users initiate an action, such as saving a record, the response from Salesforce will be delayed while the Apex code is being recompiled.
Let best practices guide you to success
You want a change management process that reinforces that development should occur outside of your production org. A change management process determines what kinds of modifications you allow on your production org, when they can occur, and who is responsible for making