Entering the Salesforce ecosystem can be a daunting yet exciting experience. Just over a year ago, I joined Giveclarity as a trainee technical consultant. After three months of training, I delved into the dynamic world of consulting. As a new member of the technical team, I engage in all sorts of tasks, from working on support cases to writing and testing code to deliver efficient solutions to our clients. To say that this has been a learning experience would be something of an understatement. It’s been educational, challenging, enjoyable, and a great step in my fledgling Salesforce career.
In this blog post, I will describe my schedule for a recent day of work. It almost goes without saying, but I’ll mention it anyways: no two days are exactly the same. Still, what follows is fairly representative of what I do on a day-to-day basis.
A Typical Day
9:00am – Log on and check email
I fire up my laptop and take a quick look at my email and Teams messages to see if I need to respond to anything immediately. Truthfully, it’s rare that I start the day with anything so urgent. Today confirms this observation – all looks good, so I make a cup of tea, roll up my sleeves, and open up Visual Studio Code.
9:30am – Review Lightning Web Component and batch class
This morning, I am working on a batch class and a Lightning Web Component for one of our clients. I’m nearing the end of these tickets, so my focus is testing the functionality. I’ve written some Apex tests, so I run these. I also perform manual tests in a sandbox.
10:00am – Stand-up call
Next, I join a Teams call to check in with my line manager and the other technical consultants from our office. These calls allow us to discuss the work we are doing. I find that they give structure to my day; they also keep me aware of what everyone else is working on, which can be useful if we are working on similar projects/types of work.
10:30am – Alignment call with lead functional consultant
For the past four months, I’ve been working on a new Salesforce implementation for a large charity. Each week, I have an alignment call with the lead functional consultant on the project. He has been extremely helpful in helping me to understand the full lifecycle of a project. He has also worked for the company for many years, so I have learnt loads from his depth and breadth of experience.
Since we are approaching the end of our third sprint, we discuss a few loose ends that we need to tie up, including writing test scripts for the client.
11:00am – Weekly client call
Context switching is something that I struggle with at times, so I’m grateful that my next meeting is our weekly call with the client whom the lead functional consultant and I were discussing in the previous meeting.
We discuss the progress that we’ve made over the past week, as well as any blockers we face. We also look at the current sprint in JIRA and have a quick preview of what’s to come.
11:30am – Writing test scripts
Next, I need to write the test scripts that I mentioned earlier so that the client can perform user testing for this sprint.
Writing test scripts is an interesting exercise because it requires me to break down functionality into its most basic steps. Skipping one of these steps or making assumptions might save time in the short term, but doing so can complicate the testing when it is performed. Accordingly, I try to write as unambiguously as possible.
Today I am writing scripts on payment processing. I have a few testing documents from older projects that I use as guidance. Then I go through each payment processing ticket and write a description of the test, steps to execute, and the expected results. It’s easy enough to fall into a flow while doing this. Before I know it, it’s time for a break and some lunch.
1:00pm – Lunch/break
I log off and have a sandwich, then go for a walk outside. Mercifully, it’s not raining!
2:00pm – Call with a client regarding a new API
Last week, one of our clients raised a case with us to investigate a new API that appears to hold more reliable data than the one they currently use.
Yesterday, I messed around with the API in Postman to see how it works and came up with a high-level approach for this work. During the call, the client reviews what information they are hoping to access from the API. Then I show the test callouts that I’ve made, and we discuss potential drawbacks that switching to this API might cause.
At the end of the call, I make some notes and send an email to the support team at the API with some questions.
3:00pm – Session on Data Cloud
Periodically, we have company-wide meetings on various topics, both Salesforce-related and otherwise.
Today, one of our colleagues is presenting on Salesforce Data Cloud. The session is engaging, informative, and delivered impressively. I learn a lot in the process, since I was largely ignorant of Data Cloud before the session.
4:30pm – Review Lightning Web Component and batch class, part two
I have 90 minutes or so left, so I turn back to the work that I started the day with. More testing, and I am rewarded for my persistence, as I find a minor change that I need to make in my Lightning Web Component.
5:30pm – Log time, plan for tomorrow, and log off!
That’s all, folks! I log my time for the day and briefly glimpse at my schedule for tomorrow. I have fewer meetings, which means I’ll be able to dedicate chunks of time to some outstanding tickets.
I’m far from an expert in the Salesforce world, but I have gleaned a few practical tips since starting. To conclude, I will share them here, with the hope that they might help anyone early on in their Salesforce journey:
1. Documentation is your friend
If you’re facing a challenging problem, take a look at the relevant Salesforce documentation. Other key ports of call when searching for answers include the Trailblazer Community and Salesforce Stack Exchange. Chances are that someone else at some point in time has had the same (or a similar) question. Use this to your advantage.
2. …but don’t be afraid to ask for help!
Admittedly, I find it difficult at times to know when to stop searching online for the answer to something. If I find that I’ve spent a reasonable amount of time trying to figure something out and am still coming up short, then I know it’s time to ask one of my peers and/or a more experienced colleague for help. When I do so, I try to identify the issue at hand and mention what I’ve tried to solve before asking if they can help.
3. Keep the bigger picture in mind
I love the feeling of being immersed in a problem and trying to solve it, but sometimes this means that I lose sight of why I’m doing what I’m doing. Taking a step back and talking through whatever I’m working on helps me develop a greater understanding of the bigger picture.
Sometimes this means I literally talk to myself aloud. Other times it means rereading the tickets that I’ve been assigned and seeing if they relate to any other existing tickets. Lastly, it can mean writing by hand or drawing diagrams – this is probably my preferred method of understanding a concept and breaking it down into its component parts.
And that’s it! Hopefully that gives you a better idea of what a standard day could look like for a new Salesforce coder. It’s important to remember that your day as a Salesforce professional could look different depending on your role and how much there is going on.