This article discusses the special behavior that you should consider as you are executing deployments using Snapshot. Most of these considerations stem from the quirks of the Metadata API so it would help to read salesforce's Special Behavior in Metadata API Deployments article.
Apex Classes and Apex Triggers
- By default, you cannot deploy Apex code that have Apex jobs pending. You will need to cancel those Apex jobs or better yet enable deployments with Apex jobs through the Setup UI.
- Remember to add the Apex Class Access and Apex Page Access from Profiles to open up your Apex Classes and Visualforce Pages to your users.
- If you are deploying a new Field and the associated Object does not exist, a very basic Object gets created for you.
- If you are deploying a picklist field, it is better to migrate the appropriate Value Set - Global Value Set for custom fields and Standard Value Set for standard fields - with the field. For example, to update Status field with proper picklist values, please make sure that you are migrating the StandardValueSet CaseStatus.
- When you are deploying a new Custom Object in their entirety (for example, Unpackaged > Custom Objects > My_Custom_Object__c as shown in the joblist), you are selecting all parts of the Custom Objects - all fields, field sets, validation rules, including all the descriptors like enableReports, enableSearch etc. You do not need to select them individually. In fact, if you do, they are removed automatically in the Deploy Metadata tab as the Custom Object selection supersedes those partials.
- If you are deploying partials for a new Custom Object, a new Custom Object is created with just the very basic set of descriptors and then filled in with the partials being deployed. For example, if you deploy just one Custom Field, the Object gets created and then filled with the Field. There will be no ListViews setup for this new Object.
- Deploying a new Custom Object will also set the Org-wide Defaults but not the sharing rules. You will have to deploy the sharing rules separately. As of Spring '21, you can deploy a new Custom Object + Owner Sharing Rules together. This was not possible before.
- If you are deploying a Custom Settings object, you will need to fill that with data. To do that, you need to run Build/ Migrate Datasets as these are data records and not considered as metadata.
- If you are deploying a Custom Metadata Type (__mdt) object, you will need to fill that with data by deploying the relevant Custom Metadata Type records (these are metadata assets as well).
- If you are deploying a Knowledge Article Version (__kav) object, you will need to fill that with knowledge articles. To do that, you need to run Build/ Migrate Datasets as these are data records. Please note that these articles can be created only but cannot be updated through the API.
Data Category Groups
- Do not update existing Data Category Groups using Snapshot. You can deploy new Data Category Groups. However, when you update, the Metadata API will yield some drastic results. This recommendation is from Salesforce and is documented here.
Flows/ Process Builder
- By default, flows are deployed as inactive and need to be activated after deployment. To deploy them as active, please enable the Deploy Flows as Active in destination Org before deploying. This will also run test classes to confirm code coverage as part of the deployment.
- When deploying a flow version, it becomes the latest version on the destination and is active (if Deploy Flows as Active is enabled) and the existing active version becomes deactivated.
- This is no longer needed to be deployed. Just use the Flows metadata type. This metadata type exists for legacy reasons.
Flexipages/ Lightning Record Pages
- Lightning Record Pages, also known as Flexipages, deploy in a deactivated state. You have manually activate them and assign them to the appropriate Profile/ Home Page/ Record Type/ Application etc.
- To automatically activate Flexipages, please deploy the appropriate permissions with it. For example, if a Flexipage is used in an Action Override, please deploy the appropriate ProfileActionOverride (in Custom Application) with it.
- You can deploy Installed Packages to install/ update managed packages to a destination.
- You cannot downgrade packages reliably by deploying an older version to a destination.
- You cannot reliably upgrade salesforce published managed packages like CPQ or Advanced Approvals.
- Deploying a new profile essentially clones one of the standard profiles (Standard User, Standard Platform User etc) based on the incoming profile's license and then overlays the incoming profile's privileges on top of it. This means you could get unintended additional privileges in the newly created profile. So, always manually clone the Minimum Access User Profile and then update this "new" profile. This problem does not exist with updating profiles.
- Creating a single field or Object or Apex Class updates all Profiles in your Org. So, just because Snapshot shows that there is a difference, you do not need to deploy it. You can deploy partials and get the same effect.
Users and related data
Any users related data is considered as data and not metadata by salesforce. So, you cannot deploy them but can migrate them using Build/ Migrate Datasets. So, this would apply to:
- Account Teams
- Opportunity Teams
- Group Members
- Campaign Members
If you need more information about the above material or want to discuss other metadata, please contact Metadata Support. We are here to help!