IoT data in the service portal: How machine builders make sensor data usable

Many machines have long been running their own telemetry platforms. Nevertheless, for every other service call, the dispatcher still calls an experienced colleague who “knows the machine.” The problem is rarely the sensor—it’s the gap between the data point and the service decision.

Sensor data alone does not resolve a service case. Only when vibration, temperature, operating hours, and fault codes are integrated into a system that also includes service history, contract data, and diagnostic knowledge does telemetry create a service context that dispatchers, technicians, and customers can actually work with. This article shows how machinery and equipment manufacturers can design the path from the sensor to the service portal so that every role sees the benefit—and how typical security, integration, and data sovereignty issues can be addressed.

When sensor data arrives—but doesn’t reach the service department

A typical scenario: A manufacturer of custom-built machines, with approximately 5,000 systems installed worldwide, has been operating an IoT platform for years. The machines report status, operating hours, and fault codes; the platform displays dashboards showing historical trends. However, little of this information reaches the service department. Service history is stored in the CRM, technical documentation is available as PDFs on SharePoint, and configuration changes are listed in an Excel spreadsheet. When a malfunction is reported, the dispatcher has to switch between three systems—and ends up calling a senior colleague who knows the system by heart anyway.

Head of service knows the consequences from his own experience:

• Triage takes longer because information has to be gathered from multiple sources.
• Technicians go out on a call with incomplete information and return without the correct spare part.
• The knowledge of experienced employees is lost as soon as they leave the company – new colleagues need months to make comparable decisions.
• Customers expect self-service access to the status of their systems, but only receive a link to the ticket form.

The problem is rarely the sensor itself. Most machines today provide enough data. What is missing is the ability to connect this data to the processes in which decisions are made about service cases.

From data point to service decision: the path through the layers

The path from the sensor to the dispatcher console runs in four layers – and today context is often lost at each of these layers.

Layer 1 – Sensor and Edge. Smart sensors measure vibration, temperature, current consumption, or pressure. Edge devices preprocess the data locally: they filter out noise, detect initial anomalies, and decide what data to send to the cloud. For a detailed description of this data flow, see our article “How to Implement Predictive Maintenance with IoT.”

Layer 2 – IoT platform. This is where the filtered data is consolidated. The platform displays trends, sends alerts, and provides interfaces for other systems. At this stage, the data quality is usually good. What’s missing is the link to the business context: Which specific machine is affected? Which maintenance contract applies? What is its service history?

Layer 3 – Service context. This layer is the most critical—and usually the weakest. In the Salesforce-based service backend, the asset object serves as the central reference point: machine, components, location, customer, contracts, tickets. If the IoT platform and the service backend do not communicate directly with each other, the dispatcher must manually bridge this gap—and that is precisely where delays occur.

Layer 4 – Roller surfaces. Scheduling, field service, and the customer portal all access the same service context, but each sees only what is relevant to its specific task. The technician does not see the scheduler’s dashboard, and the customer does not see the internal notes.

The central transition point is located between Layer 2 and Layer 3. Anyone who builds a seamless, bidirectional bridge here not only saves time during triage—they also lays the groundwork for every subsequent stage of service digitization.

Three usage perspectives in the service portal

As soon as IoT data and service context merge, the work for three roles changes in concrete terms.

For scheduling: faster and more informed triage. The scheduler can see the current machine status, recent service calls, active contracts, and suggested next steps all in a single view. Instead of opening three separate systems, the triage decision is made in Service Cloud—based on the specific piece of equipment, not an abstract platform ID.

For the technician: prepared on site. The technician accesses the service console on their mobile device: real-time sensor readings, the machine’s complete service history, recommendations for diagnosis, and context-sensitive instructions. logicline helped develop the Salesforce integration for Empolis Service Express, ensuring that diagnostic knowledge appears in a context-specific manner for the specific machine and does not result in an unstructured document search. Our article “Knowledge Management in Service” discusses how this knowledge base is methodically structured. If the on-site diagnosis is insufficient, the technician can escalate the issue to a remote specialist with a single click from the same console—logicline also helped develop the Salesforce integration for TeamViewer for this purpose.

For the customer: Transparency in self-service. In the customer portal, operators can view the status of their systems and upcoming maintenance appointments, and can submit support tickets or request spare parts on their own. Predictive notifications—such as “Maintenance recommended in 21 days”—appear directly here, rather than getting lost in the dashboard of a separate IoT platform.

These three views do not need their own data model. They access the same digital machine file – and only differ in terms of what is made visible for each role.

