Salesforce architecture and solution design

Salesforce architecture on the client side means designing the overall picture in the interest of the company: which clouds and products it needs, how the data model looks, how Salesforce works with ERP and other systems, and how decisions are documented. I have done this for global manufacturers, including the first worldwide Manufacturing Cloud rollout with CPQ, a product configurator and a customer portal. My role is independent from vendors and partners, which matters most when a partner proposes the next product.

Which clouds does the company really need?

Sales Cloud and Service Cloud are a given in almost every enterprise project. The interesting questions start with the add-ons:

• Field Service depends on the type of work, the locations and the duration of the jobs. The biggest benefit comes with many short jobs, where route and appointment optimisation clearly improves the numbers. With a few long projects, the benefit is much smaller. I wrote about the current mobile features in Field Service mobile with guided flows and voice.
• Experience Cloud fits customer-facing processes. Self-service portals save internal capacity, because customers find answers and submit requests themselves.
• Manufacturing Cloud only makes sense when its features match how the company actually sells. The fit has to be calculated in the ROI case, which I describe on the make-or-buy and licences page.

Why does the data model decide so much?

Every report, every automation and every AI use case depends on the data model. If accounts, products and contracts are modelled differently in each project, the problems show up years later in reports nobody trusts and in agents that give wrong answers. That is why I treat the data model as part of the architecture, including its relationships to ERP. My view on AI is the same: business value and data quality come first, as described in Agentforce: business value and data quality first.

What do I deliver?

The scope ranges from the target picture to the decision log to the data model. Each architecture decision gets a short entry with the options, the reasons and the consequences. That sounds like paperwork, but it is what lets a company change partners or people without losing the reasoning behind its system. Integration architecture is part of it, because Salesforce is never the only system; more on that under integration with ERP, middleware and telephony.

During implementation I stay on board as the architect. I review partner designs before they are built and keep the decision log current. When the build drifts away from the target picture, for example because a partner takes a shortcut that will be expensive later, I raise it early.

If you are planning a new Salesforce programme or want an independent view on an existing architecture, send me a message or read more about me.