Devices, readings and controls
Give a customer a useful view of their equipment, its readings and the actions they are allowed to take.
Give customers their devices, data and controls in your brand.
If you sell connected Linux hardware and do not want to build the customer SaaS around it from scratch, use Dataplicity for the shared device, customer and application layer. Give customers a branded view of their equipment, readings and permitted actions, then add records and workflows for jobs such as scheduling or outload. Your engineers keep the tools to operate and support the hardware.
- Keep your device software and hardware.
- Start with a customer device view or build a wider product workflow.
- Fleet operations remain useful whether or not you add an application.
Start with the job your customer needs to do.
A branded portal is the customer entrance. A Product Application defines the records, pages and workflows inside it.
Records and workflows
Build around a site task: manage schedules, review events or work through an outload process. Define the data and behaviour the task requires.
An application you already have
Keep it. Use Dataplicity for your engineering and support team without rebuilding the customer experience.
Explore this capabilityWhat you build. What Dataplicity provides.
Building the application takes product engineering. The platform supplies the shared machinery; your team defines what the product does.
Your device integration
Your team supplies the hardware, sensing, runtime and command handlers. Define the telemetry and controls your product exposes, including safety checks on the device.
Your customer experience
Configure branding, customer access and pages. For Product Applications, define records, rules and processes and connect them to your device contract.
The shared foundation
Dataplicity provides device identity, fleet operations, customer and site organisation, scoped customer access, and the application authoring and publishing system.
Follow one customer job through the system.
Worked SiloSentry reference scenario. This explains the operating model; it is not evidence of an unrelated customer deployment.
1. A reading reaches the product
A probe and gateway report a silo reading. Your sensing stack owns measurement and calibration.
2. The customer decides what to do
The customer sees their silo levels and attention state in the branded application. Their view is scoped to the equipment and site they can access.
3. Your team supports the equipment
When a reading or gateway needs investigation, engineers use device health, collected logs and remote access. Verify fresh readings after an intervention.
Open the guideProve one customer workflow before expanding.
The integration effort depends on your device interface, data model and workflow. A working example gives your engineers a concrete starting point.
Connect and define
Connect a representative device. Define its Device Class and the readings and actions required by the customer job.
Build and test
Build the customer pages and workflow. Check permissions with separate customer accounts and test device failures and lost connectivity. Offline behaviour needs explicit design.
Publish and operate
Publish a version and run it for a customer in a Product Instance. Test later changes with representative data and devices before moving customers to another version.
Open the guideShow the customer a finished job, not a collection of widgets.
Illustrative product evaluation paths. These are demonstrations to build and test, not accounts of customer deployments.
Monitor and control a site
Let an operator select their site, inspect readings and reading age, review attention state and use a permitted control. Show pending, unavailable and failed states instead of treating every click as a completed physical action.
Read the technical guideComplete a scheduling workflow
Define a schedule, publish the selected local data and show the applied state. Test the disconnected controller and verify recovery before promising the workflow to customers.
Read the technical guideKeep the result reviewable
Use customer-scoped records and execution state to explain what happened. Evaluate the application Workspace and the report or record needed for the job, including incomplete and failed outcomes.
Read the technical guideConnect the customer experience to the product lifecycle.
The customer page and the engineering workspace serve different audiences around the same equipment.
Release device software deliberately
Coordinate application versions and OS images through the appropriate release path without exposing engineering controls to the customer.
Explore this pathExplain the offline state
Keep the customer view honest about last-seen time, stale readings, pending settings and unavailable live controls.
Explore this pathProve customer separation
Use separate test accounts and sites. Verify that each user can see and operate only the records and equipment intended for them before inviting production users.
Read the technical guideChoose the customer scope you need.
Both paid plans can also be used for fleet operations without a customer application.
One customer on Standard
One Customer Portal and one downstream customer organisation, with portal branding. Use the published limits to check the fit.
Multiple customers on Business+
Multiple portals and customer organisations, subject to platform limits, alongside advanced operating capabilities.
Explore this capabilityInspect a complete application before planning your own.
Follow the level-monitor walkthrough from the device contract to the customer view. Then use the Product Applications guide to map the work for your product.