Most Salesforce professionals are already using AI. The question is whether it’s making them faster or better.

Speed can be useful. But when AI becomes a shortcut to implementation, it often accelerates the same pattern many professionals already follow. A requirement comes in, the default question is what to build, and delivery begins before the right problem is identified. The system grows more complex, and the gap between what was asked and what is actually needed stays invisible until something breaks.

As systems grow, issues show up that aren’t tied to how well something was built, but to how the problem was understood in the first place. Data no longer aligns across teams. Automations conflict. Integrations create friction instead of flow.

This is the domain of architectural design. The focus shifts from how you implement a requirement to understanding the intent behind it, the dependencies it introduces, and the constraints it needs to respect. How do your decisions influence the overall health of the system? How will this solution enable or constrain future requirements?

AI can support that shift, but only when you use it as a thinking partner rather than an answer engine. Use it to slow down, surface assumptions you didn’t know you were making, and pressure-test a design before you commit to it.

Use AI to change how you think, not just what you produce

Most of us use AI to go faster. You describe what you need, the LLM generates a viable response, and you move on. On the surface, this is a reasonable way to save time on routine tasks, but in reality it reinforces the same jump-to-solutions thinking that keeps you in builder mode.

A more valuable application is to use AI to think through a problem before you start solving it by bringing it into the analysis phase. Instead of using AI to generate a solution, ask it to challenge your framing, surface assumptions you haven’t considered, and evaluate what happens as your approach scales.

Consider this scenario: 

A business stakeholder asks you to automate an approval process for contract renewals. A builder-mode interaction with AI could look like this:

• “What’s the best way to automate a contract renewal approval process in Salesforce?”

This prompt will absolutely get you an answer, but it focuses on implementation. An architect-mode interaction starts earlier and sounds more like this:

• “What assumptions are we making about why this approval process needs to be automated?”
• “Is the issue the approval process itself, or is another aspect of the contract renewal lifecycle causing friction?”
• “What are the risks of automating the current process versus redesigning it first?”
• “How would each approach affect reporting, integrations, and future changes to the renewal workflow?”

These are two different approaches that lead to different design outcomes. One moves quickly toward implementation. The other starts by making sure you’ve identified the right problem.

In the second approach, you use AI to act as a counterpoint to your thinking.

Use context and memory to get more from AI

AI generates responses based on the training of the model you use and the context you provide. Without specific grounding in your org’s structure, constraints, and existing design decisions, the outputs default to generic best practices that likely won’t reflect your situation. The more specific you are about the system you’re working in, the constraints you’re operating under, and the tradeoffs you’re weighing, the more useful the conversation becomes.

Instead of asking AI to evaluate a design in isolation, give it the broader context. Describe the org structure, the existing automation landscape, the integration dependencies, and any governance constraints that are already in place. That context changes the conversation from generic best practices to analysis that’s actually grounded in your situation. 

There’s another dimension to consider. When AI understands how you think through problems, not just what you’re building, it can surface gaps in your analysis. If you consistently skip past data governance implications or underestimate integration complexity, AI with a well-configured context can start to challenge those patterns. Over time, it calibrates to how you think and where you’re most likely to miss something. This makes it a more effective thinking partner and strengthens your architectural judgment.

It also means taking advantage of memory features like projects. Projects let you build a persistent working context, so AI understands the particulars of what you’re building over time. Use that to store your org’s architectural standards, document decisions you’ve already made, and capture the constraints that shape design choices. Instead of re-explaining your environment at the start of every conversation, projects ensure that you pick up where you left off.

Apply AI-assisted structural thinking in your daily work

Use a consistent approach each time a requirement comes in. The five steps below use a contract renewal scenario to show what that looks like in practice.

Step 1: Expand the problem before solving it

The requirement is to automate an approval process for contract renewals. But when you expand it, you might find that the real problem is that renewals are being missed because ownership isn’t clear across business units or visibility into the pipeline is poor upstream. These are different problems that lead to different designs. Expanding the requirement before solving it helps you avoid building a solution that doesn’t address the underlying issue. 

If the expansion reveals that visibility is the root cause, the architectural implication is significant. Instead of designing an approval process, you may need to design a reporting layer or a pipeline review process first. That’s a different object model, a different set of users, and potentially a different part of the platform. Getting this wrong at the start means reworking your object model, your sharing design, and potentially your integration strategy after users are already in the system.

Example prompts:

• “Restate this requirement from the perspective of each business unit sharing the org.”
• “Which teams or profiles need visibility into renewal records, and are any of them currently excluded from the process?”
• “What does success look like for the sales rep versus the operations team managing the renewal queue?”

Step 2: Challenge assumptions

Every requirement carries assumptions. When they go unexamined, they tend to surface later as rework or design friction. In the renewal scenario, you might assume all business units follow the same approval workflow on the Contract or Opportunity object. If they don’t, a single flow handling renewals across business units with different criteria could create more friction than it eliminates. 

You might also assume the role hierarchy is structured consistently across teams. Native approval processes in Salesforce can route to the record owner’s manager based on the hierarchy. However, if a business unit has a flatter structure with no manager above them, the approval can get stuck with no approver assigned and no obvious error. 

