Mwuhahahaha! Welcome to spooky season, my dear Salesforce enthusiasts! I think it’s time for some campfire stories that are sure to send chills down your spine and stick in the back of your mind as you continue to evolve your own Salesforce orgs. Who knows, maybe you’ll learn from some of the unfortunate victims in these stories and avoid making similar mistakes yourself!
The stories you’re about to read may or may not be based on real events, with the names of the real victims changed for their own privacy…
1. The Tale of the Dreadful Data Loader
Once upon a time, there was a young Salesforce Admin who was tasked with updating a series of account records in his Salesforce org. He was given an Excel spreadsheet that was covered in all sorts of colored cells, had varying fonts, and a deadline – the update had to be done by Monday morning, and it was just before lunchtime on Friday.
Desperately trying to avoid having to work on the weekend, our admin took a quick lunch break and got stuck into tidying up the Excel spreadsheet. He removed the color, aligned the data, and took one last quick glance at the spreadsheet before exporting it as a CSV ready for updating.
With a sigh of relief, and just before 3 pm, our admin loaded the CSV into Data Loader, auto-mapped his fields, and executed the update. He was done and could even consider an early mark, given that there wasn’t anything else too pressing he had to do before the end of the day.
He merrily jumped into his car and started the drive home. He called his wife and told her he’d be home early and would start preparing some dinner, excited to relax after a long week. Suddenly, he got an incoming call from one of the sales team…
He sent it to voicemail and figured he would deal with it on Monday. A few minutes later, he received another call, this time from someone in the marketing team. Similarly, he decided it could wait until Monday and pushed that call to voicemail too. The last call had barely stopped ringing when his manager, the CTO, called him. Knowing he couldn’t ignore this call, he sheepishly answered, wondering what had happened…
His manager explained that people were having an issue with the Account Description field, which used to contain a lot of important information about their clients, but all records seem to now only contain the text “Description”. In a panic, the admin pulls his car over and reaches for his laptop out of his bag. He opens up Salesforce and is dismayed that what he’d heard is true – he can’t believe his eyes! He calls his wife to let her know about the incident and tells her it’s likely to be a long night.
Shortly after 5 pm, the admin sees what went wrong. He discovered that there was a hidden column, “Description”, in the Excel spreadsheet. Someone had accidentally filled the entire column with the literal text “Description”, and our poor admin had extracted the CSV without seeing this column. His weekend was spent sifting through backups of their data to restore the Description values instead of relaxing like he had intended!
The moral of this story is to always perform a validation test of your data loads and remember to back up your org data in case something goes wrong.
2. The Spooky Single Admin Org
There was once a small business that had a relatively new Salesforce implementation and had started to really get the hang of all the basics – capturing and managing data, running reports, and building rudimentary automations to speed up workflows.
The admin was extremely dedicated to his craft, learning as quickly as he could about best practices and features he could enable to benefit his business. He built flows that captured data from multiple records to speed up his business processes, used Lightning pages to make sure people were seeing the information that mattered most to them front-and-center, and most importantly, he set up tight security for his org to ensure that its data was never at risk. He also made sure no one had too much access and especially kept a limit on the number of system administrators that were in the org.
One day, he went to log in to Salesforce and realized that his password had changed. He remembered that he’d set up a 90-day password policy and had recently changed it, so he assumed that he had simply forgotten to save his password in his password manager. Unfortunately, it wasn’t so simple. He attempted to reset his password but kept having issues with the password reset link and was eventually locked out of the system.
Meanwhile, his support tickets were piling up – people needed help within Salesforce, but he wasn’t able to reach them! He received call after call from the CEO asking why he wasn’t assisting the business, and he tried to explain that he had been unable to log into Salesforce due to his password issues. He asked if the CEO could quickly jump in and reset his password from the Setup menu, which is when the CEO reminded him that he had recently demoted him from a System Administrator role because he didn’t require it as part of his daily tasks.
You see, our system administrator had been a little too diligent in restricting the number of system administrators in the org. He was the last one left, and without access to the org, there was no one who could support the business within Salesforce!
The moral of this story is to keep a close eye on how many admin users you have – never just one, but never too many.
3. Pandora’s Sandbox
Have you ever had an idea that would benefit your business so much that you couldn’t sleep until you were able to build out an MVP and show someone? Nerd! Just kidding… but our next Salesforce Admin was exactly like that. She had an idea that she believed would save their entire marketing team hours every day, and she was excited to show them…
She woke up early one morning and decided she’d try to quickly throw together a proof of concept before driving to work for the day. She decided to quickly refresh the Full Copy Sandbox that her org was using, which she had scheduled to do later that day anyway. She figured it’d be okay to build the proof of concept in the Full Copy because of how much value it was going to bring to the business.
She excitedly built out the new functionality and prepared her demo to present to the marketing manager later that day. It functioned exactly as she had dreamed (literally) that it would and was bound to save the business a copious amount of time. This was exactly the outcome she was looking to provide for the business!
She eagerly packed up her laptop, jumped into her car, and raced to the office. She was so excited to show off her new tool that she skipped her regular coffee order and went straight into the office. She ran up to the boardroom with the marketing manager already sitting down – he’d arrived earlier than usual after receiving a frantic phone call from the admin early in the morning. Tripping over herself with excitement, our admin booted up her laptop, plugged in the screen, and opened up the login page. But almost immediately, there was a problem…
You see, in her excitement, our admin forgot to save her new password to her password manager. She checked to see if the browser had saved it just in case, but no cigar. She was locked out of the Full Copy Sandbox with her work trapped inside and no one in there to reset her password. Plus, being a Full Copy Sandbox, she had to wait almost a month before she could refresh the Full Copy again.
In this case, though, our admin is lucky. Once she’d gathered her thoughts she realized she could simply reset her password, but it certainly made her look silly for a second there!
The moral of this story is that you should be using a password manager first and consider using Sandbox Access Groups to make sure there’s more than one admin with access to the Sandbox in case someone loses access.
4. The Absent-Minded Automation Enthusiast
We all love an admin who loves Flow (and I’m not just saying that because that was me in my early Salesforce days – it’s true!), and that this is exactly what our next admin is. He spent his days either building flows for his business or learning more about building flows in Trailhead. He even bought and started studying the Ultimate Salesforce Flow Foundation Course!
Our admin fell in love at first Flow. Realizing the potential of this simple point-and-click automation tool, he started creating automations for everything. If the stage on an opportunity changed, he had an email sent out and a Date field on the opportunity populated. If someone closed a case, he had a task automatically created a month down the line to check in with the client. He built screen flows too, replacing the field sections on almost every object with a custom interface. He loved building flows!
One day, he noticed a significant uptick in the number of emails he was receiving from users about them being swamped in notifications and extra administrative work because of all the emails, tasks, and other notifications that they were receiving. He decided to sit down with department heads to get a better understanding of what was going on…
To his dismay, his Flow work wasn’t actually helping the business but hindering it. His creations were costing the business money because the sales team was slow to respond to leads, marketing couldn’t find the information they needed to plan for beneficial campaigns, and the service team was unable to sieve through the cases that actually needed attention due to the overwhelming number of cases and tasks being created for no reason at all.
You see, our admin got too excited about being able to do something that he forgot to question whether or not he actually should. His actions were costing the business time and money, and his new priority was to remove the unnecessary automation as quickly as possible.
The moral of this story is just because you can automate something doesn’t mean you always should.
5. The Curse of Rapid Evolution
This last story is one that will resonate with many of you, I have no doubt. Whether you’ll publicly admit it or not, we’ve all attempted to do what this next admin has done from time to time. And 90% of the time, it would’ve been a calculated risk with no repercussions, but this story shows that’s not always the case…
Our admin has been given a deadline to perform a small project. I say small; it was the biggest piece of work she’d been given to date, and she was stressed at the thought of not getting it all done in time. She knew the process – design, build, test, deploy – but was concerned that some of the work was taking too much time for what it was.
She decided that there were some work items that she could bypass this process and build straight in Production. A couple of reports and dashboards, some Lightning pages, and maybe a Flow or two shouldn’t cause too much of a headache. My dear reader, I’m sure you can see where this story is about to take a turn.
Everything seemed okay at first, with the pages displaying correctly as a number of different users and the reports and dashboards appearing as they should. Even the flows seemed to work as expected, but that was only for the rushed test cases that she had come up with as she built. Little did she know that as she was powering through the rest of the requirements in the Sandbox, little gremlins were running amuck behind the scenes…
One of the small Record-Triggered Flows that our admin had built wasn’t functioning as expected without a Date field being populated, which happened far more frequently than she anticipated. All the mission-critical functionality she had built was failing to execute because of this Date field, resulting in no notifications to business users about urgent tasks they needed to complete. By the time she realized it, it was too late, and the customer complaints had started rolling in.
The moral of this story is that you should always thoroughly test your new features before deploying them to Production. Oh, and of course, never build in Production!
Summary
You never know what’s hiding in the woodwork, ready to pounce. Technical debt sitting there, watching and waiting patiently, ready to strike when you least expect it. Good intentions leaving a sprinkling of misconfiguration lurking in the shadows and waiting for the right moment to wreak havoc upon your Salesforce org…
Let these stories be a lesson to every Salesforce enthusiast out there – a series of cautionary tales that serve as a reminder of what not to do if you want to keep your org free from spooky mishaps. I hope you’ve learned some lessons from our poor victims today. Don’t become the focus of next year’s spooooky Salesforce stories!