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 solve a service case. Only when vibration, temperature, operating hours and error codes end up in a system in which service history, contract data and diagnostic knowledge are also available does telemetry become a service context that dispatchers, technicians and customers can actually work with. This article shows how machine builders can design the path from the sensor to the service portal in such a way that every role sees the benefits – and how the typical security, integration and data sovereignty issues can be addressed.

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

A typical picture: a manufacturer of special machines with around 5,000 systems installed worldwide has been operating an IoT platform for years. The machines report status, operating hours and error codes; the platform displays dashboards with historical trends. Little of this reaches the service department. The service history is stored in the CRM, technical documentation is stored in PDFs on a SharePoint, and configuration changes are stored in an Excel spreadsheet. When a fault is reported, the dispatcher has to switch between three systems – and ends up calling the senior colleague who knows the system by heart.

Service managers know the consequences from their own experience:

• Triage takes longer because information has to be gathered from several sources.
• Technicians go to the job with an incomplete picture and come back 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, power consumption or pressure. Edge devices pre-process the data locally: They filter noise, detect initial anomalies and decide what to send up in the first place. You can find a detailed description of this data flow in our article How to implement predictive maintenance with IoT.

Layer 2 – IoT platform. This is where the filtered data comes together. The platform shows trends, sends alarms and provides interfaces for other systems. At this point, the quality of the data is usually good. What is missing is the link to the business context: Which machine exactly is affected? Which maintenance contract applies? What service history does it have?

Layer 3 – Service context. This layer is the decisive and usually the weakest. In the Salesforce-based service backend, the asset object becomes the central reference value: machine, components, location, customer, contracts, tickets. If the IoT platform and service backend do not talk to each other directly, the dispatcher has to build this bridge manually – and this is exactly where the delays occur.

Layer 4 – Roller surfaces. Dispatching, field service and the customer portal access the same service context, but only see what is relevant to their task. The technician does not see the dispatcher dashboard and the customer does not see the internal notes.

The central transition point is between layer 2 and layer 3. Building a clean, bidirectional bridge here not only saves time in triage – it also creates the conditions for every further 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 dispatcher sees the current machine status, the last service assignments, open contracts and suggested next steps in one view. Instead of opening three systems, the triage decision is made in the Service Cloud – with reference to the specific system, not the 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, diagnostic recommendations, 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 end up as 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 tickets or request replacement 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.

Prerequisites: 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. Rarely do you start on a greenfield site. Machines of different generations, ERP systems with grown interfaces, older control systems without modern connectivity – all this is part of reality. A proven sequence: inventory of existing sensors and interfaces, step-by-step modernization via pilot systems, standard protocols such as MQTT or OPC UA for the machine side, a central integration layer to the service cloud. You can find a more detailed checklist with eight steps 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 leave the manufacturer’s sphere of control unintentionally. In practical terms, this means regionally hosted platforms (such as Salesforce Hyperforce EU), clear roles for data exports and, when using AI, the option of operating the model on your own infrastructure or with European providers. Data sovereignty is not just a compliance issue, but an architectural decision that should be made 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 level: From data silo to decision-capable service platform

A simple maturity model shows where IoT data ends up in the service portal. logicline works with a four-stage model that depicts the typical development in mechanical engineering.

Level 1 – Digitize. The installed base is mapped in a structured manner: Machines, components, configurations, contracts. A digital machine file replaces distributed Excel tables and PDF files.

Stage 2 – Networking. Sensor data, service history and technical knowledge are connected end-to-end. The IoT platform and service cloud work together bidirectionally, and knowledge sources such as Empolis are integrated on a contextual basis. This article starts at this level.

Level 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 attribution 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.”

Level 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-making intelligence, automation is merely a technical shell. For most mechanical engineering companies, the answer to the question “Where do we stand today?” is “between Stage 1 and Stage 2”—and that is precisely where it is determined whether IoT investments will translate into service value.

Conclusion: The value lies in the ability to connect

IoT in service is no longer a question of sensor technology. The platforms are mature, the protocols are established and the machines supply the data. What makes the difference between an expensive telemetry project and a service in which triage times are reduced and technicians drive to the job with the right spare part is the ability to connect the data to the 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 networked service cloud in which dispatchers, technicians and customers see the same truth, filtered by role.
3. A pragmatic architectural decision on security and data sovereignty that is made at an early stage and does not have to be renegotiated afterwards in every escalation.

If you put these three building blocks in place, you create the foundation on which later stages – decision-making intelligence and service work that scales like software – become possible in the first place. Without them, every AI discussion remains an add-on on an unstable basis.

The obvious first step is not the next sensor pilot project, but an honest inventory: How structured is the installed base today, and which data sources address which service process? The installed base assessment provides the basis for precisely this – in 4-6 weeks, clearly delineated, with a concrete leverage report. If you already have a structured base and would like to specifically assess where the next integration step lies, arrange an initial meeting directly.