Salesforce DX for Admins Salesforce DX is not just for developers! There are important features in Salesforce DX that every system administrator should know about. Some of the exciting new technologies associated with Salesforce DX include Developer Projects, Dev Hubs, Scratch Orgs, Source Tracking, and Unlocked Packages. Salesforce DX is way more than just a command line interface. This blog will discuss how Salesforce DX and associated technologies can help administrators be more effective. We will also talk about how to coordinate Source Based application development and Org Based release management. By working more closely with developers, Salesforce administrators can streamline the change and release management process. The first step for an administrator who wants to take advantage of Salesforce DX is to turn on the Dev Hub in your Production Org. You can do this with the Setup Menu. This will allow you or developers on your team to create Scratch Orgs and view information about them. There is also an option to develop and distribute Unlocked Packages. Turn that on too. We will talk more about both Unlocked Packages and Scratch Orgs later on.

Your Dev Hub is kind of like a private AppExchange for the enterprise. Application developers can create any number of Unlocked Packages and Package Versions and store them in the Dev Hub. These packages can be worked on by development teams and tested out in Scratch Orgs. Then administrators can install the current version of the Unlocked Package in a Sandbox for acceptance testing or a production Org for final deployment.

Source Based or Org Based? Salesforce has made the transition from the world's best CRM product to a full-blown enterprise application development platform. Because of this, application developers are more relevant than ever to the Salesforce ecosystem. But developers want to use the same tools and technologies that they use on other platforms to develop applications. Salesforce DX was released in 2016 with the goal of improving the developer experience on Salesforce and making the development process more familiar for enterprise developers. Salesforce administrators often use the Setup Menu to make changes to an Org. This method might be fine for smaller companies, but larger companies looking for corporate governance, compliance, and security often need a more rigorous change and release management solution. Developers are also likely to be uncomfortable with the concept of creating an application with an HTML interface instead of actual source code.

Because of this, Salesforce DX has introduced Source Based developer projects that exist as a code base on the local computer. These projects store Apex code and other Metadata in text and XML files that can be deployed to Scratch Orgs or used to create Unlocked Packages. The developer projects can also be committed to online repositories where the differences are

tracked over time. In the Org Based model, a live Salesforce Org is the source of truth. In the Source Based model, the Salesforce DX project is the source of truth.

Procedural or Declarative? But the Setup Menu and other Org Based declarative development technologies still provide lots of useful capabilities. Also, many of the Source Based documents are complex XML files that are not really suitable for editing by hand. The Salesforce HTML interface is still the best way to create and edit some of the more complex Metadata types. Another issue is that live Salesforce Orgs are always consistent. When you add a Custom Object to a developer project, a single file is created. But when you add a Custom Object to a Salesforce Org, there are hundreds of reflected changes to other assets. Just because you saved something to a developer project doesn't mean that code can be successfully deployed to a real Org.

Salesforce DX addresses this issue with the ability to push and pull source code. Changes to the local developer project are automatically tracked, and they can be pushed to a Scratch Org. You can also launch a Scratch Org in the browser and make changes with the Setup Menu. These changes are recorded and can be pulled back to the developer project. The ability to push and pull source enables Org Based software development on the one hand and Source Based deployment and testing on the other. Pushing and pulling source can be accomplished from the Salesforce DX command line. There are other environments that can make this task easier if you don’t want to use the command line. For example, our Snapshot product can create Scratch Orgs and push and pull source code with a point and click interface. Production Orgs and Sandboxes do not have the automatic source tracking capability, although we hope Salesforce expands the use of source tracking in

the future. You can always use the Metadata API to deploy and retrieve source files from Orgs without tracking if needed.

Scratch Orgs are also a useful tool for Salesforce admins. They can be used to quickly test out Unlocked Packages or Setup Menu changes. The Scratch Orgs are easy to configure and have various options. Many types of Orgs from Enterprise to Developer can be created in seconds, used as needed, and then disposed of automatically.

Packaged or Unpackaged? When a developer retrieves Metadata from an average Salesforce Org, all of the Custom Objects will be in one folder, all the Apex Classes in another, and so on, for all of the different Metadata types. The Metadata assets are basically organized into silos, one for each asset type. This file layout works pretty well for Salesforce administrators who need to backup Org customizations or move Metadata between Orgs.

