Know Your Tools: The Nine Questions

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 6 of 7 in the chapter Thinking Like a Data Architect, the first chapter of the Data Architect course. Each module stands on its own. Previous: Build for Today. Plan for Tomorrow. Plan for Failure. · Next: The Data Architect in the Time of AI

The question this module answers: How do you evaluate any tool, including one you’ve never seen before?

Architects need judgment. But judgment without knowledge isn’t very useful. You still have to know your tools.

I’ve been teaching architects for years, and one framework I use is a set of questions you should be able to answer about every important tool or capability in your architecture. I originally taught eight questions. I’ve added a ninth. The technologies change, Salesforce changes, new products appear and old capabilities evolve, and AI is accelerating all of it. These questions keep working.

The Nine Questions

Whenever you’re learning or evaluating a technology, ask:

1. What is it?
2. Where is it used?
3. How do I use it?
4. What are my alternatives?
5. What are its strengths?
6. What are its weaknesses?
7. How do I explain it to developers, the business, and executives?
8. How is it maintained long term?
9. What does it cost, what licensing does it require, and what are its limits?

If you can answer all nine, you’re beginning to understand the tool like an architect. Notice what isn’t on the list: “Can I configure it?” That matters, but it’s only part of knowing the tool.

Click to enlarge

1. What Is It?

Start with the obvious question, because people skip it surprisingly often. We hear a product or feature name and immediately start discussing whether to use it. Slow down. What does it actually do? What problem was it designed to solve? Where does it sit in the architecture, and what isn’t it? An architect should be able to describe a technology without repeating the marketing description. If I can’t explain something in a few sentences, I probably don’t understand it well enough yet.

2. Where Is It Used?

Knowing what something does isn’t the same as knowing when it belongs in an architecture. What kinds of problems is it good at? What conditions make it appropriate, and what conditions should make me suspicious of it? This is the step from “I know this feature” to “I recognize the problem this feature solves,” and it’s a major one. You don’t want to walk around looking for places to use your favorite technology. You want to recognize problems and know which tools fit them.

3. How Do I Use It?

Yes, architects should understand implementation. You don’t have to build every component, but you should understand enough to know what you’re asking other people to build. Know how it’s configured, how a developer works with it, how data gets in and out, how it’s deployed and secured, and what it looks like in operation. I don’t want an architect designing around a technology they’ve only seen on a product slide. Get your hands dirty: build something, break something, see how it actually behaves. Architecture gets better when it’s grounded in reality.

4. What Are My Alternatives?

This might be the most important question on the list. If you know only one way to solve a problem, you don’t have an architecture decision; you have a default. Whenever someone proposes a technology, I want to know what else we could do. A different Salesforce capability? Something declarative, or code? Could the capability live outside Salesforce? Could we leave the data where it is instead of copying it, use an event instead of an API call, or avoid building anything at all? Alternatives create trade-offs, and trade-offs are the heart of architecture.

5. What Are Its Strengths?

Every tool exists for a reason. Understand what it’s really good at: what it makes easy, where it scales well, what complexity it removes, what problems it solves elegantly. Use technologies where their strengths line up with the problem. That sounds obvious, but it’s very easy to choose a tool because we already own it, the team knows it, it’s new, or somebody saw a demo. Those can be factors. They’re not the same thing as architectural fit.

6. What Are Its Weaknesses?

This is just as important. Every technology has weaknesses, every one. If someone can tell you only a technology’s strengths, you aren’t having an architecture discussion yet. What doesn’t it do well? Where does complexity appear, and what happens at scale? What operational burden and dependencies does it bring? What requirements push it out of its sweet spot? A weakness doesn’t always mean we shouldn’t use the technology. It means we need to know what we’re accepting. A trade-off you understand can be an architectural decision. A trade-off you don’t understand can become a surprise.

7. How Do I Explain It to Different Audiences?

This is one of the questions that separates technical knowledge from architectural skill. Can you explain the same technology to a developer, to the business and to an executive? Those shouldn’t be the same explanation. The developer needs the APIs, transaction behavior, security, failure handling and implementation patterns. The business cares about what it enables and how their process changes. The executive cares about cost, risk, time, organizational impact, and which options the decision keeps open or closes. You’re not changing the truth; you’re changing the level of abstraction. If the only way you can explain a technology is in the vocabulary of its documentation, keep working on your understanding.

8. How Is It Maintained Long Term?

Projects end. Systems don’t, or at least we hope they don’t. Someone has to own what we build after the project team leaves. That means knowing how it’s monitored, upgraded and troubleshot, who needs the skills to support it, how changes get deployed and tested, and what happens when the technology evolves or Salesforce changes something underneath us. Picture it three years from now. I’ve seen architectures that were very clever on launch day and miserable to operate afterward. That’s not success. Maintainability is part of architecture.

