10 Tips for Salesforce Architects (and Everyone Else) to Supercharge Their Career

What if you could supercharge your career in 21 minutes by learning how to make better decisions, deliver solutions with maximum business impact, and communicate even your most complex ideas to any audience? Whether you are an architect, developer, consultant, or admin these 10 practical tips on decision-making, business alignment, problem-solving, and storytelling will show you how.

Not convinced? Give this a read, and I’ll prove you wrong. Short on time? No worries – either make a little time now or bookmark it for later. Chances are, you’ll want to save it anyway – these frameworks and checklists are go-to reference guides. Let’s jump in!

I recently published my book ‘The Software Architect’s Edge‘, packed with hundreds of practical tips, insights, and tools to help you supercharge your career. This 4,000-word article delivers real value and stands on its own – loaded with real-world scenarios, checklists, and action steps for each tip to help you make an impact. Make sure to check it out!

1. Master Your Mental Models

Mental models are frameworks or patterns your brain uses to understand and interpret the world. Think of them as your personal “operating system” for processing information and making decisions. As a Salesforce architect, your mental models shape how you approach problems, evaluate solutions, and make architectural choices.

Understanding how you think about architectural challenges is crucial in the Salesforce ecosystem. When faced with a complex multi-cloud implementation or integration challenge, your mental models determine your approach. If you want to make better decisions and deliver better outcomes, start mapping out your decision patterns. Here’s a structured self-reflection framework.

Technical Approach

Firstly, let’s consider your technical approach; ask yourself:

• Do you consciously examine your assumptions?
• Do you default to custom code when declarative options might work better? Or do you avoid code or more complicated solutions due to a lack of knowledge or general preference?
• Do you have a tendency to over-simplify or over-complicate?

Impact Analysis

How do your decision-making processes influence outcomes? Ask yourself:

• Do you consider scalability before functionality? What other considerations do you factor in?
• Do you consider the change’s impact on users, processes, and systems? How much do you weigh it in?
• Do you consider the relevant time horizon for your solution and if so how long in the future are you projecting?

Decision-Making Style

Lastly, reflect on your own decision-making style:

• Do you fall into analysis paralysis and get lost in details or can’t make a decision? (see tip 10)
• Do you have a clear mental image and understanding of the solution? What is missing?
• Do you weigh the pros and cons both technical and business-wise?

Consider how different mental models impact real decisions. When architecting a CPQ solution, you have several options: Native Salesforce functionality with minimal configuration, a custom solution built on native features, or a full CPQ application. What’s the “right” solution in this situation?

The answer depends on numerous factors, but using the decision-patterns checklist can inform your choice and critically examine it – try it with the CPQ example above or with one of your projects.

For instance, if the Sales process is likely to change within the next 6-12 months (time horizon) to reach maturity, a simple solution might be the best choice, especially if the Sales team is already using Opportunities (change impact and UX).

Another important factor in decision-making is cognitive biases – mental shortcuts that nature decided were an effective way to preserve energy (after all, the human brain consumes 20% of our energy). While there are over 180 biases, let’s look at two critical ones for architects.

1. Confirmation Bias: The tendency to search for, interpret, and favor information that confirms your prior beliefs. If you decide CPQ is the best option because complex pricing was mentioned in an early requirement, you’ll likely interpret all other requirements to fit your belief, potentially missing better solutions.
2. Anchoring Bias: The tendency to rely too heavily on the first piece of information received. For example, if the first requirement you hear is “We need custom code for this,” you might anchor to that solution even when powerful declarative options emerge during discovery.

A key action step to take would be to document your decision-making process for your next three architectural decisions. For each decision:

• Note your initial instinct and possible biases.
• Run through the structured self-reflection questions.
• Look for patterns and potential blind spots in your thinking.

Remember that the goal isn’t to eliminate biases (that’s impossible), but to be aware of them and your mental models, accounting for them in your decision-making process.

2. Align Architecture with Business Value

In the Salesforce ecosystem, it’s easy to get caught up in the excitement of technical capabilities – Lightning Web Components, Flow Orchestrations, Einstein features, or the latest platform innovations. However, the most successful architects understand that every architectural decision must directly connect to business outcomes.

Ask yourself these five questions before diving into any solution:

1. What specific business problem are we solving?
2. What is its root cause?
3. How will we measure success?
4. What’s the expected return on investment?
5. Are there simpler ways to achieve the same business outcome?

Consider this common scenario: A business is looking to implement an AI agent to reduce workload for the customer service team. But is the workload the actual problem? If you dig a bit deeper to find what’s causing the problem, you might learn that:

