Auto-Assign IoT Devices to Customers

Who it’s for

Equipment rental and leasing companies (construction gear, medical devices, commercial refrigeration, scooter fleets), MSPs managing white-label devices for end-customers, and OEMs shipping generic hardware that gets provisioned per-customer at first boot — any case where the device’s owner is a business identity (customer) that changes over the device’s lifecycle rather than a fixed wiring.

What it does

Reads the customer identifier from each device’s client-side attribute upload and transfers ownership of the device to the matching customer. The customer is created on demand the first time it is referenced, ownership moves when the device reports a new identifier, and the device returns to tenant ownership when the identifier clears.

Scenario 1 — First provisioning. A device boots up with no customer assignment and reports its first customerCode. The customer doesn’t exist yet — the chain creates it on demand and transfers ownership.

Scenario 2 — Reassignment to a different customer. The device’s new customerCode matches a customer already present in the tenant. The chain transfers ownership — the customer record is reused.

Scenario 3 — Device returned to the tenant pool. The device’s next attribute upload doesn’t carry customerCode (or it’s been cleared by the rental/provisioning system). The chain returns ownership of the device to the tenant — back to the inventory pool, available for the next assignment cycle.

The three scenarios cover the full lifecycle: first provisioning, reassignment, and return to the tenant inventory pool.

The chain extends the default ThingsBoard PE root chain with the auto-assignment flow — a filter that routes by customerCode presence, plus the two action nodes it feeds into:

• A script filter — labelled Customer Code present? in this chain. Routes attribute uploads that carry the customerCode key to the True branch (Change Owner → matching customer); the rest go to the False branch (Return to Tenant).
• Two change owner action nodes, one per branch of the filter:
  • True branch → Change Owner, configured with owner type Customer and the customer title pulled from the customerCode attribute, with on-demand customer creation enabled. Transfers the device to the matching customer.
  • False branch → Return to Tenant (also a Change Owner node), configured with owner type Tenant. Returns the device to tenant ownership.

How to set up

1. Click Install to open the install dialog. The dialog offers two paths:

   • Bind to a profile — enable Set as profile default rule chain and pick the target device profile. The imported chain becomes that profile’s default rule chain.
   • Install only — leave the toggle off. After install, either set it as the root — it already bundles the default routing plus the auto-assignment flow — or extract the auto-assignment flow into a nested rule chain and connect it to the Save Attributes Success output of your existing root.

2. The chain runs on the next attribute upload — find the post attributes API for your protocol in the Device APIs section on the APIs & SDKs page.

How to customize

• To use a different attribute key for the customer identifier — change Customer title on the Change Owner node (e.g. $[customerCode] → $[rentalAccountId]) and update the Customer Code present? filter body to match the new key.

• To require a pre-existing customer instead of auto-creating one — disable Create new customer if it doesn’t exist on the Change Owner node. Devices whose customerCode doesn’t match any existing customer then route to the node’s Failure output instead of provisioning a new customer.

• To route returned devices to a dedicated “Returns” customer instead of the tenant pool — on the Return to Tenant node, change Owner type from Tenant to Customer, set Customer title to a fixed literal name (e.g. Returns Inventory), and enable Create new customer if it doesn’t exist so the node auto-provisions the holding customer the first time it’s used. Useful when returned units should be staged for QA inspection before re-issue rather than dropping straight into the tenant pool.

• To support multi-level customer hierarchies — enable Create new customer on the same level as message originator on the Change Owner node. The new customer is placed as a child of whoever owns the device — a sub-customer under a parent customer, or a top-level customer under the tenant.