What business logic should live in Dataplicity, on the device, or in my backend?

Use Dataplicity for connected-product orchestration and bounded customer workflows. Keep logic on the device when it must remain correct without the cloud or when it controls physical safety. Keep complex or financially authoritative business systems in your own backend when they need to be your durable system of record.

That boundary is more useful than asking whether Dataplicity can execute a particular rule.

A practical rule

Logic	Best home
Safety interlocks, real-time control loops, machine protection	Device / controller
Behaviour that must continue during an Internet outage	Device, with cloud-assisted configuration if useful
Sensor interpretation tightly coupled to hardware	Device application
Desired configuration and operator-approved remote settings	Dataplicity + device validation
Customer/site/device records used by the connected product	Product Applications where the model fits
Alerts and bounded operational rules around product data	Dataplicity
Multi-step connected-product workflows and device commands	Product Applications where the failure model is acceptable
ERP, invoicing, statutory accounting, broad CRM	Your business systems
Authoritative credit, settlement, or financial ledger	Your backend / dedicated financial system
High-volume analytics or arbitrary data warehouse workloads	Dedicated analytics/data platform

Keep safety and physical authority local

A cloud platform should not be the final safety authority for a pump, burner, industrial machine, access gate, refrigeration compressor, or other physical system whose unsafe behaviour can cause harm.

The device or controller should validate commands against its own state and constraints. If a cloud user requests start, unlock, dispense, or set_temperature, the local application decides whether the operation is currently permitted.

Dataplicity can initiate and observe the operation. It should not be used to remove the local safety boundary.

Keep offline-critical behaviour local

Ask a simple question:

What must still work if this device cannot reach Dataplicity for six hours?

That behaviour belongs on the device.

Examples include:

• continuing an HVAC schedule;
• enforcing a machine limit;
• accepting locally cached credentials where your product permits it;
• recording transactions locally until they can be uploaded;
• continuing to control a pump or sensor loop;
• preserving a durable event journal for business-critical records.

Dataplicity can distribute configuration or offline datasets and receive the result later. It does not make the cloud an appropriate substitute for a local control system.

See What happens when a device is offline?.

Use Product Applications for bounded product workflows

Product Applications are a good fit when the workflow is part of the product you sell and is naturally expressed using customer-scoped records, rules, processes, device commands, roles, and offline data.

Examples include:

• an operator approving a bounded device action;
• assigning equipment to a site;
• scheduling an HVAC operating mode;
• distributing an authorised tag or access dataset;
• tracking a connected-product workflow from request to device result;
• presenting customer-owned operational records alongside the hardware.

This can remove a significant amount of bespoke SaaS work. It is not a reason to force every corporate process into Dataplicity.

Keep the system of record where it belongs

If another system is already authoritative, keep it authoritative.

For example:

• ERP owns orders and invoices;
• CRM owns opportunities and sales relationships;
• payment provider owns payment processing;
• accounting system owns the ledger;
• specialist maintenance system may own work orders;
• your domain backend may own complex cross-device commercial calculations.

Integrate those systems with Dataplicity rather than duplicating their entire data model inside a Product Application.

Financial and transactional logic needs a stronger boundary

A fuel, paid-access, or credit product illustrates the distinction well.

Dataplicity can participate in the workflow: expose customer data, distribute an offline authorisation dataset, receive a request, initiate a device command, and show the resulting state.

But if money, legal entitlement, or scarce credit depends on the transaction, your authoritative ledger should be designed for exactly-once business effects, idempotency, reconciliation, reversal, audit, and outage recovery. Do not infer those guarantees from a generic cloud action being queued or a telemetry value being observed.

Use the current device data and control contract when designing that path.

Do not confuse convenient with authoritative

A useful architecture can deliberately have several layers:

customer / operator
        |
        v
Dataplicity portal + Product Application
        |
        | requested action / desired state
        v
local product application
        |
        | validates against local state and safety rules
        v
physical equipment

And, where required:

Dataplicity <----> customer backend / ERP / ledger

The fact that a workflow begins in Dataplicity does not mean Dataplicity must own every consequence of that workflow.

When Dataplicity should own more

Let Dataplicity own more of the workflow when:

• the workflow exists specifically to operate the connected product;
• the data is naturally customer/site/device scoped;
• bounded records/rules/processes express it cleanly;
• the device can validate final physical authority;
• offline and failure semantics are acceptable;
• replacing a bespoke backend would remove undifferentiated engineering work.

When to keep it outside

Keep the logic in your device or backend when:

• milliseconds matter;
• loss of Internet must not change correct operation;
• the logic is safety-critical;
• it is a financial or legal system of record;
• the domain model is much larger than the connected product;
• you need arbitrary compute/data processing beyond the Product Application model;
• your existing system already solves it well.

Related

• Product Applications
• Device data and control contract
• What happens when a device is offline?
• What does Dataplicity replace?
• Production limits