• 20% of the inquiries are related to changes to orders or status checks.
• 25% are product setup or configuration issues.
• 20% are billing-related questions.

So what then? The next steps are improving the order status communication through automations, updating the unclear production documentation, providing in-app help, and simplifying the billing process. This will help to reduce the workload by addressing the root causes without a consumption-based agent while generating a higher ROI.

I’m not trying to say that an agent doesn’t have a place in this solution – but remember when your only tool is a hammer, every problem looks like a nail.

Common pitfalls to avoid:

1. Solution Jumping: Leaping to technical solutions before understanding business needs.
2. Feature Fascination: Implementing exciting features without clear business justification.

Key action steps to take:

• For your current project, identify three specific business KPIs your solution will impact.
• Map each major technical decision to specific business outcomes.
• Practice explaining technical choices in business terms: Instead of: “We’ll implement a master-detail relationship” Say: “This will ensure accurate revenue reporting and streamline data maintenance”.

The most elegant technical solution that doesn’t deliver business value is ultimately a failed architecture. Your role is to drive business success through technology.

3. Navigate Multiple Levels of Abstraction

The ability to move seamlessly between high-level strategy and technical detail is a critical skill for Salesforce architects. Think of it as having a mental “zoom lens” that lets you adjust your focus from broad business strategy to specific technical implementation details.

The three key levels you need to master are:

1. Strategic Level: Digital transformation, business outcomes, long-term vision, etc.
2. Solution Level: Functional requirements, user experience, process design, etc.
3. Technical Level: Implementation details, integrations, security model, etc.

For example, when designing a Service Cloud implementation, you might need to:

• Discuss omnichannel strategy with executives (strategic).
• Map out case-handling processes with managers (solution).
• Configure case assignment rules and queues with admins (technical).

Let’s use a real-world scenario. During a steering committee meeting, an executive asks about case resolution times. A skilled architect can:

• Start with the strategic impact: “This affects customer satisfaction and support costs”.
• Move to solution approach: “We’re streamlining the case routing process”.
• Dive into specifics when needed: “We’re implementing custom assignment rules and SLA automation”.

Common pitfalls to avoid:

1. Altitude Lock: Getting stuck at one level, either too high (“everything is strategic”) or too low (“lost in the technical weeds”).
2. Context Switching Lag: Taking too long to adjust between levels during conversations or decision-making.

Key action steps to take:

• Create a multi-layer diagram for your current project showing:
  • Business strategy and expected outcomes
  • Solution components and processes
  • Technical implementation details
• Practice switching between these levels in your communications.
• For each major decision, document the implications at all three levels.

Your value as an architect comes not just from understanding each level, but from being able to connect them coherently for different audiences.

4. Decompose Complex Problems Systematically

Large Salesforce implementations can be overwhelming. A single project might involve multiple clouds, complex integrations, data migration, and organizational change. The key to managing this complexity is systematic decomposition – breaking large problems into manageable, well-defined components.

Think of decomposition as building with blocks:

• First, establish your foundation (boundaries and constraints).
• Sort your blocks by type (related components).
• Build block by block (logical work streams).
• Connect the blocks (integration points).

Consider this real-world example – implementing Salesforce CPQ for a global manufacturing company:

Instead of tackling it as one massive project, break it down into building blocks and their components:

• Data Model: Products, pricing, configurations.
• Business Logic: Pricing rules, approval workflows.
• Integration: ERP system, manufacturing systems.
• User Experience: Quote generation, product selection.
• Channels: Web, Mobile, Community.
• Platform: SSO, Territories, Notification Engine.
• Change Management: Training, documentation.
• Governance: Data quality, system maintenance.

Do these building blocks look familiar? You’ll likely encounter these same fundamental blocks repeatedly across different projects, whether you’re implementing Service Cloud, Marketing Cloud, or a custom solution.

The beauty of this approach is you can apply it to the overall architecture and on an individual requirement level to think clearly through your solution.

The true art of architecture lies in recognizing these common patterns (which is where experience and practice come into play), logically grouping requirements into components right building blocks, and understanding how these blocks best fit together for your specific situation.

Common pitfalls to avoid:

1. Too Many Blocks: Breaking things down so much that you lose sight of the whole structure.
2. Under-Dividing: Keeping chunks too large to be effectively managed or delegated.

A systematic approach to decomposition:

1. Start with the end goal
2. Identify major components
3. Break each component into deliverable units
4. Define clear interfaces between components
5. Establish dependencies and sequence

Key action steps to take:

• Take your biggest current challenge and break it into 5-7 major components.
• For each component, identify:
  • Clear success criteria
  • Dependencies
  • Risks
  • Owner
