Salesforce DX has been established as a highly user-friendly and features rich platform for individual developers and developer teams. Apart from its initial purpose of CRM, Salesforce had grown into a complete enterprise application development platform, and DX had made it more flexible and scalable. However, with its source-driven development concepts, Salesforce DX is also raising some challenges to the developers. In this article, we will discuss the source driven approach over setup menu in a bit more details.

 

Setup Menu vs. Source Driven Development

 

One big issue when Salesforce DX first got introduced to developers and administrators is about the ‘Setup’ menu. At olden times, Setup Menu was the most common way in which developers used to configure and administer Salesforce. This is where they used to:

 

• Create new objects
• Add roles and groups.
• Create new objects.
• Build email templates, and
• Control things for users.

 

As Salesforce had further upgraded, Setup Menu was made more complex. There was nothing wrong in this concept as the smaller enterprises moving on to Salesforce were able to do everything they wanted using this Setup Menu.

 

However, larger enterprises needed more visibility and control over this process. They wanted to have specific data-driven information like:

 

• The nature of organizational changes over time
• Differences between Production and Sandbox
• Who and what drove the changes?
• Whether somebody tested it?
• What is the custody chain for the production assets?
• Is there a need for more comprehensive compliance documentation?
• Meeting regulations like HIPAA, FISMA, SOX, GLBA, PCI-DSS, or GDPR?

 

Corporate decision makers didn’t want to hear someone getting into the Setup Menu to change some stuff now and then to make things work again. They always needed instant and precise answers.

 

Also, as specified by Flosum.com, enterprise developers were also used to source-driven development methods where they were able to visualize anything every time on the projects they work on. Code repository acts as the source of truth for any application the build.

 

Developer projects of Salesforce DX

 

In this scenario, Salesforce DX specifies a format structure and file format for the developer projects in the local machines itself. Developers can access the Command Line Interface (CLI) to clone the projects from Salesforce repositories or plan for code commits inside the team. They can also add some frameworks for Lightning Components, Apex Classes, or Visualforce pages. This created a new foundation for source-driven development.

 

Now, the developers can simply push the projects to their Scratch Orgs which are disposable. This works with the conventional model of compile and test, which most of the developers have familiarized with. Developers can easily make changes to the projects with the help of Setup Menu. Such changes can be then pulled back to incorporate to local developer projects. This way, changes can effectively flow back and forth between Scratch Org and developer projects.

 

Overall, Developer Projects can offer the source-driven tools which the enterprise developers are familiar with to make the process much easier and flexible. Adding to it, Second-Generation Packages may act as the base to distribute and deploy these projects. Salesforce DX is yet to flourish fully, but the technology involved is already making this Salesforce platform ideal for the enterprise application developers.