One device record from factory to field ticket

A supportable connected product needs more than a serial number. It needs one operational identity that survives the handoffs from provisioning to customer support.

Operating connected products series

1. After devices ship
2. One device record from factory to field ticket
3. Dataplicity beside your existing stack
4. From signal to verified recovery
5. Trust on someone else's network

The record is the continuity

A physical device passes through many systems and teams. Manufacturing knows a build batch and hardware serial. Provisioning knows an organisation key and device class. Operations knows connectivity, tags, logs, and monitors. Support knows a customer, site, and ticket. Engineering knows the software and the diagnostic path.

When each team uses a different identifier, a field incident starts with reconciliation:

• Which dashboard entry represents the unit in the ticket?
• Was it provisioned into the intended organisation and product class?
• Does the customer or site assignment still reflect where it is deployed?
• Which logs, monitors, access events, or fleet actions belong to it?
• Is a reported failure isolated, or part of a product, site, rollout, or network cohort?

Dataplicity centres these questions on the device record. The record does not replace factory systems, CRM, ITSM, observability, or product databases. It gives those systems a stable operational reference for the deployed Linux machine.

1. Provision an identity, not just an agent

The first operational handoff happens during installation.

An organisation provisioning key authorises the supported provisioning flow. The organisation can supply a default device class, and supported flows can select an explicit class. On first connection, the device appears in the intended organisation with its Dataplicity identity and current connection state.

Before adding the process to a production image:

1. Provision representative staging hardware.
2. Confirm the organisation, device class, architecture, and first connection.
3. Test the network path used at a real deployment site.
4. Verify the support tools and device-side permissions on the production image.
5. Protect and rotate provisioning material as a manufacturing secret.

The unit is not supportable merely because the agent has connected once. First connection proves the route. The next handoff establishes what the unit is and who depends on it.

See Provision and claim for the controlled production procedure.

2. Separate product identity from operational labels

Different kinds of context answer different questions:

Context	Question it answers	Example
Device identity	Which Dataplicity-managed Linux machine is this?	Device name and Dataplicity identifier
Device class	What product line and deployment configuration should describe it?	Retail gateway
Customer and site	Who relies on it, and where is it deployed?	Customer record and Manchester site
Tags	Which operational cohorts currently include it?	environment:production, cohort:beta
Network	Which organisation-owned grouping contains it?	UK field estate

A device class should represent a product line or durable deployment model. Tags are better for filtering, rollout waves, environments, and other cohorts that change during operations. Where customer and site modules are enabled, use their dedicated records for ownership and location instead of treating a tag as the complete system of record.

This distinction matters because selectors can drive monitors and fleet actions. Changing a tag can alter the next target set. Reusing a product class for an unrelated product can confuse provisioning and downstream operations. Reassigning a device without removing the previous customer's context can expose the wrong operational relationship.

Use Networks and tags to define the taxonomy and Customer ownership to model the business relationship.

3. Make shipment an ownership handoff

Before a unit is treated as shipped inventory, verify the context that support will need later:

• the device is in the intended organisation and class
• the current name and asset reference are searchable
• customer, site, environment, and rollout context are correct
• support can reach the intended logs, monitors, and remote tools
• access is scoped to individual team members rather than a shared account
• the device's effective Linux permissions match the production policy

This is the point where factory success becomes operating readiness.

The manufacturing system may remain authoritative for the bill of materials and physical serial. CRM may remain authoritative for the commercial account. Dataplicity does not need to absorb either system. Store or link the identifiers that let an operator move from those records to the deployed device without guessing.

4. Keep evidence attached to the same operational identity

After deployment, the device record becomes the route from a customer report, site, monitor, or support ticket to the affected unit and its cohort. Use it to scope evidence before interactive access and to retain the identity and time context needed for independent recovery checks.

The record keeps identity in that loop. It does not imply that every related event has identical retention or appears in one universal timeline. Product history, logs, alerts, incidents, and fleet results have their own coverage and retention. Preserve the identifiers and time window needed to correlate them.

Follow From signal to verified recovery for the complete response method.

5. Link external tickets; do not rebuild them

Dataplicity is not a replacement for a service desk. Keep ticket ownership, customer conversation, approval, and wider business workflow in the ITSM system that already serves the organisation.

The useful integration is a durable link between that process and the affected device:

• include the Dataplicity device identifier or device link in the ticket
• keep customer and site context consistent across the handoff
• record the incident time window and relevant monitor or log query
• return the verified outcome and remaining risk to the ticket

The Gateway API can expose fleet identity and operational context to supported server-side integrations. Use the public API contract rather than private dashboard endpoints, and keep API credentials outside browser code and customer-visible records.

6. Preserve identity through change

Field devices move. Customers change sites. Hardware is replaced. Product classes are retired. A device may be returned to stock or decommissioned.

Treat each transition as an explicit handoff:

1. Record the reason and effective time.
2. Remove customer, site, network, and access context that no longer applies.
3. Apply the new ownership and operational labels.
4. Recheck monitors, fleet selectors, and support-team visibility.
5. Uninstall or disable the agent when the device leaves management.

Do not silently reuse one device record for unrelated hardware merely to preserve a convenient name. The value of the record comes from maintaining a trustworthy relationship between identity, history, and the deployed machine.

The practical test

Choose one shipped unit and ask a support engineer who did not provision it to:

1. find it from the customer or site description
2. identify its product class and current operational cohorts
3. locate recent evidence without opening a shell first
4. explain who may access it and under which device-side permissions
5. link it to an external support record
6. verify a recovery independently

Every missing answer reveals a handoff to fix before fleet scale magnifies it.

Continue the series

Next, read Dataplicity beside your existing stack to decide which systems remain authoritative and where Dataplicity supplies the device-operational link.

Then use:

• Provision and claim to establish the production identity
• Device classes to model product lines
• Networks and tags to design operational cohorts
• Map devices to customers to make inventory findable
• Gateway API to connect supported server-side systems