How to master Org dependencies in Salesforce

Introduction

Salesforce is the most powerful customizable business application on the planet. Because it offers rich, declarative and easy to use ways to change the Org configuration, it serves as a hub for business innovation. However, that power also introduces complexity. The more the Salesforce Org is configured, the more automations and innovations are built and put in place, and the more challenging it becomes to manage that complexity. The challenge of managing Salesforce at scale comes from the lack of visibility of what is used where, how, and what the impact will be of making a change. Not to mention, the continuously accumulating technical debt. A lot of the time, it is akin to playing Jenga while blindfolded.

These dependencies are not merely technical at the level of metadata relationships. There are also plenty of organizational dependencies, i.e. business processes, internal procedures, and operational business processes that are also dependent on the current Salesforce configuration. And in many ways, these are even more difficult to account for than the technical ones.

In this blog, I will explore how Elements.cloud helps you capture, identify, and explore all of them. And how, through most innovative capabilities in the Change Intelligence market, Elements allows you to explore them at scale.

Exploring Various Types of Dependencies

First, let’s understand the different types of dependencies within an Org:

Dependencies between Salesforce Metadata:

This is what most people think about when they hear ‘Salesforce dependencies’. It is a relationship between two actual metadata components, where one ‘references’ or ‘uses’ the other.

An example would be a flow that uses a specific field in its logic, or a report being used in a dashboard. These dependencies can be determined from analyzing the XML / JSON / Code definition of the metadata component and finding a reference to another metadata based on its ID, label, or API name.

Change Intelligence applications can help spot that either by allowing users to ‘search’ through the metadata definitions manually or by automatically finding those references. Elements has the most robust approach to both.

Data flow dependencies:

This type of dependencies is of biggest concern to architects. It is a type of relationship that determines how the data flows through the standard and custom objects and fields. Unlike the previous type, data flow dependencies are not always direct and require much more detailed analysis of metadata definition files.

A simple example would be, for field dependencies, a flow that uses 7 different objects and 45 fields in its logic. It is triggered by a record operation on one of the objects, then reads 20 fields from 4 other objects to make various determinations, to then create and edit records on 2 other objects. Understanding what automation does with data, step by step is important because it allows us to accelerate troubleshooting and quickly appreciate impact on business processes when planning future changes. But it can be determined from the metadata definitions.

A bigger challenge would be a dependency that is not at all ‘hardcoded’ in any definition, instead, it has to be interpreted and implied from the business logic interaction. For instance, a flow that creates a new case does trigger an order of execution for that case. Namely, record-triggered automation, required field checks, validations and other metadata will run as a result of record creation. But those different automations actually have no knowledge of each other, as they do not reference each other directly.

A Change Intelligence application should be able to help you qualify how automations use objects, fields, and even other automations, to help you visualize a sequence of data actions through your Org. But it should also help you determine and understand the ‘logical’ dependencies that do not simply reside in code.

Data model dependencies:

Data in your Org is also managed through hierarchical relationships between objects, through lookup and master-detail relationships. A change in object configuration, and by extension, the data stored within, can have an enormous impact on millions of records of data stored across standard and custom objects. These hierarchical relationships define not only how objects associate with one another but also dictate the behavior of these associations in terms of data sharing, security, and cascading actions.

For instance, deleting a parent object in a master-detail relationship can result in the deletion of all associated child records, a dramatic action that can have significant implications for data integrity and business operations. Furthermore, changing the relationship type or modifying sharing rules can affect data visibility and user access across the organization. Thus, recognizing these dependencies allows for more informed decision-making.

A Change Intelligence application should equip you with the ability to capture and visualize your Salesforce’s data model manually or automatically so you can understand and appreciate the impact on data before making substantial changes to the object.

Organizational dependencies:

This type of dependencies is of biggest concern to business analysts. And in some ways, this is the most challenging one to properly capture and utilize. Organizational dependency in a relationship between metadata and people, determining how users leverage various metadata types. And it is impossible to account for without process documentation.

