A sales team analyzing its pipeline data on a laptop screen

Sales Cloud Integrator: Role, Scope and Selection Criteria

You have Sales Cloud. The licenses are paid for, the dashboards exist, the sales reps have had their training session. And yet Monday’s pipeline review still starts with the same question: “where does this figure come from?” Someone then opens a parallel spreadsheet, and the meeting turns into a referee session between two versions of reality.

This is not a licensing problem, nor a screen layout problem. It is a data problem: where the data comes from, whether it is unique, how fresh it is, and how much the teams trust it. It is also, very precisely, the job of a Sales Cloud integrator — a role often confused with that of a license reseller or a marketing agency, when it actually deals with a completely different risk.

Sales Cloud: what the platform brings, and what it does not solve on its own

Sales Cloud is Salesforce’s sales foundation: accounts, contacts, opportunities, forecasts, activities, and all the automation that connects them. It is a mature, extensible platform, capable of supporting complex, multi-country sales organizations.

What it does not do: decide which version of a customer is the reference when the ERP, the invoicing tool and the marketing database offer three. Nor guarantee that an opportunity amount matches what will actually be invoiced. Nor prevent the same account from existing four times because four sales reps created it with four spellings.

A CRM does not produce reliability: it exposes it. Well fed, it becomes the company’s reference. Poorly fed, it becomes the place where everyone notices that the figures do not add up — and then works around it.

Integrator, consultant, agency: who does what

Three professions meet on a Salesforce project, and the confusion is costly when it comes to choosing a partner.

  • The consultant works on usage: sales process, qualification method, forecasting rituals. They help you decide what the platform should reflect.
  • The agency works on what the CRM produces: campaigns, prospecting sequences, content, marketing reporting.
  • The Sales Cloud integrator works on what the CRM receives and redistributes: the data model, inbound and outbound flows, consistency with the ERP, invoicing, support and the data warehouse.

All three are useful, and often complementary. But only one deals with the risk that derails the largest number of deployments: a flawless platform sitting on data that no one believes.

Data reliability decides the fate of your Sales Cloud

The data model comes before the screens

At the start, the temptation is to begin with what can be seen: which fields on the opportunity record, which stages in the pipeline, which dashboard for management. It is pleasant, it can be shown in a meeting, and it is premature.

The real first workstream is less spectacular: defining the objects, their relationships, and above all the system of record for each piece of data. The customer exists in Sales Cloud and in the ERP — which one is the reference, and for which field? The billing address belongs to accounting, the operational contact to sales, the outstanding balance to finance. Writing this split down in black and white before configuring avoids years of case-by-case arbitration.

Duplicates, free-text fields and orphan data

Three defects come up in almost every audit we carry out.

Duplicates first: same account, two spellings, two owners, two histories. They skew the pipeline, double up follow-ups and make any forecast debatable. At Mirakl, our work focused precisely on synchronization between the CRMs in place and on reducing duplicates: without this foundation, no dashboard would have been credible.

Free-text fields next. A text field left open where a list of values was needed produces twenty ways of describing the same reality. No one notices at the start; everyone discovers it six months later, when the data has to be grouped.

Orphan data finally: data no one owns. A field that neither sales, nor finance, nor marketing claims is updated by no one. It becomes wrong, then ignored, then harmful — because it stays on screen and someone will eventually use it.

The four connections that really feed Sales Cloud

An isolated Sales Cloud degrades on its own. Four connections determine its real value.

With the ERP. Connecting Sales Cloud to your ERP — Odoo, NetSuite, Sage or a more specific system — lets sales reps see the status of an order, a backlog or an outstanding balance without leaving their CRM. Every time they leave the tool is a chance they will not come back.

With invoicing. A signed quote that triggers nothing downstream means one more re-entry and one more source of discrepancy. The projects that hold up are those where the step from quote to invoice is explicit: what triggers it, who validates it, how the margin flows back to the sales rep. At Orhatek, the CRM overhaul first served to structure this chain — sales, invoicing, margin management — rather than to change the interface.

