Workspaces, Tenants & Roles

AppBlocks Cloud organizes everything you build into three levels. Understanding them is the difference between a fleet you can hand to a customer and one you have to babysit.

Level	What it is	Who it is for
Personal space	Everything you create while no workspace is selected. Visible only to you.	Trying things out, single-developer projects
Workspace	A shared container for applications, devices, groups, dashboards, SCADA screens, workflows and variables.	Your company or team
Tenant	A partition inside a workspace with its own devices, groups, variables and users.	One per end customer, site or building

A workspace is where your team works. A tenant is what your customer sees.

Personal space

When no workspace is selected the switcher shows Default Workspace. This is not a real workspace — it is your personal space, and everything in it belongs to your account alone. It cannot be shared, has no members, no roles and no tenants.

Move to a workspace as soon as a second person needs access. Content is not transferred automatically between your personal space and a workspace, so it is worth choosing before you build much.

Workspaces

What lives in a workspace

• Applications and project versions (firmware snapshots)
• Devices and device groups
• Dashboards, SCADA screens and data sources
• Workflows and their runs
• Workspace variables and tenant variable templates
• Audit logs, invites and members

Creating and switching

The workspace switcher sits in the sidebar under Workspace:

• Create Workspace — name it and you become its owner
• Switch Workspace — pick another workspace, or Default Workspace to return to your personal space
• Workspace Settings — members, variables, export/import and deletion

The selected workspace scopes the whole application. Devices, dashboards and workflows you see in the sidebar are the ones belonging to it.

Workspace settings

Settings → Workspace holds four sections:

Section	Contents
Members	Current members and their roles, plus pending invitations
Variables	Shared key/value pairs referenced from dashboards and workflows
Workspace Project	Export the workspace as a reusable bundle, or import one
Danger Zone	Delete the workspace

Deleting a workspace requires typing its name to confirm, and removes every tenant, device, group, dashboard, SCADA screen, workflow, project, firmware and audit log inside it. There is no undo.

Workspace roles

Every member of a workspace holds exactly one role.

Role	Can do
Owner	Full control, including deleting the workspace. Assigned to whoever created it and cannot be transferred or changed.
Admin	Manage workspace settings, members, variables and import/export. Can also create and edit applications, workflows, dashboards and devices.
Member	Create and edit applications, workflows, dashboards and devices. Cannot change workspace settings, members or variables.
Operator	Read-only access to devices and device groups. Cannot create or edit workspace resources.

A few consequences worth knowing:

• Operators see a reduced sidebar — Devices and Device Groups only. A write attempt returns "Operators have read-only access".
• Operators are nevertheless allowed to manage tenants: they can create, rename and delete them and manage tenant users. The role is designed for the person who onboards customers without touching the engineering content.
• Only the owner and admins can rename or delete the workspace, edit workspace variables, or read the workspace-wide audit trail.

Adding people

Two ways, both under Settings → Workspace → Members and both restricted to the owner and admins:

Add an existing user — enter the email address of someone who already has an AppBlocks account, choose a role, done. If they have no account yet this fails.

Invite by email — generates a link valid for 7 days and emails it. The recipient opens /invite/<token> and can either sign up on the spot, sign in with an existing account, or join with the account they are already signed in as. Creating a new invite for an address replaces any earlier pending one.

Pending invitations are listed with their expiry and can be revoked at any time.

Tenants

A tenant is a partition inside a workspace. Use one per end customer: their devices, their groups, their variable values and their logins, all inside the workspace your team maintains.

Tenants are created under Settings → Tenants, available to the workspace owner, admins and operators.

Selecting a tenant

Once a workspace has at least one tenant, a Tenant switcher appears in the sidebar below the workspace switcher:

• Switch Tenant — scope the interface to one tenant
• Exit Tenant View — return to the whole workspace

The selection matters when you create things:

Tenant assignment is set at creation

A device or device group is assigned to whichever tenant is selected at the moment you create it, and that assignment cannot be changed afterwards. Select the tenant before adding devices.

Content created with no tenant selected belongs to the workspace itself and is shared across tenants — that is where the applications, dashboards and workflows your team reuses for every customer should live.

Tenant roles