It is relatively easy to determine that a field is used in multiple different automations or reports. What is extremely hard is understanding that a field, that might not be used in any automation or reports yet, is heavily used by users to drive business decisions manually.

This issue is most profound on ‘shared’ business objects, like Account, Opportunity, or Contact that get utilized by every department, like finance, sales, support, marketing, and even product. Each department uses some fields and attributes of those objects, some of them might be unique to them, and others would be shared across departments. If a sales team would like to change pipeline stages on the opportunity object, a business analyst equipped with process documentation would point out that the field is also used by the finance team in financial forecasting, may be used by marketing to track success of their campaigns, and therefore there are many other business processes and stakeholders reliant on that one field.

A Change Intelligence application should be capable of helping you capture and document which processes and business users are reliant on which areas of your configuration. The benefit for businesses include accelerated analysis, custom development that fits the purpose, and overall saving on business’s time, cost and effort.

Challenges of Managing Org Dependencies

Managing Org dependencies requires solving two distinct problems: tracking and analysis. 

Tracking

Of the 3 types of dependencies, the direct metadata to metadata relationships are the easiest to track – but still require a huge amount of code to be written to discover them. As stated earlier, these dependencies stem from one metadata component being referenced (hardcoded) in another. Therefore such dependencies can be tracked by either automatic pattern-matching or manual search through metadata definition files.

Elements supports both ways of tracking direct dependencies. When we sync the Salesforce Org, as part of the processing of metadata definitions, we perform robust pattern matching to find references to other metadata and identify how they are being used.

However, building robust pattern-matching algorithms is complex and there is no Change Intelligence platform that can support all dependencies through automated insights. Therefore, it is equally important to allow users to find references through robust search to compensate. They can then make the connections manually.

The other types of dependencies, especially organizational dependencies, are virtually impossible to track automatically. This is because the knowledge of those dependencies does not stem from hardcoded references but rather the business logic of the platform or business processes by which the company operates. The indirect impact of planned changes on Salesforce users is only possible through robust documentation.

This knowledge does exist and we do capture it all the time across the entire development cycle. Procedural documents, design diagrams, project charters, user stories, step guides, and others. The challenge is not in creating those assets, as it is with retaining them. Far too often important documents get lost in folders and sub-folders, never to be found again. As more changes are rolled out, these documents get outdated and cannot be trusted anymore, leading us to create them from scratch.

A proper Change Intelligence platform will allow you to capture all of that design documentation contextually against the relevant metadata. That way, your metadata dictionary becomes in essence, your indexed library of operational knowledge, allowing you to retain, find and update any relevant documentation that states who uses something and why.

Analysis

There is a known cognitive challenge with performing impact assessment, known as ‘the haystack problem’. Even when all dependencies are known and mapped, planned changes are often not implemented. This is because the information overload of too many dependencies makes it challenging and time-consuming to account for all impacts.

Let’s look at an example below. The ‘Stage’ field on Opportunity object is used in 392 different components, including 282 reports. And that is just the ‘primary’ impact, a lot of those components themselves are also utilized somewhere else. That view, while useful for visualization, can quickly lead to analysis paralysis.

At Elements we have long solved the haystack problem by:

• Capturing granular details about metadata relationships, including how and where they are used (e.g. which flow element, column, filter or grouping in the report, etc.)
• Providing users with filterable and actionable grid for metadata exploration

By filtering the dependent metadata down to specific types and searching for relationship attributes, such as any write or read operations, types of triggers, and how they are used (e.g. showing reports that are used as ‘filter’), users have the ability to traverse the complexity of their Org dependencies and identify the relationships that matter to them, based on their use-case. This makes the entire custom development much leaner, including making it much easier to specify what needs to be done for testing purposes.

Furthermore, as there are often many dependencies to account for, too many to remember, it is paramount to be able to keep track of the work to be done. It is too easy to lose track of something and release a change in a production release that will have a profoundly negative impact on the production environment, business logic and user experience.

