Written in partnership with Ziipline. Ziipline is a multi-cloud Salesforce partner that puts innovation and business impact at the heart of everything we do. We partner with organisations of all sizes to build & deliver strategic Salesforce programmes designed to maximise your investment in Salesforce. You can find us at www.ziipline.com or on LinkedIn.

‍

When building Salesforce solutions, we as admins, developers & architects, have the shared goal of building configurable solutions. A configurable Salesforce solution allows us to control the behaviour of our solution without requiring underlying changes to the business logic and automation - such as code or flow. 

A common example might be a ‘feature toggle’ - where functionality is deployed but not made fully active for all users until a later date. Another would be storing a Record Type Id in a custom setting, which could be configured with a different value in different sandboxes if required.

Some of us (probably most of us!) will have experienced the pain of working with Salesforce orgs that don’t respect this practice:

• Hardcoded values, URLs or ids that only work in one environment. 
• Lack of confidence in the current state of the sandboxes for development and testing.
• Long lists of manual steps after each release to update values that are only specific to that single environment. 

After previously inheriting a release process with 100+ manual steps (each deployment!), I was forced to quickly become passionate about this topic. Designing a configurable system from the ground up is one of the ways we can make our lives easier.

‍

‍

How can we build configurable systems?

Some examples of the primary Salesforce tools that we are able to leverage when building configurable solutions include:

Custom Metadata‍

• The best option when you can incorporate the configuration into your deployment process (no manual steps!).

Custom Settings

• Great for sandbox-specific differences or leveraging the hierarchical features. Arguably, configuration data as well!

Configuration Data

• Ideal when complex relationships are required between configuration records and the above approaches are not suitable.

There is no 'best' choice. Each tool is a different approach for a different problem - but one will likely stand out as the best fit for your use case. In this article, we are going to focus on configuration data specifically. How we can use, manage and deploy this data within the context of a Salesforce solution.

‍

What is configuration data?

Configuration data is simply data within standard or custom objects that is used to control the behaviour of a system. This data typically has the following characteristics:

• Data within Salesforce objects
• Data that controls automation or behaviour of the system
• Protected, administrator or developer controlled data
• Follows a build -> test -> deploy development cycle

‍

Example 

Let’s take a simple fictional scenario for a company that manufactures and sells bicycles to retailers:

• Their products (bicycles) and prices change roughly once per year
• They offer a discount based on the country of the retailer
• When a product is added to an Opportunity then the system automatically runs an automated pricing calculation to determine the correct price. 

‍

‍

As we don’t want to hardcode the prices & discounts into the pricing calculator, the above example fits our characteristics of configuration data:

• The data sits within Salesforce custom objects and there are complex relationships between those objects
• The products & prices don’t change often, but they do require changing periodically
• The pricing calculation should be protected from the sales users, thus the admins want control of the inputs
• Changes to the pricing calculator should be developed & tested in a sandbox before release

‍

Challenges

Now, I know you are getting excited at this point thinking about how this data can help deliver a configurable pricing calculator solution. I’m excited too. However, there are some challenges that we will need to overcome to make this approach attractive:

Release Management 

• Moving this data between our development, test and production environments could get painful and cumbersome.

Visibility & Accountability 

• Ensuring that we know who changed what data and when it was changed. This could mean reviewing & approving changes before they are added to a release.

Versioning 

• The ability to roll back to a previous version if we hit any issues. Never straightforward with Salesforce anyway. 

Confidence in our Environments 

• Making sure all of our developer and test environments are kept up to date with the latest data and don’t fall out of sync. We never want to hear ‘oh that doesn’t work in that sandbox’.

Sandbox Seeding 

• The ability to quickly setup new environments with the right configuration data. We don’t want someone to have to run a complex set of manual steps to load the data.

There is nothing unique about the above challenges; in fact many of us will have solved these exact problems for our core metadata release processes. We are now presented with the same issues for our configuration data.

‍

Data as Metadata

If this configuration data is just as important as our metadata for system behaviour, and has many of the same devops related challenges as metadata, why should we treat it any differently?

This data wants to be metadata. If we change our mindset and treat this data as metadata, we can solve the challenges of managing our configuration data. 

If you are already following a source-driven development process, where your version control system is the source of truth for your metadata, then it’s simple. We are building on your process to also support your configuration data. Examples might include:

• Creating feature branches and committing data changes into version control 
• Pushing & pulling data changes to or from a scratch org / sandbox throughout development
• Code reviews, pull requests and approvals before merging data changes
• Automated CI/CD pipelines for checks and data releases to other environments

‘But how can I pull or push the data from my local version control system to an org?’ I hear you ask. What a great question. It’s clear we’re going to need a tool or two to help us out.

‍

What tools are available?

There are several different tools available that can help us manage data when dealing with a Salesforce org:

Manual data loads e.g Salesforce data loader, inspector chrome plugin

• Useful for one off deployments with a low barrier to entry
• Can be time consuming and risks human error

Dedicated DevOps tools that support configuration data (like Salto)

• Brilliant for fully unifying your metadata & data deployments under a single, user-friendly tool. 

SFDX Data Move Utility (SFDMU)

• Great for developers comfortable with some hands-on configuration to setup repeatable automated deployments and can be incorporated into existing CI/CD processes

Changing our Mindset

In part one of this two-part series we’ve explored why we want to build configurable systems and how configuration data is one of the approaches that allows us to do this. However, I would argue that the biggest change is actually conceptual. We’ve changed how we think about this data. By thinking of this data as metadata, we can harness all the benefits of our DevOps and release processes for our configuration data as well as our metadata.

Although we’ve touched on the tools that are available to help us manage this data, we haven’t truly explored the complexities. In the second article we will explore in detail how we can use the SFDX Data Move Utility (SFDMU) to manage our configuration data at scale.