With customer support. A sales rep who chases an unhappy customer without knowing that a ticket has been open for three weeks does more damage than a sales rep who does not chase at all. Connecting Freshdesk, Zendesk or Service Cloud gives each team the context of the other.

With the data warehouse. As soon as two tools produce the same indicator, meetings turn into debates about the source. The connection to the data layer settles this once and for all: one definition, one source, one figure. It is also what determines any later use of sales AI, Agentforce included — an assistant plugged into contradictory data produces contradictory answers.

The real scope of a Sales Cloud project

Audit and scoping

Mapping the existing setup, qualifying the real condition of the data, deciding the systems of record, defining the first phase. This is the most profitable phase, and the one most often cut short on the grounds that “the need is clear”. It produces a simple but decisive document: who owns which data, and what happens when a flow fails.

Build

Data model, configuration, migration and cleaning of history, integration flows, test sets, acceptance testing with real users rather than demo data. Migration deserves particular attention: migrating dirty history means paying to move the problem into a more expensive tool.

Support and adoption

Training, documentation of the flow map, skills transfer so that internal teams can evolve the configuration without depending on a third party. This is the phase that decides whether the CRM will still be used in two years.

Seven criteria for choosing your Sales Cloud integrator

  • It starts with your data, not with a demo. A partner who opens the relationship by showing screens has not yet looked at your real issue.
  • It knows how to say no to a scope. A systematic “everything is possible” signals postponed trade-offs, and therefore overruns.
  • It knows your neighboring systems. Sales Cloud alone is not enough: ask what it has already connected in terms of ERP, invoicing and data warehouse.
  • It documents. Flow map, systems of record, deduplication rules: anything not written down will be lost again at the first team change.
  • It plans for failures. A flow that fails without an alert creates silent discrepancies, discovered three months later at closing.
  • It trains your teams. Autonomy is not an end-of-project option, it is the criterion for success.
  • It shows verifiable references. Contexts close to yours, with contacts you can call.

The signs that you need an integrator

A few symptoms come up regularly, and they are fairly reliable:

  • Your sales reps keep a parallel file “for the real information”.
  • The same customer exists under several spellings in several tools.
  • No one can say, without checking, whether a figure comes from the CRM, the ERP or the management control spreadsheet.
  • Your automations run in Make or Zapier without anyone knowing what would break if they were stopped.
  • The monthly sales closing requires a day of manual reprocessing.

If you recognize three or more, your issue is probably not Sales Cloud. It is what feeds it.

Where to start

Rarely with a full-scale project. The right first step is a data and flow audit: measure the duplicate rate, identify the fields no one owns, spot the two or three connections that waste the most time, and tackle those first. The rest can wait — and usually waits very well.

If you want an outside perspective on your Sales Cloud configuration and on the quality of the data feeding it, let’s talk. You can also browse our CRM integration offer, our data expertise, or all the tools we integrate and operate.

the most common questions

What is the difference between a Sales Cloud integrator and a Salesforce consultant?

A Salesforce consultant works on usage: sales process, qualification method, forecasting rituals. They help you decide what the platform should reflect. A Sales Cloud integrator works on what the CRM receives and redistributes: the data model, flows with the ERP, invoicing, support and the data warehouse. The two professions are complementary, but they do not address the same risk.

Should you connect Sales Cloud to your ERP?

In the vast majority of cases, yes: it is the most profitable connection. Without it, a sales rep looking for an order status, a backlog or a customer’s outstanding balance has to leave the CRM, and every time they leave, adoption weakens. The issue is not technical: it is about deciding which data is the reference in which system, and in which direction it is copied.

How do you know whether your Sales Cloud data is reliable?

Three tests are often enough. Pick a customer account at random and check that it exists only once. Pick an executive committee indicator and ask two people where it comes from: if the answers differ, the source has not been settled. Finally, open ten closed opportunities and compare the amount with the amount actually invoiced. The discrepancies you find are your starting point.

Can you evolve Sales Cloud in-house after the project?

That is the goal to aim for. A CRM where every change goes through a provider ends up freezing, then being worked around. We therefore train internal teams to evolve the configuration and flows themselves, and we document the data map so that these changes remain safe.