When AI became the hottest topic in Salesforce, a lot of the conversation shifted toward prompts. How do you write a better prompt? How do you improve grounding? How do you reduce hallucinations?
Those are all good questions, but I think they’re often asked too late.
Before AI can answer a question, recommend a next step, or summarize a case, it first has to understand the world you’ve built. It doesn’t know your business. It only knows the representation of your business that exists inside Salesforce.
That’s your data model.
I like to think of it this way: your data model is your business’s worldview.
Your data model isn’t just a collection of objects and fields. It’s your representation of how the business works. Every object you create, every relationship you define, and every automation you build is another piece of that story. Together, they describe what exists in the business, how those things relate to one another, and why those relationships matter.
AI doesn’t create that worldview, it simply experiences the one you’ve built.
Good prompts certainly help. But they can’t compensate for a world that doesn’t make sense.
Modeling the Business, Not the Software
Clients almost never ask for a better data model. They ask for automation, AI, reports, or a better customer experience. The conversation usually starts with a feature, but somewhere along the way I find myself reaching for a whiteboard.
That’s because the first question isn’t “How should we build this?” It’s “What actually exists in this business?”
Let’s take a simple example.
Imagine we’re designing Salesforce for an HVAC company. A customer calls because their air conditioner stopped working. At first glance, this feels straightforward. We have a customer. We have a Case. That seems like enough.
Architect’s Sketch 01
There’s nothing wrong with that sketch. In fact, it’s probably where many implementations begin. But if we pause for a minute and ask one more question, the picture starts to change.
What actually broke?
Not the Case… the air conditioner.
That HVAC unit exists whether there’s an open Case today, tomorrow, or ever again. It’s part of the business regardless of whether someone has called support. That’s our first clue that we’ve discovered another business concept, not just another field.
Architect’s Sketch 02
I love this moment because it represents one of the biggest mindset shifts I’ve had as an architect. We didn’t add an Asset because Salesforce has an Asset object. We added it because the business has an asset.
Architecture doesn’t start with Salesforce. It starts with understanding the business well enough that Salesforce becomes a faithful representation of it.
Once we’ve modeled the equipment, another question naturally follows. Is the repair itself the same thing as the service request?
Probably not.
Someone answers the phone. Someone schedules the technician. Someone performs the repair. Those are related activities, but they aren’t the same business concept.
Architect’s Sketch 03
Without really noticing, we’ve stopped talking about Salesforce and started talking about the business. That’s exactly where I want architecture conversations to be.
I’ve found that’s how most good data models evolve. Rarely because someone knew the perfect design upfront, but because they kept asking one more good business question.
Architect’s Sketch 04
As we continue asking questions, more concepts emerge. How do we know whether the repair is covered under warranty? Where does the technician find troubleshooting guidance? Those aren’t just fields we need to add somewhere. They’re business concepts that deserve to exist on their own.
Behind the Sketch
If you’ve ever wondered why architects spend so much time talking about the data model (and making diagrams!), this is why.
At its core, Salesforce is a metadata-driven relational platform. Objects function much like database tables. Fields represent the attributes of those objects, and records are the individual rows of data.
If you’ve worked with relational databases before, this will probably sound familiar. If you haven’t, don’t worry. The important takeaway isn’t the database terminology. It’s that Salesforce is designed around connected information, not isolated records.
The real meaning of a Salesforce data model comes from the relationships between those objects.
Lookup relationships, master-detail relationships, and junction objects define how business entities connect to one another. They influence how users navigate information, how reports answer business questions, how automation flows through the system, how security behaves, and increasingly, how AI understands context.
Think about an Account record. By itself, it’s just an account. What makes it valuable is everything connected to it: Contacts, Opportunities, Cases, Assets, custom objects, and the countless relationships that tell the story of that customer.
A Salesforce org is less a collection of objects and more a connected network of business entities.
The objects tell you what exists.
The relationships tell you what those things mean.
Now imagine asking Agentforce:
“Has this customer experienced this issue before, and what should the technician know before arriving?”
The answer isn’t hidden inside the prompt. AI follows the relationships you’ve modeled. It moves from the customer to the Asset, from the Asset to previous Cases, from those Cases to completed Work Orders, from the warranty to the Entitlement, and from the issue to the relevant Knowledge Article.
The prompt didn’t become smarter.
It simply had a better world to explore.
Modeling the Form Instead
Now imagine a different implementation. Instead of modeling the business, we model the intake form.
Every piece of information lives directly on the Case. Customer name. Equipment model. Serial number. Warranty status. Installation date. Technician notes. Previous repair history. Twenty more fields.
The implementation works. The customer submits the request. The technician completes the repair. Nobody complains.
At least not at first.
Architect’s Sketch 05
At first glance, this design feels simpler. But look at what’s missing!
The HVAC unit no longer exists as its own business entity. It’s just text on a Case. The warranty no longer exists. It’s another field. Repair history isn’t connected across multiple visits. It’s scattered across individual records.
Neither your users nor your AI can easily understand the bigger picture because the bigger picture was never modeled.
The issue isn’t that one solution uses more standard objects than the other. The issue is that one models the business. The other models the form. Once you see that distinction, it’s hard to unsee it.
Architect’s Lens
One of the biggest shifts from implementation to architecture isn’t learning more Salesforce features. It’s learning to ask different questions.
Instead of asking, “Where should I put this field?” ask, “What business concept am I trying to represent?”
Instead of asking, “How do I automate this?” ask, “Does my data model accurately represent the business first?”
Those aren’t AI questions.
They’re architecture questions.
AI has simply made them impossible to ignore.
Architect’s Notebook
One lesson that’s stayed with me throughout my consulting career is that good architecture isn’t about blindly following Salesforce’s standard data model. It’s about understanding why that model exists in the first place.
I’ve worked with clients who simply couldn’t justify licensing products like Field Service. We still needed to represent service visits, technician assignments, and repair history, so we designed our own custom objects instead.
At first, that felt a little uncomfortable. As architects, we’re taught to reach for standard functionality whenever we can. But this client didn’t need Field Service. They needed a solution that faithfully represented their business within the constraints they had.
Those custom objects weren’t a compromise. They were the right solution for that client.
The reason they worked wasn’t because we recreated Salesforce feature for feature. It was because we preserved the underlying business concepts and the relationships between them. We asked ourselves, “If we aren’t using Work Orders, what does a work order actually represent in this business?” Then we modeled that concept.
Looking back, each project I work on changes how I think about architecture.
Good architecture isn’t about avoiding custom objects.
Good architecture isn’t about using every standard object.
It’s about making intentional decisions that faithfully represent the business you’re trying to support.
Back to Basics Challenge
This week, resist the temptation to start in Setup. Grab a whiteboard instead!
Pick one business process in your org and sketch it before you open Salesforce. Ask yourself:
- What actually exists in this business?
- Which things have their own lifecycle?
- Which things are simply events?
- Am I modeling the business or am I modeling the form?
You might be surprised how different your solution looks once you start thinking about the business before the technology.
And as AI becomes a bigger part of every Salesforce implementation, those sketches won’t just help your users.
They’ll help your AI understand your business.
Force For Fun 
0 comments on “Back to Basics: Modeling the Business, Not the Software”