The dependency grid allows users to mass-select and bulk-action dependencies, most importantly documenting them against one or many stories as to-do items, therefore allowing users to easily keep track of all required work.

How to master Org Dependencies

Navigating the complex web of Salesforce Org dependencies demands a strategic approach, leveraging change intelligence and effective configuration management practices. To ensure successful releases and to maintain the agility of your Salesforce environment, here are key best practices and tips:

Invest in a metadata dictionary

Without an automatic metadata dictionary, i.e. hierarchical structure of your Org’s current metadata configuration you have no chance of nailing your metadata management. Metadata dictionary not only provides you with an ability to visualize and list all your metadata components, and dependencies between those, but also serves as a documentation hub. It allows you to capture and document further, human-generated pieces of knowledge and add them to the overall puzzle.

Adopt configuration management best practices

Effective configuration management is the foundation of mastering Org dependencies. It involves a systematic approach to managing changes in such a way that the integrity and consistency of your Salesforce Org are maintained over time.

This includes documenting all configurations and customizations, as well as establishing processes for reviewing and approving proposed changes. No change should happen without a ticket being raised, documented with regards to business purpose, and assessed for impact on your configuration. When linked to relevant affected components in your metadata dictionary, such tickets provide important business context as to why something was built and how.

Always perform an impact assessment

The biggest cultural shift involves adopting a standard where every work item, story, and project is first assessed for impact on your Organization before any commitment is made to its implementation and timeline. As I covered before, there are many types of dependencies, and you cannot be sure of the impact on any of them without doing proper due diligence upfront.

With a Change Intelligence platform, you should be able to find, review, and action relevant dependencies in a timely manner. These dependencies then become your well-documented to-dos for a ticket and feed into your DevOps processes, specifying what metadata should be part of the planned deployment.

Data / Integration / Process Modeling

Mastering Org dependencies, especially those related to business operations and data flow, requires true excellence. This comes from documenting business process diagrams, data models, and integration diagrams against relevant metadata in your metadata dictionary.

There is a wealth of knowledge that cannot be automatically detected or inferred from simply reading the XML /JSON/ Apex code definitions. For one, because no tool can scan all source files from all the different applications from your tech stack. Secondly, even if there was, there is still plenty of business context that is never part of the underlying code.

Packaging your metadata

While ‘packaging’ metadata has been mostly done by commercial development companies to publish on AppExchange, with unmanaged packages and Second-Generation Managed Packages any company can package and version their Org features in manageable bundles. By segmenting your Org into these concrete packages, the business gains ability to perform beta testing with specific salesforce users and keep dependent components separate from other parts of the environment.

With the help of a Change Intelligence platform, you can identify which objects, fields, flows, apex classes, and other automations are connected together (technically) and which business processes they support. That makes any future changes, testing, and deployment much easier.

Summary

Mastering Salesforce Org dependencies is a journey and it takes some effort to truly become fluent, as an organization, in assessing dependencies at scale. First, it requires an automatic metadata dictionary for your Org, as the size, complexity, and frequency of changes make it impossible to manage it manually. Secondly, traversing the enormity and complexity of the Salesforce configuration and both in-system and cross-system dependencies is impossible to do at scale without a dedicated impact assessment tooling to help you filter and bulk-action relevant metadata.

Most of all however, mastering Org dependencies requires effort and cultural shift. It requires that the entire team adopt a practice whereby every change is always documented as a ticket and all impacted metadata are documented as “to-do’s”, in scope of that task.
Even more importantly, the team needs to be enabled through the Change Intelligence platform to capture and document their design documentation (such as business processes, automation designs, data models, integration diagrams, stories, and planned work) against the affected metadata in the metadata dictionary.

Combining all of those capabilities and practices together, allows an organization to fully master and be always aware of the technical, operational, and regulatory impact of planned changes on their Org.

To find out more, feel free to get in touch here.