Skip to content

Users, teams, roles, and permissions

Every operator should use an individual identity. Dataplicity combines direct and group role assignments, then evaluates resource scopes and feature access.

Canonical roles include organisation administration, development, support, security, infrastructure, network and site operations, and read-only variants. The role catalogue shown by the product is authoritative because permissions can evolve.

Assign least privilege

  1. Start with the user's operational outcome.
  2. Choose the narrowest canonical role that provides the required actions.
  3. Prefer group assignment for repeatable job functions.
  4. Add network, tag, device-class, customer, or portal scope where supported.
  5. Test with the user's account before granting broader access.
  6. Review effective roles and inherited group sources.

Direct and inherited roles can combine. A hidden action can result from role, scope, managed/read-only identity state, feature access, or resource ownership.

Managed identities

SCIM-managed users and groups can make fields read-only in Dataplicity. Change those fields in the identity provider. Do not work around management by adding an unmanaged duplicate identity.

SCIM direct role assignment is separately enabled and uses an allowlist. Organisation admin and superuser roles are not accepted from SCIM role payloads.

Joiners, movers, and leavers

  • Invite a user to the intended organisation and groups.
  • Verify effective access to representative devices and customer records.
  • Change group and scope assignments when responsibilities move.
  • Deactivate access through the authoritative identity system.
  • Review sessions, API keys, on-call responder devices, and audit history after departure.