Skip to main content

Before You Begin

Applicable Roles: All roles (System Administrator, Tenant Administrator, End-User). This document serves as the overall operations manual for the platform. Readers are advised to focus on the sections corresponding to their own roles.

About This Manual​

  • This manual systematically introduces the operation methods for all functional modules of the platform, targeting three roles in the All-in-One platform: System Administrator, Tenant Administrator, and End-User. The manual is divided into three parts by role: Part 1 is the System Administrator operations guide, Part 2 is the Tenant Administrator operations guide, and Part 3 is the End-User operations guide.
  • Readers are advised to read the sections corresponding to their own roles first; System Administrators should read the entire manual to fully understand the complete management chain.

Platform Role Descriptions​

RoleAbbreviationResponsibilities and Scope of Authority
System AdministratorSysAdminHighest administrative authority on the platform, responsible for tenant lifecycle management, tenant profile management, tenant administrator account management, and platform system configuration. Does not directly manage devices, assets, or end-users.
Tenant AdministratorTenant AdminHighest administrative authority within a tenant, responsible for user management, device management, asset management, dashboard management, rule chain management, alarm management, and connectivity & solution deployment (including LoRaWAN device/gateway registration, solution templates, public tunnels, MQTT Broker subscriptions).
End-UserEnd-UserBasic user permissions within a tenant; can only view assigned dashboards, cannot create, edit, or delete dashboards. Has no authority to manage devices, assets, or rule chains.

Note: In this document, "System Administrator" and "Super Administrator" are the same concept, both referring to the role with the highest platform privileges.

Account Acquisition​

  • Platform accounts are created and assigned by higher-level administrators. The source of accounts for different roles is as follows:
RoleAccount CreatorInitial Account Acquisition Method
System AdministratorInitialized during platform deploymentInitial account and password are generated during deployment and are received and kept by the deployment responsible person. If lost, contact platform operations personnel to reset.
Tenant AdministratorSystem Administrator (see "Create Tenant Administrator")Depending on the creation flow, the System Administrator either securely assigns the account credentials or provides an activation link for the Tenant Administrator to set a password.
End-UserTenant Administrator (see "Create User")Depending on the creation flow, the Tenant Administrator either securely assigns the account credentials or provides an activation link for the user to set a password.

Important: The platform supports two account handoff methods, depending on the creation flow: the creator may securely communicate the account credentials, or the creator may provide an activation link through which the recipient sets a password. The platform does not automatically send an initial password email. When credentials are assigned directly, keep them safe and change the password as soon as possible after the first login. When an activation link is used, set the password through the link before logging in. (End-Users refer to "Change Password", Tenant Administrators refer to "Reset Tenant Admin Password" (operated by System Administrator) or change it themselves in personal settings.)

Special Notes on Rule Chains​

  • Rule chains are the core engine for data flow and business logic processing on the platform. System‑preset rule chains are fundamental to basic platform functions and must not be deleted.
Rule Chain TypeDescriptionDeletable?
System‑preset rule chainsAutomatically created during platform initialization, carrying core data processing logic.No
Custom rule chainsCreated by Tenant Administrators based on business needs to extend data processing flows.Yes, but only after confirming that no devices/assets are associated.

Warning: Deleting a system‑preset rule chain will cause platform malfunctions; do not operate. Before deleting a custom rule chain, ensure that all associations with devices and assets have been removed.

Quick Reference for Deletion Impact Scope​

Deletion behaviors differ significantly among platform entities. Some operations cascade‑delete associated data, while others only remove associations. Please consult the table below before performing any deletion to avoid creating "orphan resources" (entities that still consume quotas but are unmanaged).

Deletion OperationCascaded Deletion ContentOnly Remove Association / Not Deleted
Delete TenantAll users, devices, assets, dashboards, rule chains, telemetry data, and audit logs under that tenant (all permanently deleted, irrecoverable).—
Delete CustomerAll customer‑user accounts under that customer.Devices, assets, and dashboards assigned to that customer are not deleted; they are only unassigned, become unassigned, and still consume tenant quotas.
Delete Asset—Associated devices under the asset are not deleted; only the association is removed, and devices become independent.
Delete DeviceThe device itself and all its telemetry data, attributes, alarms, and event records.—
Delete UserThe user account itself.Devices, assets, and dashboards already assigned to that user are unaffected.
Delete DashboardThe dashboard itself.Data sources such as devices and assets referenced by it are unaffected.
Delete Profile (Template)The template itself.First migrate devices/assets that reference this template to another template; otherwise, operation may be affected.

Typical Misjudgment Reminders:

  • Deleting an asset ≠ deleting devices. After deleting an asset, its devices remain on the platform and continue to consume device quotas.
  • Deleting a customer ≠ releasing device quotas. After deleting a customer, devices become unassigned but still count against the tenant's device quota.
  • Deleting a device is the only operation that clears telemetry data. Confirm that historical data does not need to be retained before deletion.

Terminology Quick Reference​

TermBrief Description
TenantAn independent logical isolation unit on the platform, which can contain its own users, devices, assets, dashboards, and data.
Tenant ProfileA configuration template that defines the functional features, quotas, and module availability of a tenant.
DeviceA physical or virtual terminal that connects to the platform and reports data.
AssetA logical grouping of devices or other assets, used for organizing and managing resources.
DashboardA visualisation interface configured from data sources for monitoring and analysing data.
Rule ChainA data‑processing pipeline composed of rule nodes, defining how data is received, processed, and forwarded.
AlarmA notification automatically triggered based on conditions configured in rule chains, used for alerting abnormal situations.
Audit LogA log that records critical operation activities on the platform, used for security auditing and problem tracing. Only System Administrators and Tenant Administrators can view/export; End‑Users have no access.

Typical Operation Paths (Tenant Administrator Examples)​

This manual is organised by role and module. In practice, operations often require cross‑module coordination. The following two typical end‑to‑end operation paths are provided to help you quickly locate the required sections.

Scenario 1: Onboarding a Batch of New Devices and Configuring a Monitoring Dashboard​

  1. Create a device profile → "Device Management > 6. Create Device Profile"
  2. Create a device → "Device Management > 1. Create Device"
  3. (Optional) Create an asset profile → "Asset Management > 5. Create Asset Profile"
  4. (Optional) Create an asset and associate devices → "Asset Management > 1. Create Asset", "Asset Management > 3. Associate Devices with Asset"
  5. Create a dashboard → "Dashboard Management > 1. Create Dashboard"
  6. Add widgets and configure data sources → "Dashboard Management > 2. Add Widgets"
  7. Publish and assign the dashboard (also assign associated devices/assets) → "Dashboard Management > 5. Publish and Share Dashboard"

Scenario 2: Opening an Account for a Customer and Assigning Read‑Only Permissions​

  1. Create a customer → "User and Customer Management > 1. Create Customer"
  2. Create a user from the customer details page (do not create from the "Users" menu) → "User and Customer Management > 4. Create User"
  3. Assign devices/assets to that customer → Use "Manage Assigned Customers" in the device/asset list.
  4. Assign the dashboard to that customer → "Dashboard Management > 5. Publish and Share Dashboard > Method 2: Assign to Customer"

Hint: The dashboard and its underlying devices/assets must be assigned to the same customer in the same way, otherwise widgets will show "No data". See the "Design Constraints" note in the Dashboard Management overview for details.