Requirements: Integration, Security, data sovereignty

The three issues that most frequently slow down any IoT in Service project can be categorized pragmatically.

Integration in existing buildings. It’s rare to start from scratch. Machines from different generations, ERP systems with legacy interfaces, older control systems without modern connectivity—all of this is part of the reality. A proven approach: Take stock of existing sensors and interfaces; modernize step by step using pilot systems; use standard protocols such as MQTT or OPC UA on the machine side; and implement a central integration layer to the Service Cloud. You can find a more detailed eight-step checklist in “8 Best Practices for IoT Asset Management.”

Security. Networked machines expand the attack surface. Three measures bear most of the burden: encryption of data transmission, multi-factor authentication at all access points and consistent separation of OT and IT networks. Added to this is an update discipline that actively maintains firmware versions instead of letting them run. If you would like to find out more about this aspect, you can find the details in our article IoT data in service portals: minimizing security risks.

Data sovereignty. Service data contains customer context and technical IP. Neither should inadvertently leave the manufacturer’s sphere of control. In practice, this means: regionally hosted platforms (such as Salesforce Hyperforce EU), clearly defined roles for data exports, and—when using AI—the option to run the model on your own infrastructure or with European providers. Data sovereignty is not merely a compliance issue, but an architectural decision that should be decided early on.

These three requirements are not end points, but permanent disciplines. If you plan for them pragmatically, you will avoid the most common dead end: a successful IoT pilot project that fails to scale due to one of these three hurdles.

Maturity: From Data Silo to Decision-Enabling Service Platform

A simple maturity model can be used to determine where IoT data ends up in the service portal. logicline uses a four-stage model that reflects the typical development process among machinery and equipment manufacturers.

Step 1 — Digitize. The installed base is mapped in a structured way: machines, components, configurations, contracts. A Digital Machine File replaces scattered Excel spreadsheets and PDF archives. This article explains why predictive maintenance in particular stands or falls on this data foundation Predictive Maintenance: Why the Data Foundation Decides on Success.

Step 2 — Connect. Sensor data, service history, and technical knowledge are seamlessly integrated. The IoT platform and Service Cloud work together bidirectionally, and knowledge sources such as Empolis are integrated in a context-aware manner. This article focuses on this level.

Step 3 — Decide. An intelligence layer built on top of interconnected data provides traceable recommendations for triage, diagnosis, and escalation. At logicline, this is Service Decision Intelligence (SDI)—a layer that connects fragmented service data from ERP, Salesforce, IoT, and documents, with source citation for every recommendation and operated on the customer’s infrastructure. A separate magazine article on SDI as the step from Level 2 to Level 3 can be found at “When Agentforce Hallucinates: Why AI in Service Needs Its Own Knowledge Base.”

Step 4 — Automate. Defined service work is carried out like software: routines run autonomously, people only intervene in escalation and exceptional cases.

Each stage builds on the previous one. Without structured data, there is nothing to connect; without connected data, intelligence cannot emerge across silos; without decision intelligence, automation is merely a technical shell. For most machinery and equipment manufacturers, the question “Where do we stand today?” is answered with “between Stage 1 and Stage 2”—and that is precisely where it is decided whether IoT investments will translate into service value.

Conclusion: The value lies in the ability to connect

IoT in service is no longer just a matter of sensor technology. The platforms are mature, the protocols are established, and the machines are delivering the data. What distinguishes an expensive telemetry project from a service that reduces triage times and ensures technicians arrive on-site with the right spare part is the ability to link the data to service context, roles, and decisions.

Three points carry the majority of the value:

1. A digital machine file as a reference object for each data point – otherwise telemetry values end up in a vacuum.
2. A connected Service Cloud where dispatchers, technicians, and customers all see the same information, filtered by role.
3. A pragmatic architectural decision regarding security and data sovereignty that is made early on and does not have to be renegotiated each time an issue escalates.

Those who implement these three building blocks lay the foundation that makes subsequent stages—decision intelligence and service work that scales like software—possible in the first place. Without them, any discussion of AI remains nothing more than an add-on built on an unstable foundation.

The obvious first step isn’t the next sensor pilot project, but an honest assessment of the current situation: How is the installed base structured today, and which data sources feed into which service processes? The Installed Base Assessment provides the foundation for exactly that—in 4–6 weeks, with clearly defined scope and a concrete report on areas for improvement. If you already have a structured base and want to specifically assess where the next integration step lies, schedule an introductory call right away.