Appearance
Customer lifecycle and automation #
Dataplicity provides the operating and customer-facing software around your connected product. It does not need to become the system of record for every commercial process around that product.
The cleanest production architecture is to let each system own the job it is good at.
What Dataplicity owns #
Dataplicity is a good home for:
- device identity and remote operating connectivity;
- Device Class product definitions;
- fleet operations, diagnostics, evidence, and remote support;
- customer organisations and portal access;
- site, network, and device placement;
- customer-safe product data and controls;
- product-specific applications and workflows where enabled;
- Software Build and container delivery where that is part of your deployment model.
What normally stays in your existing systems #
Keep the authoritative commercial record in the systems that already own it:
- pricing, quotations, orders, invoices, payments, and tax;
- contracts and signed SLA terms;
- CRM account and sales history;
- legal warranty obligations;
- shipping, repair, parts, credits, and returns logistics;
- insurance and regulated records;
- hardware manufacture, certification, installation, and safety;
- Linux, secure boot, OS hardening, product application, and device firmware.
Dataplicity can expose useful operating context from those systems without needing to replace them.
A practical lifecycle split #
| Lifecycle job | Dataplicity role | External system role |
|---|---|---|
| Create a customer | Create the downstream operating boundary and portal access | CRM/ERP remains the commercial customer record |
| Allocate a device | Associate the serialised unit with the correct customer and place | ERP/asset system keeps fulfilment and chain-of-custody records where required |
| Operate the installed product | Fleet operations, customer UI, telemetry, actions, settings, diagnostics | Product backend keeps any domain-specific authoritative business state |
| Support an incident | Logs, diagnostics, remote access, device history, evidence | ITSM/helpdesk can remain the support case system if required |
| Replace a unit | Reassign the new device and remove the old customer context | ERP/RMA system owns shipping, repair, credits, and inventory movement |
| Decommission a unit | Remove access and operating placement | Asset/security process owns physical disposal, sanitisation, and legal retention |
| Update software | Orchestrate application containers through Software Builds and optionally stage qualified RAUC OS delivery | Existing product runtime or updater remains authoritative for software outside that path, including bootloader and physical device firmware |
Automation and the public API #
Use the published Gateway API for unattended automation. A browser UI calling an internal JSON endpoint does not turn that endpoint into a stable integration contract.
Current public API coverage is strongest around device inventory, state, Device Class information, and documented remote-access operations. Some customer-lifecycle operations remain UI-led.
| Lifecycle operation | Public Gateway API | Product path |
|---|---|---|
| Read organisation device inventory and online state | Yes | Engineering workspace |
| Read Device Class summary | Yes | Device Class detail |
| Use documented remote-access operations | Yes, for documented endpoints | Engineering workspace |
| Create a downstream customer organisation | UI-led | Customer journey > Customers |
| Create or brand a Customer Portal | UI-led | Customer journey > Customer Portal |
| Manage portal users and customer placement | UI-led | Customer Portal administration |
| Define streams, actions, settings, and product UI | UI-led | Engineering > Software > I/O, and Device Class UI Designer |
| Configure containers, Builds, and delivery | UI-led | Engineering > Software |
If an unattended business workflow depends on an operation that is currently UI-led, treat that as an integration requirement: use a published endpoint when available rather than coupling production automation to an undocumented application route.
Sale and fulfilment #
Create the commercial customer and order in the business system that owns them. Then create the corresponding Dataplicity customer boundary, allocate the serialised unit, place it at the correct site or network, and invite the named users who will operate it.
This keeps commercial ownership and operational ownership aligned without duplicating the entire ERP model inside Dataplicity.
Software release ownership #
Use Engineering > Software for a selected product Device Class. Attach application containers under Containers, compose exact versions and an optional OS image under Builds, then select the class default or a tag cohort. Managed OS images remain held for a staged rollout under Delivery; container versions begin reconciling from the effective Build.
Keep product application data migrations, OS-image construction, bootloader fallback, agent qualification, and physical firmware updates in the release processes that own them. Follow Software Builds and cohorts and Software delivery for the canonical platform steps.
Replacement and reassignment #
When replacing a physical unit:
- confirm the old unit's chain of custody where that matters;
- retain any evidence or records required by your business process;
- remove the old unit from the customer's operating context;
- allocate the replacement;
- verify that the customer can see only the intended unit and history.
Do not reuse a device identity for a different physical unit merely to preserve a dashboard row.
Return and repair #
Keep shipping, repair, parts, credits, and legal warranty decisions in the returns or ERP system that owns them. Dataplicity can carry device-linked diagnostic and operating context alongside that process.
That separation is useful: the support engineer gets the technical truth about the unit, while the business system retains the authoritative commercial record.
Decommissioning #
A complete decommission normally includes both cloud and physical steps:
- remove customer access;
- revoke or rotate device credentials as appropriate;
- stop product publishing;
- account for retained cloud data;
- update the physical asset record;
- follow the device sanitisation or disposal process.
Removing a portal record does not wipe the physical device.
Availability of optional lifecycle modules #
The basic Customer Portal suite is a supported product on its published plan entitlements. There is no beta, early-access, programme-enrolment, or release-channel gate for creating downstream customers or Customer Portals. Standard includes one Customer Portal and one downstream customer organisation; Business+ supports multiple portals and customer organisations subject to published platform limits.
Some adjacent capabilities such as claim bundles, Product Applications, warranty/RMA surfaces, extended retention, and enterprise integrations have their own plan or release availability.
Keep those changing details in the relevant availability/reference page rather than making them architectural dependencies by accident. The basic Customer Portal availability is documented under Plans and availability.