If business units follow different approval workflows, the architectural response is to evaluate whether a single configurable process can accommodate that variation. If not, you may need separate processes per business unit with a shared data model underneath. That’s a governance decision, and it shapes data model flexibility for every business unit that comes after.

Example prompts:

• “What assumptions are we making about whether all business units follow the same approval workflow on the Opportunity or Contract object?”
• “What could be incorrect about assuming a single flow can handle renewal approvals across business units with different criteria?”
• “What risks emerge if record ownership varies across business units and the approval process depends on the owner’s role in the hierarchy?”

Step 3: Explore multiple design options

Defaulting to the first viable solution is a builder habit. Architects generate multiple options and compare them before committing to one. 

For contract renewals, this might mean comparing three options: a flow-based approval process, a native Salesforce approval process, and a queue-based model with escalation rules. Each one handles the business unit structure differently. 

A flow-based process gives you flexibility but will need to be modified as the number of business units grows. A native approval process is easier to maintain but can introduce role hierarchy dependencies if it routes to the record owner’s manager. A queue-based model sidesteps that dependency but requires a clear governance model: who owns the queue, who has access to it, and how approval assignments are managed across business units.

The right choice depends on the specifics of your org, including how frequently business units are added, how much variation exists across their processes, and how much administrative overhead your team can sustain. A queue-based model may fit an org with high process variation across business units. A well-structured flow may be the better choice where processes are consistent and the team has strong flow expertise.

Example prompts:

• “Explore three different ways to model a contract renewal approval process in Salesforce, and the key differences between each approach.”
• “What are the tradeoffs of each option in terms of reporting visibility, maintainability, and scalability as the number of business units grows?”
• “How would each option handle a future requirement to add a second approval stage for renewals above a certain contract value?”

Step 4: Analyze system impact

Every design decision affects more than the immediate requirement. In the contract renewal scenario, start with existing automation. If the Contract object already has a record-triggered flow that fires on status change, and your approval process also updates that same status field when approved or rejected, this can create a circular dependency. The approval updates the status, which retriggers the flow, which may reset fields or fire notifications that conflict with where the record is in the approval cycle. 

Flow Trigger Explorer can help by providing a consolidated view of all flows running on a given object and their order of execution. This analysis enables you to spot conflicts early.

Impact analysis also means looking downstream. If your org has an enterprise resource planning (ERP) integration that syncs contract data nightly, an approval process that updates the Contract record mid-cycle could create mismatched data between systems during the approval window. This is a sequencing risk worth documenting and exploring before the build phase.

Looking forward is equally important. If a future requirement adds a second approval stage for high-value renewals, your design needs to accommodate that without a rebuild. That’s what the Well-Architected Framework defines as composability: building solutions from functional units that can be extended rather than replaced.

System impact analysis can change both the option you choose and how you implement it. If the ERP sequencing risk is significant, it may shift your design toward one that decouples the approval status from the field the integration is reading. This decoupling protects data integrity across both systems when the approval cycle and the integration window don’t align.

Example prompts:

• “How would this approval design interact with existing record-triggered flows on the Contract object, and where could this introduce conflicting automation?”
• “What upstream or downstream dependencies could exist between the renewal process and the ERP integration syncing contract data to Salesforce?”
• “If we add a second approval stage for high-value renewals in a future release, what constraints could this introduce?”

Step 5: Make and document the decision

The goal is to arrive at a choice you can defend with evidence: what you evaluated, what you ruled out, and why the tradeoffs you accepted align with the long-term needs of the system. Then document your reasoning while the context is still fresh.

In the contract renewal scenario, that documentation might capture why you chose a queue-based model over a flow-based process, what you learned about the role hierarchy assumptions that ruled out the native approval process option, and why you intentionally deferred the ERP dependency to a later phase rather than trying to solve it now. 

This context disappears quickly once a project closes. Six months later, when a stakeholder asks why renewals work the way they do, that record is what keeps the conversation grounded in the original reasoning rather than speculation. It also helps prevent unnecessary changes driven by incomplete understanding of why the system was designed that way.

Documentation is a design artifact with lasting value beyond the project that produced it. A decision record that captures context, constraints, and tradeoffs gives the next architect working in that org a foundation to build on rather than a system to reverse engineer. For the next architect who inherits the org, the decision record also serves to contextually-ground their AI conversations. This helps ground your design in the Well-Architected Framework’s principle of trust: solutions must be understandable and governable by the people responsible for them over time.

Example prompts:

• “Summarize why a queue-based approval model was chosen over a flow-based process, referencing the business unit structure and role hierarchy dependency.”
• “What risks should be documented for the team inheriting this org, specifically around the deferred ERP integration and the existing record-triggered flow on the Contract object?”
• “Draft a plain-language explanation of this decision for a stakeholder who understands the business process but not the Salesforce data model.”

Rethinking how you use AI 

Start with step one of the approach outlined in this post on the next requirement that lands in your backlog. Bring the full context of your org, restate the problem from multiple angles, and see what the conversation surfaces before you build anything.

The same requirement, approached two different ways, produced two very different starting points. One moved straight to implementation. The other surfaced the real problem before anything got built.

Moving from a builder to an architect mentality means evolving how you’re using AI.