Customer portal

The customer portal is a vendor-branded frontend for the people who operate your deployed product. Customers sign in at the permanent hosted address https://your-vendor.dvcmgr.com. They see only the devices and networks assigned to their own organisation.

The portal carries your name, colours, sign-in copy, and support link. Northstar is an illustrative demonstration fleet.

OEM engineers keep using the Dataplicity engineering workspace to define device classes, software, streams, and device-page layouts. The portal is where the customer acts on the result.

The customer journey

A customer should experience a product, not your internal platform model:

1. They receive your portal address and a named-user invitation.
2. They sign in to a portal carrying your product identity and support route.
3. They see the products their organisation owns.
4. They open a location or operational grouping when that helps their job.
5. They open one device to see current product state, history, video, or permitted controls defined by its Device Class.
6. They contact your support team with a recognisable product, serial, and location, not an internal Dataplicity identifier.

Design onboarding, navigation, and support copy around that sequence. Do not require customers to learn terms such as stream binding, class software, fleet job, or firmware rollout.

Portal and OEM responsibilities

OEM engineering workspace	Customer portal
Define product Device Classes	View assigned product inventory
Upload and release class software	An Org owner or Admin claims and assigns devices
Configure class streams and page layouts	Open the class-designed device page
Operate firmware rollouts	Review device and network connectivity
Use engineering diagnostics and remote access	Manage portal users and account security where permitted

The portal is not a customer route into Remote Shell, the fleet logging cockpit, or firmware rollout controls.

Configure the customer boundary

An organisation administrator creates the hosted tenant at https://your-vendor.dvcmgr.com, enables the portal, and configures branding and sign-in copy. The current OEM UI does not provide self-service custom portal hostnames. Then:

1. create the downstream customer organisation
2. add its real-world sites or locations where relevant
3. create the portal network used to place each device in the current product
4. invite customer users with the smallest suitable role
5. have an Org owner or Admin claim and assign devices
6. verify each device's class page

Use dedicated ownership records where enabled. Tags remain useful operational selectors, but they do not replace the portal's customer and network boundary.

Customer, site, and network answer different questions:

• Customer: who owns or operates the product?
• Site: where is it installed in the real world?
• Network: which current portal deployment boundary contains the device?

A network assignment is currently required before a claimed portal device becomes active. Treat that as a placement step in fulfilment, not as a claim that every product naturally has a computer network. A network can represent a building, vehicle, cabinet, farm, or other customer grouping.

What customers see

Portal navigation is grouped into Fleet, Organisation, and Account. Availability depends on organisation configuration and role.

Overview

Overview names the customer organisation and summarises device, network, and user counts, including how many devices are still unassigned. It is a starting point rather than an operational console: use Inventory and Networks for detail.

Inventory

Inventory lists every device available to the portal organisation with its serial, connection status, network, and device class. An Org owner or Admin claims devices with Claim devices and places them on a network from the Assign network column. Site and Network operator roles do not see that assignment column in the current portal.

Inventory is the customer's working surface: claim a device, assign it to a network, and read current connection state per unit.

A newly claimed device stays dormant until it is assigned to a network. Treat that as an assignment state, not a connectivity failure, and say so in your own onboarding material.

Networks

A network is the customer's deployment boundary, such as one site or one vehicle. The network page counts total, online, and offline devices, charts online devices over time, and hosts class boards where they are configured.

Network pages give customers a per-site view with recent online history, so a single offline unit is read against a trend rather than in isolation.

Device

The device page shows identity and connection context for one unit, and it can also show the OEM-designed class page when class UI is enabled. Live product values on that page come from device class streams that you define on the class UI Components tab and lay out in UI Designer.

Without a class layout the device page still gives customers identity and 24-hour connectivity context, which is enough to distinguish a site problem from a product fault.

Organisation and Account

Administrators manage portal Users, Groups, organisation Configuration, and review Activity. Individual users manage their own password and multi-factor authentication under Security.

Product UI inside the portal

The Device Class determines the customer-safe product page shared by every unit of that model. Depending on the class definition, the page can combine:

• identity, connectivity, firmware, tags, and approved inventory facts
• current metrics, boolean state, and historical charts
• buttons and list actions
• boolean, numeric, slider, and enum settings
• tank, silo, battery, wellhead, and gauge-style levels
• camera video and event context

Each element must bind to an explicit class stream, action, setting, inventory fact, level input, or camera source. A customer role can only use the controls its permissions allow. See Design the customer product UI.

Plans and availability

The Customer Portal suite is currently beta-gated as well as plan-gated. Your organisation must be on the required release channel or enrolled in the beta programme.

Plan	Customer product availability
Free	Evaluate device connectivity; the Customer Portal suite is not included
Standard	Customer Portal suite with exactly one portal and one downstream customer organisation
Business+	Customer Portal suite with unlimited portals and downstream customer organisations

Every row remains subject to the beta and release-channel requirement above.

On Standard, the first portal and customer are real production objects; there is no separate demo or publish mode. Attempting to create a second portal or second customer requires an upgrade. Device and user allowances remain governed by the account's normal plan and service limits.

“Unlimited” applies to those two object quantities, not devices, users, traffic, storage, API requests, or support.

The suite consists of independently checked capabilities:

• whitelabel for portal branding and hosted portal configuration
• customers for downstream customer organisations and invitations
• device_class_ui for streams, actions, settings, UI Components, and UI Designer
• microservices for class container and release uploads
• firmware for class container sets and tag rollout groups

Device Class Inventory is a separate beta-gated Business+ capability. Claim bundles are separately gated to Enterprise. Warranty, licensing, RMA, SLA/SLO, extended stream retention, SSO, SCIM, and support integrations are also separate. Confirm each required capability before promising it in a customer contract.

Assign roles

Use customer-scoped roles:

Role	Typical portal use
Org owner	Own billing and organisation-wide administration
Admin	Manage the portal organisation, users, groups, claims, and placement
Network operator	Operate assigned devices and networks
Site operator	Operate devices at assigned sites
Site viewer	View devices at assigned sites without action controls

Do not invite customer operators as OEM Developers merely to expose a device page. Developer and Engineering permissions include product-wide class and software configuration.

Verify a portal release

Test with representative portal users:

• an administrator who can claim and assign
• an operator who can act on an assigned device
• a viewer who must not see action controls

For each role, verify:

1. only the intended customer and networks are visible
2. dormant inventory explains the assignment step
3. device connectivity agrees with the OEM view
4. class widgets show current, missing, stale, and offline states correctly
5. engineering-only controls are absent
6. sign-out returns to the correct vendor-branded host

Choose a different customer surface

Use a status page when customers only need selected service and incident truth. Use a paired dashboard display for a shared screen. Use the customer portal when named users need to operate their own devices and networks.

Related

• Turn your hardware into a customer SaaS product
• Design a device class page
• Device class streams
• Customer surfaces
• Customer ownership
• Map devices to customers
• Teams and roles
• Customer lifecycle and automation
• Production limits and service behaviour