HARTMANN–RICO: sales and service processes integrated with back-office systems.

The challenge

In healthcare, the operational truth about a customer — products, orders, deliveries, invoices — lives in back-office systems, while the customer relationship lives in CRM. When the two are not integrated, the gap shows up as daily friction: sales prepares for a visit without a reliable picture of the account, service agents cannot see the status of an order they are being asked about, and the same data gets re-typed into two systems with predictable drift between them.

The industry raises the stakes. Healthcare customers — hospitals, pharmacies, distributors — expect accurate answers, and a regulated environment expects traceability. "The CRM says one thing, the ERP says another" is not an acceptable state; every swivel-chair workaround is both wasted time and a data-quality risk.

The engineering question underneath is data freshness. Not every field needs real-time synchronisation, and pretending it does produces integrations that are expensive to run and brittle under load. But batch-only replication leaves service agents answering today's question with yesterday's data. Deciding which data needs which freshness — and paying the integration cost only where it earns its keep — is where these projects are won or lost.

That is the industry backdrop. The published scope of our work with HARTMANN–RICO is specific: sales and service processes integrated with back-office systems, on Salesforce.

Our approach

Integration projects fail on assumptions, so discovery came first: mapping the processes, data and systems before touching a single object, the way we run every engagement. Part of that honesty is deciding what Salesforce should not do — the CRM should consume back-office truth, not attempt to replace the systems that own it. That boundary-setting follows the same logic as our framework in when to write Apex — and when to walk away.

Delivery was phased: design a clear architecture, then build config, code and integrations in tested increments, with the client in the loop every sprint. The senior engineers who scoped the platform built it, and the same discipline continues past go-live into run and optimisation — the model behind our managed services.

Adoption is treated as part of the architecture, not an afterthought. Sales and service processes are scoped and configured around how the teams actually work — the field visit, the incoming service call — rather than around the data model. A technically correct integration that people route around in practice delivers nothing, so screens, processes and integrations are designed together.

Architecture, at pattern level

We publish client architectures at pattern level only — enough to show the shape of the build without disclosing internals.

Process layer

Sales and service processes run on Salesforce core clouds: account and pipeline management on the sales side, case handling on the service side, with one shared view of the customer across both.

Data ownership

Each data domain has exactly one owner. Back-office systems remain the source of truth for products, orders and financial records; Salesforce owns customers, interactions and pipeline. Integration synchronises the views instead of duplicating the mastering — the single decision that prevents most CRM–ERP drift.

Integration patterns

The integration layer mixes two well-worn patterns by intent, the way we describe in our guide to Salesforce integration patterns: synchronous request-reply where a person is waiting on an answer, such as an agent checking current order status, and asynchronous propagation for updates flowing between systems, where retries and ordering matter more than latency.

Contract-first boundaries

Interfaces are specified as contracts before they are implemented, and translation happens at the boundary — so back-office internals never leak into the Salesforce data model, and a change on one side becomes a versioning conversation instead of a production surprise. The CRM consumes clean, stable views of back-office truth rather than mirroring another system's schema.

Resilience and observability

Interfaces are built to be secure, observable and resilient: failures land in visible error queues with retry rather than disappearing, and idempotent processing means a replayed message never creates a duplicate. An integration a business runs on has to fail loudly and recover quietly — this is the standard we hold every interface to in our integration work.

Outcome

We do not publish client metrics without agreement, so the outcome here is stated qualitatively: the published scope — sales and service processes integrated with back-office systems — means customer-facing teams work in one system with back-office context in view, instead of swivelling between applications and re-keying data across them. Data flows over governed, observable interfaces with clear ownership on each side, which is what keeps that single view trustworthy over time.

Related reading