5+1 Admin Tips: Troubleshooting in Salesforce - Part III

In the previous post of this series, we finally got all the information we need. This time we’ll tackle the process of troubleshooting itself and how to diagnose the issue.

Tip 5: Reproduce the error with the complete list of steps

Create a step-by-step list of instructions (following the previous guidelines) to reproduce the error and be specific about each step the user does and how the system responds. Then run that sequence a couple of times to make sure you captured everything so that anyone can get to error. For example: if you report:

1. Searched for Services.
2. Results are displayed.
3. Results cannot be sent by email.

This will lead to a lot of questions:

• Where does the user access the search page from? Is it a tab? From a button, where?
• Which fields did you search by? What values did you input in each filter?
• What do you mean by the “results cannot be sent”? Is there a button to send the results? Is the button disabled? Are the results automatically sent after search?
• To whom should the email be sent? How is the email address entered?

The best is to define everything you do to allow the support team to get to the error and figure out what caused it. In the above example a better definition would be:

1. User goes to the Contact page of a Contact with “Client” record type (I’m using this one https://test.lightning.force.com/lightning/r/Contact/0030y000000aaalAAD/view)
2. User presses the button called “Search Services” at the top-right of the page layout.
3. System displays the Search Services page with the filter criteria panel on the left and empty result panel on the right.
4. User enters search criteria with Available on Weekends = TRUE and presses the Search button.
5. System displays the results in the result panel.
6. User selects which results to save and presses the Send button.
7. System displays a popup with the options to send by email.
8. System displays a box prepopulated with the Contact’s email and the user can enter additional emails separated by comma.
9. User presses Send Email and the system sends an email with the PDF version of the results to the emails entered. This is the step that is failing, I click the Send Email button to send the email to this contact (which has my email) and it doesn't.

There is no waste in these instructions, every line and every bit of information in each line is necessary to reproduce the error completely and timely.

Why does the support team need all this information?

Once the request has all the steps, the support team can start working on the diagnosis and fix. This is the point you need to be at to start finding out why this particular sequence leads to an error. When you are reporting an issue, the more you do to get to this state before you send it over to the support team, the sooner you’ll get a fix. If for every condition, every link, every line, the Administrator has to guess, assume, go in blind or ask the reporter, then reproducing the error will be more difficult, if not impossible. There is no way to solve a problem when you can’t even see the problem. If the support team has to spend time getting the sequence of steps in a long back-and-forth as they are trying to solve it, the resolution time will be further delayed.

Not needing any more immediate feedback from the end-user who reported it allows the support team to:

• Prioritize the request.
• Assign someone to review it.
• Work on their own schedule to review it.
• Block time to review it without interruptions.
• Focus and get into the context of the request.
• Follow the instructions provided.
• Get to the error.
• Diagnose the cause.
• Find possible solutions.
• Book their time for reviewing it.
• Give the (hopefully) good news of the fix.

Extra Tip: Follow the timeline

The Story of “Su”

Back in 1993, Argentinian host Susana Gimenez, warmly called “Su” by her fans, had a guest on her show telling her that they had “brought a dinosaur from Patagonia” for an exposition. Patagonia is a region known for the discovery of fossils. Su was so caught up by the story, so involved, so captivated, so emotionally invested, that she could only tilt back, hold her chest and gasp: “Seriously?” followed by a brief pause and then added... “Alive?!” It took a second and then everyone in the studio and watching from home (this was a live daily show after all) couldn’t help but instantly chuckle at this candid moment that captured the hearts of millions of fans across Latin America who still to this day, almost 30 years later, remember this TV gem fondly.

We’ll get back to Su after commercials, but just in case you’re wondering, spoiler alert: the dinosaur was not alive, it was the fossils they brought to the exposition. Maybe next time.

The Story of “SGU” (Site Guest User)

One day some processes started getting errors while trying to update certain records. Upon closer inspection there was nothing unusual about those records, all data was complete and consistent. They had all been created by the Site Guest User, but other records also created by this user did not have any issues getting updated. The error didn’t make sense, there wasn’t a clear pattern.

After further analyzing the data we noticed that all records that presented errors when updated had been created before Friday, October 17th, 2020 while some others also created before that date and all the ones created afterwards didn’t present errors. So what was so special about this date?

It took time to detect where the issue was. But then we finally realized that October 17th, 2020 was the day before the Winter 21 release hit that production environment. Before Winter 21 the Site Guest User was allowed to own records. Starting with Winter 21 when a Site Guest User created a record, the default owner is set by Salesforce according to the configuration following these instructions Assign Records Created by Guest Users to a Default User in the Org which in this case was set correctly to:

So that's why records created after Winter 21 and the ones created before but whose owner had been changed to a user other than the Site Guest User were updated correctly. Only the ones created before Winter 21 and were still owned by the Site Guest User were the ones that could not be updated. It turned out to be a matter of when the records were created and who was assigned as the owner.

The Story of Being Human

So how do the stories of Su and the SGU connect? Because while evaluating the records owned by the SGU I had a “Su” moment. I was evaluating the records as if they had been created now with the org as it is configured today, but just like in Su’s story, the life of the records, much as that of dinosaurs, had long passed.

Even if the records are still used, their life was defined between the moment they were created and the moment they were last modified. That’s why they represent not just the data they contain, but how the system would process them at the time. Some fields that exist today did not exist back then. Some validations that are no longer active today were enforced back then. A record that was perfectly valid at the time would no longer pass every check today. The timeframe is essential when properly assessing the situation to determine why certain errors or scenarios appear in your system.

So I had to evaluate the records’ lifetime in the corresponding timeframe, back in the good old days of 2020, when SGU could own records and dinosaurs were still roaming the Earth. Thanks to tip 1 you should realize now why that one precedes them all. This is indeed a humbling experience.

And so I dug up the fossils of the records owned by the SGU to build their timeline and tried to make sense out of it:Finally, the solution was to reassign the owner of those records to an active System Administrator which would not cause the issues when trying to update them.

The Takeaway

To solve a problem we need to know what the problem is and get into that context. But then there’s the problem of explaining what the problem is. Problems are complex enough as they are. It’s challenging to troubleshoot even if you have the sequence of steps that lead to the error. But that’s why getting that sequence should not be part of the problem. 

The best we can do is get the explanation of the problem straight out of the gate so that we can focus on the solution. This is a team effort and everyone should be aligned so that the time spent is mostly dedicated to find a fix. And for such an effort to take place, everyone needs to be in that focused problem-solving state of mind.

What do you think of the process of troubleshooting? Do you have any recommendations to report issues in a more streamlined manner? Tell me all about it or suggest topics you want me to write about in the comments below, in the Salesforce Trailblazer Community, or tweet directly at me @mdigenioarkus. Subscribe to the Arkus newsletter here to get the top posts of the Arkus blog directly to your inbox.