Role	Can do
Admin	Rename the tenant and edit its variable values. Can add and manage devices and device groups in the tenant, and invite or remove tenant users.
Member	View devices, device groups, events, dashboards and SCADA screens. Cannot change tenant settings or add devices.

Tenant users are added the same two ways as workspace members — by email address for existing accounts, or by an invitation link valid for 7 days. The tenant admin, along with workspace owners, admins and operators, may do this from Settings → Tenants.

How workspace roles map onto tenants

Workspace membership grants access to tenants automatically; nobody on your team has to be added to each customer's tenant individually.

Your workspace role	Effective role in every tenant
Owner or Admin	Full control of the tenant
Operator	Full control of the tenant (but still read-only on devices)
Member	Tenant member — sees tenant content, cannot manage the tenant
None (tenant user only)	Whatever role the tenant itself grants

Listing tenants reflects this: owners, admins and operators see every tenant in the workspace, while everyone else sees only the tenants they belong to.

Tenant-only members

A user who belongs to a tenant but not to the workspace is a tenant-only member — the typical end customer login. They get a deliberately narrow view:

• The sidebar shows Devices, Device Groups, Events, Dashboards and SCADA screens. No Designer, no Workflows, no Data Sources.
• The workspace member list, workspace variables and tenant variable templates are hidden from them.
• They cannot create or edit dashboards, SCADA screens, workflows or projects.
• Without the tenant admin role they cannot write device state variables or device tables — they can look, not touch.
• A tenant admin additionally gets Tenant Settings in the sidebar, where they fill in their own variable values.

Variables

Variables let one application serve many customers. Instead of hard-coding a broker address or a site name into a dashboard or workflow, you reference a variable and let the workspace or the tenant supply the value.

Workspace variables

Settings → Workspace → Variables. Shared across the whole workspace and referenced as:

{{workspace.variables.KEY_NAME}}

Use them for API keys, endpoints and configuration strings that are the same for every customer. Values are masked in the table and can be revealed individually. Reading them requires workspace membership; only the owner and admins can add, edit or remove them. When a workspace is exported, values are replaced with placeholders so secrets never travel inside a bundle.

Tenant variable templates

Settings → Tenants → Tenant Variable Templates. A template declares a key, a description and an optional default — it is the workspace administrator saying "every tenant must supply this". Keys are sanitized on save: anything outside A-Z, a-z, 0-9 and _ is stripped.

Tenant variables

Settings → Tenant Settings. Each tenant fills in a value for the keys the templates declare, referenced as:

{{tenant.variables.KEY_NAME}}

Tenant admins can edit their own values, as can workspace owners, admins and operators. Build the dashboard once against {{tenant.variables.SITE_NAME}}, and every customer sees their own.

Audit logs

Settings → Audit Logs records who did what. Entries cover firmware assignments, variable writes, table changes, commands, group setting pushes and workflow changes, each with the acting user's email, the affected devices and a timestamp.

Scope follows the tenant switcher: with a tenant selected you see that tenant's entries, and without one you see the workspace entries that belong to no tenant. The workspace-wide trail is readable by the owner and admins; a tenant's trail is additionally readable by that tenant's admins.

Exporting and importing a workspace

Settings → Workspace → Workspace Project exports the workspace as a bundle — applications, dashboards, workflows and tenant variable templates, with variable values replaced by placeholders. The bundle can be imported back into an existing workspace or as a new one, which makes it a practical way to stand up an identical deployment for a new region or a new customer of your own.

An imported workspace records the bundle id and version it came from, shown at the top of the section.

Putting it together

A typical machine builder ends up with:

1. One workspace for the company, owned by the engineering lead.
2. Engineers as members — they build the application, the dashboards and the workflows at workspace level, with no tenant selected.
3. A support person as operator — they can watch every device and onboard new customers as tenants without being able to change firmware or dashboards.
4. One tenant per customer, created before that customer's devices are added, so every device lands in the right partition.
5. Tenant variable templates for anything that differs per customer — site name, contact email, thresholds — with each customer's tenant admin filling in their own values.
6. Customer logins invited into their tenant only, never into the workspace, so they see their devices and dashboards and nothing else.

See Also

• Workspaces & Tenants API — automate all of the above
• Roles and permissions — the same rules as the API enforces them
• Devices API