Deployment Best Practices

Why Developing Directly in Production Isn't a Good Idea

Deploying changes directly to your live Salesforce production environment is generally not a good idea because it introduces significant risks to your business and users. Even small modifications can have unexpected, cascading effects that disrupt your system. For instance, changing a field's type can irreversibly alter data or cause Apex code to recompile. A single, untested update can break a critical process, mess up your data, or make the system unusable for your team or your customers, leading to a scramble to fix things while everyone waits.

When you’re developing or modifying an app, the safest place to make and test changes is in a dedicated development environment, such as a sandbox or scratch org. And some changes must be made in a development environment to safeguard your production org, such as writing Apex code.

A robust release pipeline with multiple testing stages ensures a smooth deployment to production by:

• Validating that integrated changes work together.
• Allowing you to practice the deployment to identify any issues.
• Making sure you include everything you need in your deployment artifact. If you missed something, it'll be obvious when you test it.
• Providing multiple stakeholders the opportunity to test the changes in a Partial Copy or Full sandbox (user acceptance testing).

What Changes Can You Make Directly in Production?

While developing or modifying applications in your production org is generally not recommended, some administrative tasks are perfectly fine to perform directly in production. These tasks typically don't involve changing or building applications themselves, but rather managing existing configurations or user access.

For instance, you can safely perform administrative tasks such as:

• Developing email templates.
• Creating or editing users.
• Creating or editing permission sets and profiles.

These types of actions are common and acceptable to execute directly in your live org. They help to keep it running smoothly without the risks associated with larger development changes.

Embrace Change Management and Good Governance

Maintaining a healthy and stable production environment is crucial for your business and customers. This requires a strategic approach to deployment, grounded in best practices for governance and change management, also known as application lifecycle management (ALM). These practices establish a framework for change: defining what, when, and how changes are introduced. This gives teams confidence and provides traceability, leading to smoother, more consistent deployments.

Here are some suggested governance rules to encourage good development practices.

• Minimize who can develop in production. Limit "Customize Application" access to admins.
• Restrict permissions to perform programmatic deployments to a small number of admins.
• Be judicious about the changes you make via the Setup in production, and stick to administrative tasks.

Be Strategic About Deployment Timing

During a Salesforce deployment, the impact on users can range from a minor inconvenience to a complete disruption, depending on the type of changes and the time of the deployment. Be sure to steer clear of peak hours when everyone's actively using the system. Avoiding peak times is especially important if your deployment might cause Apex code to recompile or cause Apex concurrency errors, which can greatly reduce application performance.

Additionally, avoid deploying right before holidays or major events to prevent any unnecessary headaches or disruptions. Instead, try to release at times when most users are off the system.

Try to stick to a consistent release schedule. For example, aim to release at regular intervals and on a given day of the week. Even here at Salesforce, we schedule regular release moratoriums to avoid system-wide disruptions during critical times. Scheduling consistency helps with company-wide planning and sets expectations with your business users and customers.

Watch for Deployment Dependencies

When deploying to Salesforce, a simple approach for ordering your deployment can significantly ease the process and help resolve dependencies efficiently. Here, we provide some general information and guidelines.

Note Some Salesforce features and products have their own specific information for deployment best practices. Be sure to review your feature's product documentation before formulating your deployment strategy.

A recommended sequence is to deploy in this order:

• Objects
• Apex classes
• Visualforce components and pages
• Lightning web components (LWC) and Aura components
• Apex triggers and other metadata
• Profiles and permission sets
• Sharing rules

To avoid issues early in the process, deploy objects first. Include new custom objects, fields, record types, and other necessary metadata components. This sequence is especially important for components like compact layouts and list views, because of their direct dependency on objects.

For profiles and permission sets, be sure that all related metadata is deployed beforehand because profiles act as an overarching layer that ties together many dependencies across the org's metadata.

Deploy sharing logic near the end of your deployment window because it operates at the record-level. Deploying a full profile or permission set that contains a sharing rule, for example, triggers a calculation each time you attempt to deploy, which can be time-consuming if there are multiple failures. The timing of sharing logic deployments is critical due to the sharing recalculation process.

Additionally, any changes made in an org, particularly to sharing rules or group settings, or structural changes in role hierarchy, can cause Apex code to recompile, which can increase processing times.