Salesforce has countless configuration and customization options. You can configure with standard functionality, like triggered actions and workflows. You can customize to integrate third-party applications, like document management or a marketing automation platform. Or, you can even build custom apps from scratch with Lightning web components and APEX to address a particular need.
And as your organization continues to grow and evolve, the demand for Salesforce customizations will likely grow with it. When done correctly, customizing Salesforce improves the user experience, which raises adoption rates and increases Salesforce ROI.
You can safely develop some of this new functionality in your production org, such as new dashboards, reports, and email templates. However, certain customizations made directly in production, like new workflow rules, fields, and page layout changes, can create issues when overwriting or deleting data.
How do developers ensure that these changes are completed and published without negatively impacting their Salesforce platform’s existing functions? The safest way to customize your org is to make and test changes using a dedicated environment for development, like a sandbox. To do this, developers often use a model called change set development, which enables them to make changes to certain apps by using a group of components deployed in sandboxes.
This post will introduce the concept of change sets, look at a new feature from Salesforce related to this topic, and review what to consider before you start using this new feature.
What Exactly are Change Sets?
Change sets in Salesforce are groupings of components deployed from one organization (sandbox) to another org (production). Both the destination and the target org can be either a sandbox or a production org. But the factor that makes change sets truly unique is their declarative nature. The entire process can be done within the Salesforce.com user interface with point and click tools. Developers can use permission sets or profile settings to specify permissions and other access settings in a change set.
When you’re using the change set development model, though, it’s important to track every change. And the first step of tracking these changes is establishing which method to use. Many Salesforce admins will create a ticketing system for Salesforce enhancements and use either cases or a custom object to hold those tickets. Developers may use more robust tools to log each change they make, like the Setup Audit Trail tool from Salesforce. Setup Audit Trail tracks the recent setup changes that you and other admins make to your Salesforce org. Audit history is especially useful in orgs with multiple admins.
Regardless of the method, tracking changes is critical to the Salesforce development lifecycle, as it's the only way to be sure that the customizations deployed won’t overwrite or unexpectedly change the production org.
How Automatic Source Tracking Helps Developers
As part of their Summer ‘20 release, Salesforce launched a new source tracking feature (currently in beta) that makes it easier to track changes between your local workspace and your sandbox. Salesforce had previously released a similar feature for scratch orgs.
When source tracking is enabled, the sandbox automatically tracks changes between the sandbox and the local workspace. When you pull sandbox changes into your project or push project changes to the sandbox, only the changed source syncs back.
What does this mean for developers? In short, faster development cycles. The new feature automates the deployment process, such that once it identifies a change in the source code, it automatically deploys the change to the sandbox. This way, developers can see new code’s impact on their sandbox environments instead of triggering a deploy manually.
What To Know Before Enabling Source Tracking
A key thing to remember about source tracking for sandboxes is that it’s only available for Developer and Developer Pro sandboxes, not Full or Partial copy ones. While Developer and Developer Pro sandbox copies all metadata from production when refreshed, they don’t include any actual data.
Developers who want to take advantage of this feature will have to populate their Developer and Developer Pro sandboxes with fresh, relevant test data. Seeding the right test data can be a challenge. That’s because you need to be able to filter and refine your test data, exclude attachments and certain sets of data, all while maintaining relationship integrity for the data you’ve selected.
Populate Sandboxes With Ease Using Own
Own Accelerate is an intuitive and powerful sandbox seeding solution for organizations that want to maximize their Salesforce platform for training, development, or testing. Salesforce administrators and developers can easily seed quality data to any sandbox with desired objects and records while maintaining all relationships and masking all sensitive information.
To learn more, check out "The Ultimate Guide to Sandbox Seeding in Salesforce" or request a demo below.
.avif)
.png){kind=logo}