But the vast sea of unpackaged Metadata in the average Salesforce Org is not well suited to application development. Developers are expecting to see logical packages that group all of the different assets for each application horizontally. They want to work with the source code for the application, track changes in the application over time, maintain application versions, and test each application independently.

Salesforce DX provides Unlocked Packages to help organize Metadata into logical groups suitable for application development. Unlocked Packages help reduce Org complexity and

provided structure for the unpackaged assets. Packages also help organize application assets into logical groups for agile development teams.

There are many advantages to adopting Unlocked Packages. Bugs and problems are isolated to the package instead of being spread across the entire Org. When a project needs to be upgraded or replaced, the package makes entangled assets easier to identify. Packages are the foundation for agile development teams, enabling smaller groups of developers to focus on more isolated sections of code. Packages lower cost, increase flexibility, reduce complexity, and improve time to production. Unlocked Packages are easy to install. Each Package Version has an installation URL and they can be installed into any Org. From the administrative point of view, the package will be created by your developers or an ISV partner and installed in a Sandbox for user acceptance testing or in a production Org for final deployment. The best thing about Unlocked packages is that they reduce Org complexity and organize unpackaged assets.

Consider an Org where Profiles and Custom Objects are being created with the Setup Menu at a linear rate. The number of object permissions in the Org will increase at an exponential rate. But when you consider the impact of other entangled assets like Custom Fields, Record Types, Page Layouts, and Apex Classes, the overall complexity of the org will skyrocket. Unlocked Packages are the most effective remedy for runaway Org complexity. Reducing complexity should be a regular priority for system administrators in the change and release cycle.

Developer or Administrator? Probably the most important reason that administrators need to understand Salesforce DX is to help them work more effectively with developers in the change and release management process. Developers build Unlocked Packages, but administrators test them in Sandboxes and install them in production Orgs. Developer continuously integrate Apex Classes, but administrators must manage the release cycle. Developer work in local projects with procedural tools and Salesforce DX, but administrators work in the Setup Menu with declarative tools and the Metadata API.

Developers and administrators need each other for the change and release management process to work properly. Developers tend to focus on the limited Metadata types needed for application building: Custom Objects, Apex Classes, Page Layouts, Lightning Components, and Visualforce Components. But there are fully 200 other Metadata Types that are required for the release cycle, and Salesforce adds more every four months. The diagram above points out some of the different responsibilities that developers and administrators have.

Project, Repo, or Org? Pulling source from a Scratch Org almost always works, because you cannot have XML errors or broken dependencies in an Org. However, pushing source will often fail, because the XML might have an error, or because there are dependent assets that are not included in the deployment. Because of this, Salesforce DX has the ability to limit the asset types being pushed. Check out the documentation on the forceignore file for more information. In general, developer projects should focus on Custom Objects, Apex Classes, Page Layouts, Lightning Components, and Visualforce Components. These asset types are needed for source code development and have limited dependencies. More complex and entangled assets should often be handled in the change and release process by the admins. Admins tend to deal with many more Metadata types than developers.

The main advantage of code repositories like GitHub is that they can be used to track changes in developer projects over time and to merge the work of multiple developers into a single project. But be aware that additional changes may be required before the files in the repository can be deployed to a real Org. Other than for compliance purposes, there are few reasons to move all the Metadata in an Org to an online repository. The diagram above outlines the situations in which you might want to save Metadata in a Local Project, an Online Repository, or a real Salesforce Org.

Mundane or Magic? Salesforce DX goes a long way towards making enterprise developers more comfortable with the Salesforce platform. Source Based developer projects pave the way for the future growth of Salesforce as an enterprise platform. But we need to make sure that the magic of Salesforce remains intact. I don't really want Salesforce to become too much like Java or Apache. There are unique aspects of Salesforce that account for the rapid growth and adoption of the platform. Empowering the vibrant community of system administrators with clicks instead of code really sets Salesforce apart from other clouds like Azure and Amazon. We should adopt some enterprise software development practices but focus on disrupting and replacing others. If you would like to adopt the best practices to combine Source Based application development with Org Based release management then please check out our Snapshot product on the AppExchange. I have included a variety of other helpful links below.

Bill Appleton CTO Metazoa Salesforce DX Developer Guide Salesforce DX Command Line Reference Breaking Your Org Into Packages Snapshot on the AppExchange