• Create a visual map showing how the components connect.

Good decomposition makes complex problems manageable, improves team collaboration, and reduces risk. The goal is not to eliminate complexity but to make it manageable.

5. Master the Art of Architectural Trade-Offs

Every architectural decision involves trade-offs. In the Salesforce ecosystem, these trade-offs often have significant long-term implications for scalability, maintainability, and user adoption. The key is not to find perfect solutions (which rarely exist) but to make well-reasoned compromises based on your specific context.

Think of trade-offs as a balancing scale – each option comes with its own set of advantages and disadvantages. The specific context determines which factors are more important, and this balance can shift as requirements evolve. It’s rare to achieve perfect balance, and the goal should always be to find the optimal compromise.

Consider this common scenario – choosing an automation approach:

• Flow
  • Pros: Powerful, flexible, future-proof
  • Cons: More complex, requires more testing
• Apex Trigger
  • Pros: Most powerful, fine-grained control
  • Cons: Code maintenance, requires developers

The right choice depends on various factors, such as :

• Team capabilities
• Performance requirements
• Maintenance resources
• Timeline constraints
• Future scalability needs

Common pitfalls to avoid:

1. Analysis Paralysis: Spending too much time weighing options without deciding.
2. Snap Decisions: Making choices without properly evaluating trade-offs.

A systematic approach to evaluating trade-offs is:

1. Identify key decision criteria
2. Evaluate options against these criteria
3. Consider both short and long-term implications
4. Document your reasoning
5. Plan for potential future changes

Key action steps to consider:

• For your next major decision, create a decision matrix with:
  • All viable options
  • Key evaluation criteria
  • Weighted scores for each option
• Document your trade-off analysis including:
  • Options considered
  • Criteria used
  • Final decision rationale
  • Future considerations

The goal isn’t to find perfect solutions but to make informed decisions based on your specific context and constraints. Document your reasoning – it will help explain your choices and inform future decisions.

6. Architect for Evolution and Scale

In the Salesforce ecosystem, change is constant. With three major releases per year, evolving business requirements, and growing user needs, your architecture must be flexible enough to adapt. The key is to design solutions that embrace change rather than resist it.

Think of your architecture as a living system, the core structure must be stable yet flexible, components should be modular, and limit dependencies. Most importantly, change should be expected and planned, as evolution should be guided not forced.

As an architect, it’s important to remember these five common types of change:

1. Platform Updates: New features, deprecated functionality.
2. Business Evolution: Process changes, org restructuring.
3. Scale Requirements: User growth, data volume increase.
4. Integration Changes: New systems, API updates.
5. User Needs: New requirements, usability improvements.

Let’s use a real-world example of designing a Sales Process. Instead of hard-coding values in configuration and code, consider using dynamic settings that allow for adjustments without major rework.

But let’s be realistic – budget, time, and scope determine how much choice we have in making things flexible. So consider these four important questions:

1. What change might impact my solution?
2. What’s the changes’ impact?
3. What is the probability of the change?
4. What is the benefit/value of the solution vs. the cost of change down the line?

Imagine you choose a custom CPQ solution that only supports basic discounting. If the client later needs complex discounting rules (a possible change), implementing them would require hundreds of hours of refactoring – and with Salesforce’s hourly rates, that won’t be cheap (change impact).

Now, let’s say you can invest just 20 extra hours upfront to design the solution in a way that reduces future refactoring to only 30 hours instead of hundreds. Should you do it?

On paper, it seems like a great deal; you save 50 hours in the long run. But what if complex discounting is uncommon in their industry, and the likelihood of this change is only 10%? Suddenly, that extra effort might not be worth it.

Or, if you could use those 20 hours to automate other processes that deliver an immediate ROI, the decision becomes even less clear (value of the solution).

This is the kind of nuanced thinking that separates great architects from good ones – not just anticipating change, but weighing probability, impact, and opportunity cost to make informed decisions.

Common pitfalls to avoid:

1. Over-Engineering: Making everything flexible at the cost of complexity.
2. Rigid Design: Creating solutions that are too hard-coded or tightly coupled.

Key action steps to take:

• Review your current architecture:
  • Identify potential change points
  • Assess the flexibility of the current design
  • Document technical debt
• Create a change readiness checklist:
  • Configuration vs. Customization
  • Documentation requirements
  • Testing implications
  • Upgrade considerations

It is impossible to predict every possible change, but change is inevitable – anticipating it will allow your architecture to evolve gracefully and support long-term needs.

7. Craft Compelling Solution Narratives

