Appearance
What are Product Applications for, and what should stay in our own backend?
Product Applications are for bounded business and operational workflows around the connected product: customer-scoped records, rules, processes, device commands, roles, and offline datasets that make the hardware useful as a service.
They are not intended to replace every backend your company already has.
Good fits
Product Applications are a strong fit for things such as:
- customer-owned product records;
- equipment/site configuration beyond simple device settings;
- approval flows that lead to device actions;
- operational workflows spanning multiple devices;
- bounded schedules;
- access/tag datasets distributed to devices;
- customer-visible process state;
- product-specific audit/activity;
- rules that react to product data and create an operational response.
Examples include HVAC schedules, paid access workflows, silo/outload coordination, energy-site operations, and other processes where the workflow exists because the connected hardware exists.
Keep broad business systems outside
Keep these in the systems designed to own them:
- statutory accounting;
- general ERP;
- full CRM;
- payroll;
- tax;
- broad document management;
- enterprise data warehouse;
- complex billing/settlement ledgers;
- arbitrary high-scale compute workloads.
Integrate those systems instead of recreating them inside a Product Application.
A useful boundary test
Ask:
If we stopped selling this connected product tomorrow, would this workflow still exist?
If no, it is a good candidate for Product Applications.
If yes, it probably belongs in a broader business system and should integrate with the connected-product layer.
That is not an absolute rule, but it is a useful first filter.
Product Applications can own product-domain records
A Product Application may legitimately own records such as:
- an access credential used by the product;
- a site operating schedule;
- a customer-defined alarm policy;
- a dispensing authorisation request;
- a product workflow approval;
- a device-associated service state.
The important questions are whether the data model is bounded, customer-scoped, operationally understandable, and compatible with the platform's published durability and workflow semantics.
Do not force safety-critical or financially authoritative state into the platform
A Product Application can participate in a fuel, access, or payment-related workflow without becoming the final safety controller or financial ledger.
For example, Dataplicity might:
- present a customer/operator action;
- validate user authority;
- create a bounded workflow record;
- distribute relevant offline data;
- request a device operation;
- show the returned result.
The device still validates physical authority. A dedicated backend may still own credit, settlement, reconciliation, or legal entitlement.
See Where should business logic live?.
Prefer explicit integration over duplicated truth
If your ERP already owns a customer account number, do not create a second unrelated notion of the same account merely for convenience.
Instead:
- store the external identifier where useful;
- integrate changes through a supported API/process;
- define which side is authoritative;
- make reconciliation observable.
The same principle applies to billing, CRM, maintenance systems, and domain backends.
Why use Product Applications instead of writing another service?
Use them when they remove a real layer of undifferentiated SaaS work:
- multi-customer scoping;
- product-aware records;
- workflow state;
- customer roles;
- device-command integration;
- offline data distribution;
- customer activity/application surfaces.
If your requirement is mostly arbitrary code, custom databases, broad integration logic, or highly specialised compute, your own backend may be the clearer architecture.
Versioning matters
Treat a Product Application definition as production software. Changes to records, rules, processes, commands, roles, and offline data can alter customer behaviour.
Use published/versioned application definitions and explicit upgrades rather than editing a production customer workflow casually.
Where schema/data migration is required, use the currently supported Product Application lifecycle and do not assume unshipped migration features exist.