Installed Base Data in Salesforce, Zendesk and ERP Category: Software & Tools

A device-level service layer does not replace your ERP, CRM or helpdesk. The ERP keeps the commercial record, the CRM keeps the relationship, the helpdesk keeps the work, and the device layer keeps the unit: where it is now, what it runs, and what happened to it. In sqanit, the connection runs through three things: webhooks, an External ID on every ticket, and CSV import.

In most evaluations the first real question is what the software replaces, not what it does.

For a device-level service layer the answer is usually nothing. It sits next to systems you already run, and the value depends almost entirely on getting the boundaries right.

Who owns which truth

The most useful thing ayou can do before an integration project is write down, per field, which system is the master. One page. It prevents most of the arguments that come later.

The overlap that causes trouble is location. ERP knows where a device was shipped. That is not where it is. Devices move between departments, sites and customers. Whoever answers "where is it now" has to be the system that people update when they touch the device, not the invoicing process.

In every integration project we have done, the longest argument is about which system is allowed to say where a device is, and that argument is never technical. Once somebody writes it down per field, the rest is roughly a week of work.

Benedikt Biallowons, CTO

How sqanit connects

sqanit does not ship packaged connectors for Salesforce or Zendesk. It connects through three mechanisms that any integration partner or internal IT team can build on.

Webhooks. sqanit emits events, for example when a ticket is created or updated. A receiving system, or a middleware layer in between, picks them up and creates or updates the matching record on its side. This is how a case opened at the device can land in a Salesforce or Zendesk queue.

External ID on tickets. Every ticket has an External ID field that holds the identifier of the matching record in your CRM, ERP or ticketing system. It can be set manually when a case is handed over. It is what keeps the two records linked after the first hand-off.

CSV import and export. Customers, devices, codes, labels, roles, tasks and events can be imported and exported as CSV, and tickets can be imported too. Batch updates change many records at once, and notifications can be switched off for bulk runs, so a large import from your ERP does not flood anyone's inbox.

For product data specifically, we described one connection in detail in sqanit and Akeneo.

The four data flows worth building

ERP, one way in. Bring serial numbers, models, configurations and shipment records in. This is the cold start: it populates the installed base with what you have already sold. After go-live, new units come in the same way, by repeated CSV import.

CRM, one way in and one way out. Accounts and contacts in, so a device knows who operates it. Service activity out through webhooks, so the account team can see open issues before a renewal meeting. This is usually the flow with the clearest commercial payback and the one people build last.

Helpdesk, one way out. A case created at the device is sent on by webhook, already identified: which device, which model, which customer. The External ID ties the helpdesk ticket back to the sqanit ticket.

Product documents, one way in. Manuals and instructions, attached to the product model they belong to. What a technician does with those at the device is covered in the piece on document assistants.

Identifiers and standards

If you already work with GS1 identifiers, use them as the key across systems instead of inventing an internal one. The identifier your regulator, your customers and your labels already agree on is the cheapest join key available. Devices in sqanit carry GTIN and batch number fields for exactly that reason. sqanit is a GS1 Germany Solution Provider.

Where devices carry a UDI, the same argument applies with more force, as we cover in a separate piece on what a device identifier is worth beyond registration.

Five questions before the first data flows

1. Which system is master for location? Answer this one first, because it is the field that goes wrong if you do not.

2. What creates a device record? Shipment, installation or first scan are all defensible answers, but only one of them can be the rule.

3. What happens when a device is resold or moved? If the answer requires someone to remember to update a record, assume it will not happen.

4. Who resolves a conflict, and how is it visible? When two systems disagree about a configuration, somebody has to see that and decide. Silent overwrites will degrade your data without anyone noticing.

5. What is the smallest useful version? In most cases it is the ERP import in and the helpdesk hand-off out. CRM and documents can follow. Projects that try to build all four flows at once tend to go live late.

What you do not need to integrate

Your QMS, possibly. Regulatory document control has its own lifecycle and its own auditors, and a reference is often enough. Check the complaint, CAPA and vigilance hand-offs before deciding, because a service case can be the start of a complaint.

Your BI stack, at first. Reporting can wait until the data has been right for a quarter. Dashboards on top of a freshly loaded installed base mostly produce confident charts of wrong numbers.

HR and workforce systems. Technician skills and scheduling belong to whatever dispatches, not to the device layer.

A realistic timeline

For a device-level layer, six to twelve weeks to live is normal when the installed base data exists in usable form.

The data flows are rarely what takes the time. Most of it goes into reconciling what you actually have in the field, settling the ownership questions above, and physically marking devices. For how to evaluate the layer itself, see the buyer's guide.

Tell us what is in your stack and we will map the data flows with you. Book a technical call.