As an architect, your solutions are only as good as your ability to communicate them. Technical excellence without effective storytelling often leads to misunderstandings, resistance, or poor adoption.

From experience coaching hundreds of seasoned Salesforce architects, storytelling is something that requires significant attention. Common explanations are too technical and not compelling, while too short (even single words) or overly lengthy overloaded with unnecessary details or aspects. Tip 7 will introduce you to a simple story structure for you to create a compelling narrative, while Tip 8 is all about clarity and precision.

Let’s demonstrate it with a requirement from one of FlowRepublic’s custom CTA scenarios – it’s simple yet complex enough to make it interesting:

“Sales users use the ERP’s Pricing Modeler, a tool built by internal IT, that allows them to model different pricing scenarios for their proposals. Users manually enter product information from the proposal, that the tool uses together with manufacturing data and material cost to suggest different pricing options for the proposal. In the future users should be able to model prices directly from the proposal without leaving the system, but due to major dependencies the calculation logic must remain in the ERP.”

So how do you explain your solution?

Too often, we hear solutions described as “we’ll use an LWC” or “we’ll make an Apex callout.” These technical statements fail to convey the business value or user impact of the solution. Instead, use this simple three-part framework to create compelling solution narratives:

1. In order to (the requirement):

State the business need and key constraints, and focus on what needs to be achieved rather than how.

Example:

In order to let sales users calculate prices without leaving Salesforce while maintaining our complex pricing logic in the ERP, we need a solution that integrates seamlessly without unnecessary duplication.

2. I suggest (the solution):

Describe the solution from the user’s perspective, focusing on the experience rather than technical details unless necessary.

Example:

I suggest building a pricing calculator directly in the Opportunity or Proposal page, allowing users to input pricing parameters and receive real-time calculations from the ERP system. This ensures a business-centric approach.

Technically, this is implemented via an LWC that takes user input and makes REST API callouts to the ERP – but the end user only sees a seamless pricing experience.

3. Because (justification):

Decisions should be driven by measurable business benefits – reducing errors, saving time, and improving efficiency.

Example:

This approach will enhance user experience and cut quote creation time by 50%, directly impacting efficiency and sales velocity.

Key action steps to take:

1. Take the current solution you’re working on.
2. Write it out using the three-part framework.
3. Remove any unnecessary technical details.
4. Add specific, measurable benefits.
5. Test it with a non-technical stakeholder.

Let’s take a look at another example:

“Sales users use the ERP’s Pricing Modeler, a tool built by internal IT, that allows them to model different pricing scenarios for their proposals. Users manually enter product information from the proposal, that the tool uses together with manufacturing data and material cost to suggest different pricing options for the proposal. In the future users should be able to model prices directly from the proposal without leaving the system, but due to major dependencies the calculation logic must remain in the ERP.”

For this case, let’s assume IT can provide an API for the tool and we use an LWC for the UI.

How do you explain your solution?

How about “We use LWC to model prices” or “We do an Apex callout”? Remember a good technical story should combine context, plot, characters, and narrative.

Sounds complicated, right? But there’s a simpler way: using our three-element structure from before that works like a charm on a requirements scale and solution scale.

In order to (the requirement) let sales users calculate prices without leaving Salesforce while maintaining our complex pricing calculations in the ERP, I suggest (your solution with the user experience) creating an LWC that connects to the ERP’s pricing API. This allows users directly from the Opportunity or Proposal to enter pricing parameters and get real-time calculations, because (justification) it will create a better user experience and reduce quote creation time by 50%.

Now that you have a framework for structuring your solution narrative, let’s focus on how to communicate it effectively. After all, even the best story structure can fall flat if not delivered with clarity and impact.

8. Communicate with Precision and Impact

You’ve learned how to structure your solution story, now let’s focus on delivering it effectively. Even the best story structure can fall flat if not communicated with clarity and impact. I’ve noticed we tend to fall into two extremes:

Too Brief:

• “We’ll use a Lightning Web Component”
• “We need to make a callout”
• “It’s an integration”

This will most likely get you a blank stare from the audience.

Too Detailed:

“We’ll create a custom Lightning Web Component with a client-controller architecture pattern…”

Even just reading makes my brain spin!

So what is the right level of detail? Well, it depends on your audience, which typically fall into four categories:

• Executives: Focus on business outcomes and ROI
• Business Users: Emphasize daily benefits and process improvements
• Technical Teams: Detail implementation approach
• Project Sponsors: Highlight timeline, resources, and risks

Executives usually prefer to get right to the point – no fluff, and straight to the outcomes.

