Change Set Implementation Tips

Change sets allows to deploy metadata between connected orgs. By using this, Admin can create the change sets and add the components to it and can deploy it to next org. It can be used to deploy metadata between sandboxes and from sandbox to production.

Below diagram explain the change set implementation:

 Main challenge with change sets is mentioned below.

• If any error comes while validation using change sets then it stops validating other components. So we have fix the error and then again needs to validate it. But if we migrate metadata using ANT, then we get all deployment errors which help us to fix all errors in one shot.
• Deployment process using change sets becomes complex if it involves large number of different metadata.

Solution

If we split the change set into different change set, then it will make job easier. You can split components in different change set and deploy it in order mentioned below:

• First Change set

• Static Resource
• Custom Data Types
• Custom Fields
• Custom Labels
• Custom Objects
• Folders
• Record Types
• Validation Rules
• Custom Settings
• Field Sets
• Remote Sites
• Documents

• Second Change set

• Custom Report Types
• List Views
• Apex Classes
• Apex Sharing Reasons
• Apex Triggers
• VisualForce Components
• VisualForce Pages
• Email Templates
• S-Controls
• Letterheads
• Aura Components

• Third Change set

• Reports
• Dashboards

• Fourth Change set

• Page Layouts
• Buttons
• Links
• Homepage Components
• Homepage Layouts

• Fifth Change set

• Workflow Email Alerts
• Workflow Field Updates
• Workflow outbound Messages
• Workflow Rules
• Workflow Tasks

• Sixth Change set

• Apps
• Tabs
• Analytic Snapshots
• Language Translations

Hope this will help!!

Lightning Tree : Generic Lightning Component to Display Hierarchy for any sObject

In API version 41.0, Salesforce has introduce new component called lightning:tree. This can be used to display hierarchy in tree structure. Before this, we have to used jquery or other javascript libraries to implement this.

After introduction of lightning:tree, it is very easy to use this and implement this in short time.

I have created a generic lightning component to display records hierarchy in tree structure. You just have specify below attributes to component to display tree structure:

• ltngcurrentRecId : Salesforce 15 or 18 digit Id of any record for which you want to see hierarchy.
• ltngSobjectname : sObject API name (like Account, Case, Position__c etc.)
• ltngParentFieldAPIName : Field API name which creates self relationship between records.
• ltngLabelFieldAPIName : Field API name which will be used to display records in tree structure(like Name, CaseNumber, Title__c etc.).
• ltngHierarchyHeader : Header label which will be displayed above tree structure.

Below is complete complete code for your reference:

You can use this code as reference and can implement different logic.

Hope this will help!!!

Looking forward for everyone's comments and suggestions.

How to fix error while deploying new custom objects along with list views to new Org

Below are the two different errors we got when we deploy new custom object along with list view to new org through single single package:

• Error: This View Unique Name already exists or has been previously used. Please choose a different name

First error happens if you have list view on object which is shared with all internal users. If you remove below tags from exported metadata of list view, then you will not get this error.

<sharedTo>

        <allInternalUsers></allInternalUsers>

</sharedTo>

After removing these tags, I was able to deploy successfully.

• Added entity: New_Object__c support on queue: New_Queue

This error happens because your list view refers to queue and same queue refer to same object.

Resolutions:

• Split your package for deployment because there is dependency between object, list view and queues. Deploy these three things separately. 
• First deploy custom object with basic information. Remove list views tags from .object file before deployment.

Best Solution:

Create custom object manually in target org and deploy the package. This is best approach as you don't have to change any metadata files.

Recommendation:

Deployment errors also come if you deploy approval process which contains approver as queue and those quesues refer to same object on which you have approval process. So always first create custom object in target org and then deploy queues and then deploy remaining things.

Hope this will help!!!

Webinar : Build Smarter Apps with Einstein Platform Services

This webinar was held on 28th September, 2017.  Below are the list of speakers for this webinar:

• SHANE MCLAUGHLIN (Principal Demo Engineer,Salesforce)
• KATIE HURLEY (Senior Manager, Product Marketing Salesforce)
• KRIS CHANT (Director, Developer Marketing Salesforce)
• MICHAEL MACHADO (Director, Product Management Salesforce)

This webinar helps in understanding Einstein Platform Services. This is intended for Administrators and developers. If you missed this webinar then, you can refer below webinar recordings and slides.

Webinar Recording:

Webinar Slides: 

Build Smarter Apps with Einstein Platform Services from Salesforce Developers

Hope this will help!!!