Ever wondered what Salesforce Solution Architects get up to in their day-to-day jobs? Typically, no two days are ever the same and this will vary depending on the type of projects you are assigned!
In this article, I will share a ‘day in the life’ – I’m writing this as a solution architect where the majority of my experience is working for a Salesforce consulting partner. Your typical day may look different if you work elsewhere, for example, at an end user (a company that’s a customer of Salesforce).
What Does a Salesforce Solution Architect Do?
A solution architect ‘deals’ solutions. You are typically the face/voice of a project and often find yourself in meetings with c-level executives as the technical driver of a project.
You’ll use your exposure to a range of Salesforce ‘cloud’ products to orchestrate how these come together to deliver a unified customer experience.
Whether you are meeting with colleagues, customers, or prospects, you’ll preach ‘Salesforce Best Practices’ and consider how to make solutions scalable and sustainable.
You’ll often ask yourself the following questions:
Traditionally, you had Application Architect, System Architect, and Technical Architect paths. The B2B Solution Architect and B2C Solution Architect are offshoots of these, with some certifications appearing on multiple paths.
Application Architect | System Architect | B2B Solution Architect | B2C Solution Architect | |
---|---|---|---|---|
Integration Architect | Y | Y | ||
Platform App Builder | Y | Y | Y | |
Data Architect | Y | Y | Y | |
Sharing and Visibility Architect | Y | Y | ||
Platform Developer I | Y | Y | Y | |
B2B Solution Architect | Y | |||
B2C Solution Architect | Y | |||
Development Lifecycle and Deployment Architect | Y | |||
Identity and Access Management Architect | Y |
Daily Routine
Join me on a fictitious day while I work on projects for the following companies: SaleSale, Sectore, and Metrol. Typically, I’ll have three or four projects at a time, and I’ll play slightly different roles depending on the project team. Again, these companies are fictitious and some scenarios have been fictionalized too.
9am-10am: Scrum Time
A typical day starts with a scrum for each project. During this time, I catch up on emails or Slack messages to ensure my customers and the team have the support they need.
10am-11am: Documentation Time
For this fictitious day, I’ve bookmarked some time to focus on documentation. This could be a low/high-level design, an entity relationship diagram, user stories, or something else entirely!
11am-12pm: User Story Playback
The time has come to lead a playback of user stories for SaleSale, a Sales Cloud project, with Account Engagement and an integration. This session will be with the marketing team, so I’ll focus on the Account Engagement stories to make sure the requirements are correctly defined, prioritized, and included within the Statement of Work (SoW) for the current project phase.
12pm-1pm: Lunch
In order to recharge before my afternoon, I’ll take a well-deserved break where I have something to eat and put my feet up. This may involve watching some TV to switch off for a little while.
1pm-2pm: Technical Review
It’s time to catch up with a fellow architect at Metrol. We will debate stories marked for review, discuss potential solutions, and consider how to deliver a scalable solution – all while ensuring we are not creating technical debt for ourselves in the long-term. Here, it helps to be up to date on new features that could be utilized instead of building your own custom solution.
2pm-3pm: Integration Design
As a B2B solution architect, I will work alongside a system architect to map out the solution architecture diagram for SaleSale. Depending on what ‘type’ of architect you are (and your level of experience), you may be able to complete this type of task independently.
3pm-4pm: Demo
It’s demo time for Sectore where – in this case – I’ll be observing the consultant work through the Lead to Opportunity Process. During this call, I’ll be interjecting when they need support and I’ll make notes of any changes that need to be implemented.
4pm-5pm: Proof of Concept (POC) Time
During my earlier call with Metrol, I was asked to investigate the feasibility of a proposed solution. In this slot, I’ll dive into my dedicated developer sandbox to see what’s possible. This is deliberately separate from their deployment pipeline, but has a copy of their Experience Sites – I’ll need to test how I can open up record access.
Final Thoughts
Throughout my Salesforce career to date, I’ve been in the shoes of an admin, a consultant, a lead consultant, and I’ve now worked my way up to a solution architect role.
I spend a lot of my own time helping out the wider Trailblazer community, which means I’m always up to date on the latest news and able to share this with my customers. As well as giving back to the community, I’ll also ask for help or inspiration when I’m dealing with something new!
Being an architect comes with a certain maturity. As a senior member of the team, you’ll find yourself coaching peers and you’ll have honed your communication skills – not only will you be trusted by your customers, but you’ll also be able to deliver ‘bad’ news and deal with technical escalations too.
Other Resources
- Salesforce B2B Solution Architect Certification Guide & Tips
- Salesforce B2B vs. B2C Solution Architects
- What Is a Salesforce Solution Architect? Is It Right for Me?