Identifying the Root Cause of a Problem (A206)

Identifying the root cause of a problem

Sometimes a change to Salesforce configuration may lead to an unexpected outcome, errors, or lack of access for users. With Elements you can troubleshoot and find the cause of your metadata problems

Occasionally a change to your org configuration (planned or otherwise) may lead to an unexpected outcome – users losing access to certain information, automations failing or computing wrong results, etc. Considering the interdependency between metadata components, it might be time consuming to find out what exactly went wrong, where, and how to fix it. 

More often than not, time is not something you will have in abundance. Every minute the issue persists is more frustration from the stakeholders who are unable to do their jobs. And more risk that the data can be further corrupted.

However, with Elements you can troubleshoot and find the root cause of your metadata problems at the speed of business, using change log comparison. 

Why Elements Troubleshooting Works

In a lot of organizations when an automation, a report or a dashboard stops working or throws errors to the users, an issue is raised with the title ‘Fix it!’. But fix what exactly? Why did the component stop working if it worked perfectly before? 

Whether the fix is given to an admin, or escalated to the developer, in most cases the person responsible will end up going through the entire configuration of a given component. If the issue is with a flow or other automation, they will often end up going step by step to follow the logic and see when and how it can break. 

The process outlined above is time consuming. The admin or developer do not know what happened exactly and are forced to search for the root cause, often with very little direction. However, relying on change log comparisons, and specifically XML file investigations, allows both admins and developers to identify the root causes of any errors or bugs faster.

Even if you are not the person responsible for solving issues with the metadata, by being able to point to the developers or admins the exact changes that happened to the metadata before that might have led to the issue will greatly accelerate time to resolution.

What is an XML file and how to read it?

Unless you are a developer, chances are you have not come across XML files before.

XML (Extensible Markup Language) is a text-based language that is used to identify, organize, and migrate metadata components. You can learn more about XML files in this Trailhead module. In short, an XML file is a textual file with custom tags that describes the definition of a given metadata component. The XML, in simple terms, is the underlying textual definition of a metadata component that you interact with in the Salesforce interface.

On the right you see the flow as you experience it in flow builder. On the left you see the underlying XML definition of the same flow.

Every single detail, even those that are not clearly visible in the interface, is defined in the XML file. Our change log comparison capability allows you to compare the XML files for the same metadata before and after a change was detected. We even color code the specific differences!

Reading XML files may seem intimidating at first but in reality it is very simple. You just need to remember that XML file is:

• Nothing more than a text document with all the details about your metadata configuration
• The text contains hierarchically organized tags

In the example below, we see a field with name Space__c being referenced in a flow component.

How is it referenced? If we look just above, where the indent level is slightly decreased, we can see <filters>. That means that field is used as a filter.

Where is the field used as a filter? Again, we just need to scroll up to find the next tag with a slightly decreased indent level and we see <recordDeletes> tag. That means the field is used in the record delete element in a flow. We can even see the name of that element just below.

Remember, the XML files are just hierarchical and indented textual documents. You do not need to know how to code to be able to read them!

Finding the difference

As you have completed the course on Staying up to date on Org changes, you have already learned how to find and identify what was changed in your Org environment. Once you know which metadata have been changed, you can use the change log comparison to understand how they have changed. 

Find the ‘changelog’ tab on the selected metadata in the right panel. You will see a number of changelog records, time-stamped and ordered chronologically from the most recent.

Click on ‘Inspect change’ to pop up a screen that will highlight how the metadata has changed since the last sync. Click here to learn more about changelog comparison interface.

Reading the XML difference

The screen will pop up 2 XML (Extensible Markup Language) files and highlight differences side-by-side. An XML file is provided by Salesforce APIs, and contains the definition and structure of the metadata component. We store the XML file for most metadata types from the first sync, and we then continue to store a new XML file for each detected update to that metadata item, going forward.

The XML files may seem a bit intimidating at first sight but if you focus on what is written in the text itself it can be easily understood by anyone.

Click to open illustrative example - Profile

Illustrative example: Profile

 

If we look at the example below, we can see that the differences for the profile are on the ‘user permissions’. The ‘Password Never Expires’ permission was turned off as demonstrated by the fact that it is highlighted in red on the left hand side. It means that this is not found in the latest XML file.

 

Separately, we can see that the following user permissions have been turned on: Privacy Data Access, Run Flow, Run Reports. This is demonstrated by the fact that they are highlighted in green on the right hand side, meaning they have been added to the profile.

 

Click to open illustrative example - Flow

Illustrative example: Flow

If we look at the example below, we can see that a field ‘Address’ was removed from the flow element. This is demonstrated by the red highlight in the left hand side – signifying that this definition cannot be found in the latest XML file.

However, this does not tell us enough. A flow can be composed of many different elements and just knowing that it was removed does not help us appreciate what impact this might have had on the flow. However, if we scroll up a little we can navigate within the hierarchy of the file to find to which elements does the field belong to. In this case, it is a screen element called ‘Screen 1’:

 

Click to open illustrative example - Page Layout

Illustrative example: Page Layout

In the example below, we have turned on ‘Only show lines with differences’ to display only the differences between the page layout structure before and now. We can see that we have removed 3 fields (items highlighted in red on the left hand side) and added 3 other fields (items highlighted in green on the right hand side).

 

What’s next

Next, you will take a short, theory and practical quiz. Select it from the menu below.

This quiz will help you to recognise the skills and knowledge you have gained, and identify any areas you still need to explore and learn.

Remember, you can revisit these pages, or ask us for help if you get stuck. Once you pass the quiz, click “Next Module” to move on to Module 2.