“We’re bringing the pricing calculation directly into Salesforce, reducing quote creation time by 50% while retaining the existing pricing logic.”

For business users, it’s best to discuss users experience and benefits:

“We’re creating a pricing calculator in Salesforce that connects to your ERP system. You can enter pricing parameters or we load them automatically and get calculations without switching systems, cutting quote creation time in half.”

A technical audience will want the focus to be on implementation details and rationale. This is a bit trickier, as we have many components coming together; UI, custom UI, integrations and business logic. I suggest developing talk tracks templates for how to describe each component and how they will interact. Here’s an example skeleton of a talk track.

[Location] + [Custom UI] + [Integration Details] + [Business Logic]

For project managers/sponsors, come with high level approach, focusing on time, resources, and risks:

“I suggest we build a custom that integrates with ERP’s pricing API. I estimate it will take x days and x FTE (full time employee) Salesforce developers and x FTE ERP integration architect. Given the custom development and integration work, there’s a risk of delays should we encounter X alone. I suggest we…”

The five principles for precise communication are:

1. Match detail level to audience
2. Lead with impact
3. Layer technical details as needed
4. Use clear, concrete terms
5. Focus on what matters to your audience

Common pitfalls to avoid:

1. Jargon Overload: Using technical terms with non-technical audiences.
2. Detail Flooding: Providing too much information too quickly.

Key action steps to take:

• Create 30-second, 2-minute, and 5-minute versions.
• Practice each version with appropriate audiences.
• Get feedback on clarity and impact.

9. Think On Your Feet

Think about the last time when you were put on the spot during a workshop or meeting because you didn’t have the answer to a challenging question at hand or your solution was wrong. Your brain goes into hypermode desperately trying to find a solution and you can’t think clearly – causing analysis paralysis.

So how do you overcome analysis paralysis and think on your feet under pressure? Simple.

STOP

• Pause the spiral of racing thoughts.
• Step back from the immediate pressure.
• Create mental space.

BREATHE

• Take a moment to center yourself.
• Slow down your racing mind.
• Reset your thinking.

THINK

• Repeat the question or define the actual problem.
• Collect your thoughts.
• Consider your options.
• Evaluate implications.
• Trust your instincts.

ACT

• Make a clear decision.
• Communicate confidently.
• Move forward.
• Adjust based on feedback.

Common pitfalls to avoid:

1. Rushing to Answer: Fear of silence leads to hasty, incorrect responses.
2. Overcomplexity: Making things more complicated when under pressure.

Key action steps to take:

• Practice using the framework in low-pressure situations.
• Get comfortable with brief silences while you think.

10. Build Your Learning Engine

We’ve covered a lot of ground in these tips – from mastering your mental models to communicating with impact. But perhaps the most important skill is learning how to learn and grow continuously as an architect.

The Salesforce ecosystem evolves rapidly – three releases per year, new features and buzzwords, and evolving best practices. Your ability to adapt and grow determines your long-term success. But it’s not just about keeping up with Salesforce; it’s about developing yourself as a Salesforce professional and as an architect.

Think about how the previous tips connect:

• Mental models shape how you approach problems.
• Business value alignment guides your decisions.
• Multiple levels of abstraction help you see the big picture.
• Building blocks help you break down complexity.
• Trade-offs inform your choices.
• Change-ready design future-proofs your solutions.
• Storytelling helps you communicate effectively.
• Precise communication ensures understanding.
• STOP-BREATH-THINK-ACT helps you handle challenges.

Now, build your personal learning engine through these five steps:

1. Reflect: Review your decisions and their outcomes.
2. Connect: Engage more frequently with the community and build together.
3. Practice: Use the action steps laid out in these tips.
4. Reflect: Consider your own thought processes.
5. Adapt: Adjust these tips based on what works for you.

Architecture is a journey, not a destination – keep learning, keep growing, and keep building!

Key action steps to take:

• Create a personal learning backlog.
• Schedule regular reflection time.
• Join architect community groups.
• Share your experiences with others.

The best architects never stop learning. What will you learn next?

The Salesforce ecosystem evolves rapidly. Successful architects create systematic ways to stay current. This goes beyond earning certificates – it’s about building a continuous learning habit.

For example, set aside time each week to explore new features in preview orgs, participate in architect community groups, and experiment with new tools in developer editions.

As a final action step, create a personal learning roadmap for the next quarter, including technical skills, soft skills, and business domain knowledge.

Final Thoughts

These tips are just the beginning of your journey to becoming an exceptional Salesforce architect. Each one can be expanded into deeper practices and habits. Remember, the goal isn’t to implement everything at once but to steadily enhance your architectural practice over time.