Documentation

Appearance

How are customer, site, and device tenants isolated? ​

Dataplicity deliberately separates the OEM engineering workspace from the downstream customer product application.

Your engineering and support team manages the installed base. Your customer signs in to the Customer Portal and sees only the customer organisations, sites, devices, data, and controls they are authorised to use.

Model ownership explicitly ​

A useful hierarchy is:

text
vendor / OEM
  |
  +-- customer A
  |     +-- site 1
  |     |    +-- device 001
  |     |    +-- device 002
  |     +-- site 2
  |          +-- device 003
  |
  +-- customer B
        +-- site 7
             +-- device 004

A Device Class defines what the product is. Customer/site allocation defines who can operate a particular unit and where it belongs.

Do not use Device Classes as a tenancy mechanism.

OEM engineering access is a different trust boundary ​

The OEM workspace can expose engineering capabilities such as:

  • logs and diagnostics;
  • Remote Shell;
  • fleet jobs;
  • device software/release controls;
  • Pulse and fleet-level evidence;
  • product definition and customer allocation.

Those are not simply extra tabs that a downstream customer should receive by default.

The Customer Portal exists so the product buyer can operate their equipment without entering the vendor's engineering console.

Customer users should receive product roles, not engineer roles ​

Design customer roles around what a customer operator needs to do.

Examples:

  • viewer - see product state and history;
  • operator - perform approved customer-safe actions or change bounded settings;
  • customer administrator - manage users/sites where supported.

Do not expose an action merely because the OEM can run the equivalent command through Remote Shell.

A customer-safe action should be deliberately modelled, validated locally, audited, and presented in product language.

Sites are more than folders when they affect access ​

If a site/network represents a real operational boundary, treat it as one.

Examples include:

  • a warehouse;
  • fuel site;
  • commercial building;
  • store;
  • remote cabinet;
  • customer branch;
  • deployed project.

Where customer users should only operate certain sites, the permission model should match that organisational reality rather than relying on naming conventions or tags.

Test isolation adversarially ​

Before production handover, do not test only the happy path.

Create at least:

  • two downstream customers;
  • two sites;
  • devices assigned across both customers;
  • viewer/operator users with deliberately different scopes.

Then verify:

  1. customer A cannot enumerate customer B devices;
  2. direct/deep links do not bypass the boundary;
  3. search cannot leak another tenant's device names or metadata;
  4. actions/settings are authorised server-side, not hidden only in UI;
  5. API access follows the same tenant boundary where applicable;
  6. logs/engineering diagnostics are not exposed through customer surfaces;
  7. reassignment removes old-customer access as expected.

Tenancy is a security property, not a visual navigation feature.

Customer data ownership and external systems ​

A customer may have product records in Dataplicity and authoritative commercial records in your ERP/CRM/backend.

Define which system owns which fact. For example:

FactLikely owner
Device product modelDataplicity Device Class / OEM product master
Current customer allocationDataplicity plus authoritative fulfilment/ERP integration
Invoice ownershipERP/billing
Current device stateDevice / Dataplicity product state
Customer transaction ledgerDomain backend if financially authoritative

Avoid creating competing masters that can silently disagree.

Reassignment is a security event ​

Moving a device between customers is not merely changing a label.

When ownership changes, verify:

  • previous customer access is removed;
  • new customer access is correct;
  • customer-specific cached/offline datasets are replaced where relevant;
  • historical data visibility follows your product policy;
  • audit records preserve the change.

For refurbished or transferred equipment, include reassignment in the operational runbook.