Appearance
Set up roles
You are deciding who can see a live fleet, who can change it, and who can administer the organisation that owns it. Dataplicity does that with roles, groups, and scope, not with a custom permission editor.
This page is the setup guide. Use Permission areas when you need the complete grant list behind each role.
What you are building
A small, named set of job functions. Most people should get access from a group that matches their job. A few people need a privileged primary role because they administer the organisation itself.
Do not invent a unique role per person. Do not leave everyone on Administrator because it is convenient.
A working design answers:
- Who owns the organisation and the SSO break-glass path?
- Who may invite users and change organisation settings?
- Who may change firmware, device classes, and engineering configuration?
- Who may change monitors, automation, and status?
- Who may act on incidents and alerts without redesigning the system?
- Who may see security detections, and who may change them?
- Which people should only see a tagged slice of devices or networks?
How Dataplicity decides access
Access is the combination of five things. Role is only one of them.
| Layer | What it does |
|---|---|
| Organisation membership | The person must belong to this organisation. |
| Effective roles | The person's primary role plus every group role. Grants add. They do not cancel each other. |
| Scope | Device and network access tags on the user or group. This is how you keep a contractor inside one customer or environment. |
| Plan and features | Some surfaces (SSO, security detections, logs) also require the organisation entitlement. |
| Managed identity | SCIM-managed users are read-only in Dataplicity while SCIM is on. Change those people in the identity provider. |
If a page is missing, a button is hidden, or an API returns 403, walk those five layers before assuming a product bug.
The invite form shows the roles available to this organisation. OEM organisations see OEM roles. Customer portal organisations see site roles. Organisation Administrator and Administrator appear in both.
Organisation Admin versus Administrator
Each organisation has exactly one Organisation Administrator. That account:
- owns the organisation
- can manage users, billing, and high-impact settings
- is the only Dataplicity identity that can bypass mandatory SSO with a password when the identity provider path fails
Give Administrator to the people who do day-to-day admin: users, groups, devices, networks, and organisation settings. Keep Organisation Admin for ownership and break-glass. Do not share that login. Do not try to create a second Organisation Admin.
Both roles hold full organisation permission (*). The difference is ownership and the SSO break-glass path, not who can open Settings.
User management, SSO, and organisation settings are tied to those two roles as the person's primary role. Do not rely on an Administrator group alone for the people who must invite users.
Recommended OEM role set
Start here for a vendor organisation that builds and operates the fleet. Create a group for each row except Organisation Admin, then put people in the group that matches their job.
| Job function | Role to assign | Typical people | Why this role |
|---|---|---|---|
| Organisation owner | Organisation Administrator | One named person | Ownership, billing, SSO break-glass. Daily work should happen on a different account. |
| IT / security admin | Administrator | Two or three deputies | Invite users, manage groups, configure SSO. Full product access without owning the account. |
| Product engineering | Developer | Firmware and device-class owners | Change classes, software, developer tools, devices, networks, and related ops surfaces. |
| Engineering readers | Engineering Viewer | PM, QA, contractors who must not ship | See classes, software, and logs. No engineering writes. |
| Fleet operations | Infrastructure Admin | People who own monitors and automation | Change ops configuration and status. |
| Shift operators | Infrastructure Operator | People who run the ops board | Same ops grants as Infrastructure Admin today; keep the role so you can tighten it later. |
| Field support | Support Engineer | L1 / L2 | See fleet context, acknowledge incidents and alerts, update status. No engineering redesign. |
| Ops stakeholders | Operations Viewer | Leads who watch health | See monitors and incidents. No changes. |
| Incident observers | Incident Viewer | People who follow the queue | See incidents and ops context. No acknowledgement. |
| Security owner | Security Admin | One security engineer | Change detections and security integrations. |
| Investigators | Security Analyst | SOC analysts | See security activity and fleet context. No detection policy changes. |
| Auditors | Security Viewer | Compliance readers | See security activity only. |
That is enough for most organisations. You do not need every viewer role on day one. Add Operations Viewer, Incident Viewer, and Security Viewer when those audiences exist.
What this set deliberately avoids
- Support does not get Developer. Support acknowledges and investigates; engineering changes classes and software.
- Analysts do not get Security Admin. Investigation is not detection-policy ownership.
- Contractors do not get Administrator. Give them a viewer or operator role and tag scope.
- Nobody shares the Organisation Admin login.
If support also needs log search
Support Engineer can triage incidents and alerts. It does not include log search. If a support pod must search organisation logs, add those people to an Engineering Viewer group as well. Roles stack; that combination still cannot change device classes.
Customer portal organisations
If you run a customer portal, that organisation has a different role list. These people work inside a site or network boundary, not the OEM estate.
| Job function | Role | Give it to |
|---|---|---|
| Site lead | Site Admin | The person who runs that customer site: devices, alerting, and ops inside the assigned boundary |
| On-site technician | Site Operator | People who reboot, capture evidence, and acknowledge alerts without restructuring the site |
| Read-only site staff | Site Viewer | People who only need visibility in that customer context |
| Broad read-only | Viewer | The default invite role when nothing more specific is required |
Keep OEM engineering and OEM support in the vendor organisation. Do not make a customer-site technician a Developer in the OEM tenant.
How roles stack
A person has a primary role (the one on their user record) plus any group roles. Dataplicity unions the grants.
Example:
- Primary role: Engineering Viewer (see classes and logs)
- Group: Support with role Support Engineer (acknowledge incidents and alerts)
That person can see engineering surfaces and act on incidents. They still cannot change device classes or manage users.
Use stacking for extras. Do not stack Administrator onto everyone as a shortcut.
Scope after role
Role answers what kind of work. Scope answers which devices and networks.
On the user or group, set device access tags and network access tags:
- Leave the special all devices / all networks tags for people who truly need the whole estate (Administrators, most Developers, the security owner).
- Give support and contractors the customer, site, or environment tags they are allowed to touch.
- Prefer putting tags on the group, so a new hire inherits the same boundary.
Role without scope is how a contractor gets the whole fleet.
Roll it out
- Name the Organisation Admin. Create a second Dataplicity login for that person and put Administrator on it for daily work.
- Choose two deputies. Give them Administrator as their primary role.
- Create groups that match the table above. Set the group role and, where needed, device/network tags.
- Move everyone else off Administrator / Developer unless that is actually their job.
- Invite remaining people into the matching group. Keep their primary role as the narrowest role that still fits if they have no group yet.
- Sign in as a spare Support Engineer and as a spare Engineering Viewer. Confirm each can do their job and cannot do the other team's job.
- Turn on SSO for a pilot group, then SCIM. Keep Organisation Admin as the password break-glass account.
- Review group membership when people change jobs. Deactivate leavers in the identity provider (or in Dataplicity if they are local accounts).
Verify before you widen access
For each job function, test with an account that has only that role (and its group tags):
- The person can open the pages they need.
- Create / edit / acknowledge / save is present only where the table says they should change things.
- A device or network outside their tags does not appear.
- An Administrator can still invite and remove users.
- After you require SSO, the Organisation Admin can still use password login.
Audit trails are the record of who did what after you go live. Individual accounts are what make that record usable.
Joiners, movers, and leavers
- Joiner: add them to the job-function group (and the identity-provider group that provisions it, if you use SCIM). Do not clone an Administrator.
- Mover: change group membership. Check tags. Confirm they lost the old job's writes.
- Leaver: deactivate in the identity provider for SCIM-managed users; remove or deactivate local users in Dataplicity. Review sessions, API keys, on-call responder devices, and audit history.
SCIM-managed users stay read-only in Dataplicity while SCIM is enabled. You can still add and edit local accounts. Do not create an unmanaged duplicate of a directory user to bypass that.
If you turn on SCIM group sync, you cannot create groups in Dataplicity and SCIM-managed groups become read-only. Leave group sync off when the job-function groups in this guide live in Dataplicity.
SCIM can assign roles only when you enable that option and only from the allowlist. Organisation Admin is not accepted from SCIM role payloads.