Documentation

Appearance

How do we manufacture, provision, allocate, and hand over devices to customers? ​

Treat manufacturing identity, product identity, customer ownership, and site placement as separate steps. A device should be able to leave the factory with the right product identity before you know which customer or site will ultimately receive it.

A robust path is:

text
manufacture -> connect -> identify product -> verify -> allocate customer -> place at site -> hand over -> support

1. Build a repeatable factory image ​

Your factory image should contain the Linux/product software required for the hardware to boot and perform its local function. Keep customer-specific state out of the base image where possible.

For each production image record:

  • hardware model and revision;
  • Linux/image version;
  • product application version;
  • Dataplicity installation/provisioning method;
  • device serial/asset identity;
  • factory test result.

If your product already has a secure manufacturing identity system, keep it. Dataplicity should complement that process rather than become a replacement for hardware-rooted identity or secure boot.

2. Connect and verify the manufactured unit ​

Before customer allocation, prove that the unit:

  1. boots correctly;
  2. obtains network access in the factory or staging environment;
  3. connects to Dataplicity;
  4. appears with the intended device identity;
  5. is assigned to the correct Device Class/product generation;
  6. reports the minimum health/version data you need;
  7. reconnects after reboot.

A unit that has not passed this gate should not move into customer inventory simply because it has a serial number.

3. Keep product identity separate from customer identity ​

A Device Class describes what the device is. Customer/site allocation describes who owns or operates it and where it belongs.

Do not create different Device Classes merely because two customers bought the same model.

A useful model is:

Real-world conceptDataplicity concept
Product model/generationDevice Class
One manufactured unitDevice
Buyer/operator organisationPortal customer
Customer location/deploymentNetwork/site boundary
Customer staff memberPortal user

4. Hold new units in unassigned inventory ​

If the destination is not yet known, keep the device unassigned to a downstream customer rather than inventing a temporary customer/site.

This creates a clean distinction between:

  • manufactured stock;
  • customer-owned/allocated stock;
  • deployed devices at a known site;
  • returned/replacement devices.

Use explicit inventory state rather than overloading tags or names with ownership semantics.

5. Allocate only when the commercial handover is real ​

Allocation should happen when your business knows which customer owns or operates the device.

Before allocation confirm:

  • correct serial/device;
  • correct customer organisation;
  • correct product model;
  • expected support entitlement if your own systems track it;
  • whether the unit should immediately appear in the customer portal.

Dataplicity does not replace order fulfilment, invoicing, warranty, or ERP asset ownership. Integrate those systems where they are authoritative.

6. Place the unit at the correct site ​

For products that are site-oriented, assign the device to the customer location/network that represents the deployment.

A site may be a warehouse, forecourt, building, vehicle group, cabinet, branch, or another operational boundary.

Do not use a site merely as a visual folder if it has real access-control or operating meaning. Design the customer/site hierarchy to match how support and operations actually work.

7. Hand over customer access separately from engineering access ​

Your customer should use the Customer Portal. Your engineering/support team should use the Dataplicity engineering workspace.

The customer should not need engineering-level Remote Shell, logs, fleet jobs, or release controls merely to operate the product they bought.

Before handover, test using a real customer-scoped role:

  • the customer can see the intended device;
  • the customer cannot see another customer's device;
  • viewer/operator role boundaries work;
  • customer-safe data and actions are understandable;
  • engineering-only controls remain absent.

See Customer Portal.

8. Treat replacement and return as first-class flows ​

Plan what happens when a device is:

  • returned before deployment;
  • replaced under warranty;
  • moved between sites;
  • transferred to another customer;
  • refurbished and resold;
  • retired.

The serial/device identity should remain auditable while current customer/site allocation changes deliberately.

9. Automate after the manual path is proven ​

For higher-volume production, use supported provisioning/claim mechanisms and APIs to remove repetitive manual work. Do not automate until the one-device path is understood and reversible.

The automation should preserve the same gates:

  • product identity correct;
  • connectivity verified;
  • allocation explicit;
  • customer/site placement explicit;
  • handover tested.

See Provision and claim and the Gateway API.

Production handover checklist ​

  • [ ] Factory image/version is recorded.
  • [ ] Device identity matches the physical serial/asset.
  • [ ] Device connects and reconnects after reboot.
  • [ ] Correct Device Class is assigned.
  • [ ] Required streams/settings/actions are present.
  • [ ] Customer allocation matches the authoritative business record.
  • [ ] Site placement is correct.
  • [ ] Customer-scoped user can see the device.
  • [ ] Another customer cannot see it.
  • [ ] Engineering/support retains the intended support path.
  • [ ] Replacement, transfer, and retirement procedures are documented.