I recently had an experience that I think many Salesforce Admins will find familiar. I was sent a request to make a change in Salesforce. By the time the change was finished and had gone live in Production, the client had forgotten about the request, and upon further thought, decided they didn’t want the change after all. I then had to remove what I had built.
In this case, it was a very small change. It was just a couple of picklists – no automation or integration, and nothing that would be extremely time-consuming to dismantle. But it was frustrating for me as the admin, to see something that I had created, exactly to specifications, be so quickly disregarded by the person who had requested it. After giving it some thought, I realized where I had gone wrong, and what could be learned from this situation. I’m sharing this story with you all today to hopefully save other admins from the same situation in the future.
Project Management
When it comes to being a Salesforce Admin, we spend a lot of time learning about the technical functionality of Salesforce; how to create fields, UI changes, Flows, data security models, integrations, maybe even code, etc.
But a huge portion of the job of being a Salesforce Admin is actually not technical – it’s the soft skills of project management. In fact, these skills are so important that even an exactly perfectly executed request can become a failure when the project management portion of the project fails.
You might be familiar with the thought experiment: “If a tree falls in the forest, and no one hears it, does it make a sound?” Of course, logically we know it does – the physics of a tree crashing to the ground are the same, whether someone is in hearing range or not. But that’s not the point of the question.
What it boils down to is this: If nobody knows a thing happened, did it happen? Or in Salesforce terms, if the client doesn’t believe you completed a task correctly, did you really complete it correctly?
Like the tree, you might know that you did complete it correctly. But keep in mind that completing the task correctly was only half of the project.
Communication
Knowing the best way to communicate with your client is imperative to a project’s success. This particular project was sort of a perfect storm of miscommunication.
Weekly meetings with clients are great, but during the winter season when there are a lot of holidays and people getting sick, it can be easy to have multiple meetings in a row canceled, and end up going much longer than expected without actually speaking to the client (which happened with this project).
Another miscommunication is that I myself did not realize I was communicating in a method that did not work for the client (because I had been so used to talking with them weekly on calls).
Imagine me sending email updates when the client really only uses Slack, or vice versa. My updates had been floating around unread, and I wrongly assumed that a lack of reply equaled a lack of objection. Silence does not equal acceptance.
In this case, I should have waited for a verbal or written go-ahead before proceeding with the go-live, even if that pushed the due date out further.
Live Demos
In the Salesforce Admin world, a couple of new picklists are not difficult to create, especially when those picklists have no dependencies, no integration, no validation, and no automation.
I assumed that a verbal explanation – along with some written documentation/user guide – would be sufficient to explain the change. In this case – depending on the client – this can be OK.
However, my lack of knowledge of the client’s preferred method of learning caused a lot of confusion for the client, and my updates and written documentation were going unread.
This particular client prefers live demos whenever possible, and recorded video when not. This is not a problem for me – I can create either or both as needed. The issue here was that I did not know their preferred method.
Because they had not seen the change live, they were not able to give it a second round of discussion, which turned out to be sorely needed.
Scoping
One of the hardest parts about being a consultant is that I do not actually work for the company. I’m not familiar with the company’s general culture or how individual teams operate.
Even working as a full-time administrator, I would often not have details about how particular teams completed their work on a day-to-day basis. In addition to me not knowing the details of what a team does on a daily basis, the person making the requests for me is likely just a go-between.
They may be the person fielding Salesforce requests and are likely neither a Salesforce expert nor at the job of the end user. Now we’ve got two layers of people with a lack of very detailed information on how a team works. This lack of knowledge can really cause problems when scoping a project.
Whenever possible, it’s best to speak directly to the end user to get a full picture of what they actually need in Salesforce. This ensures that no information gets lost in translation and that you as the administrator can provide the best possible solution. The best solution might even be different than what the original request was!
Future Proofing or “Scalability”
Having a good understanding of how this change will be utilized in the future is also a great way to predict future problems or needs. Knowing some basics of human behavior helps too. For example, Long text fields; they sound fine as a way to capture a lot of random text information on a record.
But keep in mind human behavior and preferences – no manager wants to read a dissertation-length text of 80+ records weekly, and even fewer people want to spend their days typing out that much data.
Fields like that tend to go stagnant or irritate users within a matter of days. Frustrating users is one surefire way to make them think an admin has failed – they might not know who or why you made something required, but they will certainly know you made the change and that often makes admins the target of much ire.
Asking a client how this change will be used in the future, perhaps if their company grows drastically, will help you to understand and recommend the best possible solution.
Prevention Is the Best Cure
When communication problems happen, they’re much more difficult to repair than a purely technical mistake. I’m a solid believer that communication and a good working relationship with the client are the best ways to ensure the success of a project.
Preventing communication problems is hard and requires a lot of work. It can be especially difficult when trying to communicate with people of different skill levels in Salesforce. Being clear and upfront about the tasks you must do – and what your expectations of the client are – will save you many headaches in the end.
Final Thoughts
In the situation I mentioned at the beginning of this article, we had sort of a perfect storm of miscommunication. A request that the client hadn’t fully thought out, an admin who knew it was a minor change and didn’t think much of it, a couple of skipped meetings for the holidays, and voilà; a perfect recipe for miscommunication.
I hope you can take this experience and learn from it in your own Salesforce Admin work. Being able to prevent issues like this before they happen will make you a better admin, and help your clients get the most out of your time and expertise.