9. What Does It Cost, What Licensing Does It Require, and What Are Its Limits?

This is the question I added to the original eight, and today I think it’s impossible to leave out. A technology can be the perfect technical solution and still the wrong architectural one if the economics don’t work. Is it included in the licenses we have, or an add-on? Is it licensed by user, usage, consumption, storage or transactions? What happens to the cost as we scale?

Then there are limits, and every platform has them: API, storage, query, transaction, concurrency, throughput and licensing limits. Some are hard, some soft; some can be raised and some can’t; some don’t matter at our scale until we add another zero. You don’t have to memorize every Salesforce limit, and doing so would be a terrible use of your time. You need to know that the limits exist, which ones matter to your architecture, and when to go verify the current number. The numbers will change. The architectural question remains.

A Worked Example: Apex Sharing

Here’s one of my most common examples of the questions at work. We receive a requirement for complicated sharing, sharing that can’t be met with any of the owner-based or criteria-based sharing rules. That leads us to Apex sharing: code that writes the sharing records itself. So now we need to know what Apex sharing is, where it’s used, how to use it and the rest. It’s an escalation: Apex sharing is the alternative (question 4) for when the rules we need go beyond what owner- and criteria-based sharing can express.

Now its weaknesses (question 6). Say we have a customer community with 10 or 20 million members, and we use the Customer Community license, not Customer Community Plus. Those are high-volume users. They don’t have roles, and they don’t use the sharing model at all: their access comes from sharing sets and share groups, matched through their account and contact. There’s no share record for Apex to write for them, so Apex sharing doesn’t work for them. And the cost and licensing question (question 9) is what put us there: the license choice decided which sharing tools exist at all.

So just as Apex sharing was the alternative to owner- and criteria-based rules, you may run into a case where you need an alternative to Apex sharing. And there really aren’t any configuration-based options for complex sharing rules at that point. You end up making the object read-only and controlling access through Apex. That’s why you ask all nine questions before you choose, not after.

Don’t Memorize the Platform

This matters most when you’re learning Salesforce architecture. Don’t try to memorize Salesforce. You can’t: the platform is too large, and it changes too quickly. I’ve worked with Salesforce for a long time, and I’m still learning. That’s normal.

What I want you to develop is a framework for learning. When Salesforce releases a new capability tomorrow, I don’t need to have seen it before. I know what to ask: what is it, where does it fit, how do I use it, what else could I use, what’s it good at, where does it struggle, how do I explain it, how do I operate it, and what does it cost and where are the limits? Now I can start evaluating it. That’s much more valuable than memorizing another feature matrix.

Beyond the exam: AI makes the nine questions faster to answer, and easier to get wrong. Meet a technology you don’t know, and you can ask AI to explain it, compare three approaches, list its limits and common failure modes, or argue against using it. That’s a remarkable research assistant. But it can be wrong, out of date, or confidently mix up two similarly named products or editions. For anything that affects a decision, verify it: follow the source and check the current documentation, limits and licensing. Trust but verify (module 7).

Learn the Questions, Not Just the Answers

We’ll meet a lot of technologies in this course. I don’t want you collecting answers; I want you practicing the questions. When we talk about big objects, external data, Data 360, integration patterns, or an AI capability Salesforce releases six months after this chapter was written, ask the same nine questions.

The answers will change. The questions are durable. That’s what makes this an architecture framework rather than a study guide.

Know your tools: what they’re good at, what they’re bad at, what else you could use, what they cost and where they break. And know enough to explain the decision to the people who have to live with it. That’s how an architect learns technology.

What an Architect Decides Here

• Whether a tool fits the problem, judged on all nine questions, not only on whether it can be configured.
• What the alternatives are, and what the tool’s cost, licensing and limits mean at your scale.
• Who will maintain it, and how, three years from now.
• Which facts about the tool to verify before relying on them.

Explore

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (checked 2026-10-09; re-checked 2026-10-12): high-volume users (the External Apps, Customer Community, High Volume Customer Portal and Authenticated Website licenses) don’t have roles; their access comes from sharing sets and share groups; they can’t be included in owner-based sharing rules, and records they own can’t be shared manually.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-10-09; re-checked 2026-10-12): high-volume users (Customer Community, High Volume Customer Portal, Authenticated Website) don’t use the sharing model, because their licenses don’t support roles; access works by matching the user to the Account and Contact lookups, through sharing sets or share groups. The same page lists when Apex managed sharing is the right tool.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), Trailblazer Community question, November 2024 (checked 2026-10-09; re-checked 2026-10-12): a practitioner reports that inserting share records for high-volume users failed with an error. A field report, not official documentation. (The online Trailblazer Community becomes read-only on 30 October 2026; the link may change.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (checked 2026-10-09): a sharing set grants access to records related to the user’s account or contact.