Once upon a time, Salesforce was a simple customer relationship management (CRM) tool that could be easily managed by a single person or a small team. But that time is well in the past.

Today, enterprises are transforming Salesforce into a single source of truth for the whole business and the lifeblood of the modern organization. Salesforce’s low-code software approach (clicks, not code) has opened the door for more teams and skill sets to configure on the platform, meaning businesses can realize faster time-to-value of new tools and features developed with point-and-click tools instead of writing code for maximum business agility and efficiency.

However, like all paradigm shifts, this low-code revolution doesn’t happen without a few stumbles. Standards, methodologies, and tools for code-based development have evolved over decades of software development. But declarative-first platforms, like Salesforce, are shifting the onus of managing app updates and new feature releases to configs made by Salesforce administrators and operations teams. In many cases, the concepts of development may be equally applicable to configs- and code-based changes, the traditional tools have not kept pace. One example of this is the concept of deployments. 

What is deployment?

Deployment is simply the process of releasing new functionality to users. Most Salesforce admin’s introduction to deployments is through building Change Sets. Low-code super users and admins also need to consider how they will move their config changes through the release path to production, which may not be possible with Change Sets. 

It’s these config-based changes that can present a host of potential deployment issues, as teams battle to release updates quickly in the name of speed and agility, without exposing their entire organization to the possibility of unintended consequences from poorly managed releases.

Deployment issues can become big problems

Like all core enterprise systems, Salesforce isn’t an island unto itself. That is, other apps and systems depend on Salesforce data being current and complete, and failing to account for dependencies when modifying or updating Salesforce apps can create a number of new challenges that Salesforce admins may not be well-equipped to handle.

Loss or corruption of relational data

Salesforce’s relational database structure allows users to relate objects to share information between objects. But those data relationships can easily be broken by poor data hygiene practices, modifying records and configuration settings, or accidentally deleting large volumes of data.

Worse, as more teams across the business add or request more apps, it increases the probability of misconfiguration because any little change or mistake can have a massive negative impact. For example, an inadvertent change to a discount rule may cause quotes to miscalculate or a miskeyed field accidentally reassigns sales accounts to an inactive user.

In either case, remedying broken data relationships for such important basic functions is time-consuming and labor-intensive, as admins have to manually scour change histories (if they tracked them) and rectify whatever errors they’re able to find — all while business users eagerly await the restoration of critical functionality. 

Duplicate data between Salesforce orgs

While data relationship loss is a big concern, duplicate data can also have a significant and unpleasant impact on everyday activities often compounding relational data issues. Read the rest of this entry!