Roles, groups and access policies

Sluicio answers two separate questions about every user, on two independent axes:

• Org role (viewer / editor / admin) — capability: what you may do.
• Groups + access policies — visibility: which services you may see.

A user’s visible set is the union of what every policy on every group they belong to grants. No group, no policy → they see nothing. There are no deny rules — a policy can only ever add to what a user sees, so one group can never hide what another group granted.

Deny by default

Visibility is strictly opt-in. A newly added viewer sees an empty catalog until they’re added to a group — see the onboarding gotcha below.

Org roles: capability

• Admin — everything: members, tokens, SSO, settings — and admins bypass visibility entirely. An admin sees all services and telemetry regardless of group membership.
• Editor — org-wide write capability. But read visibility is not org-wide: it resolves from group policies and shares exactly like a viewer’s. An org editor who belongs to no groups can edit anything they can reach — and sees an empty catalog.
• Viewer — read-only. Sees only what groups and shares grant.

The asymmetry for editors is deliberate: capability and visibility are independent, so making someone an editor never accidentally widens what they can see.

Groups and access policies: visibility

Members are organized into groups, and each group carries access policies that define its scope — the set of services its members can see (plus the integrations and systems those services imply, and their telemetry).

Policy kinds

Kind	Grants
service	one named service
integration	every service in an integration (via its matchers)
system	every service flagged as a system — all systems, one system kind, or one specific system
attributes	services whose resource attributes match all the given key=value pairs (AND)
compound	an integration/service target AND an attribute filter
all_org	everything in the org (wildcard)
expression	an arbitrary boolean tree — see below

Expression policies

The expression kind gives a single policy full AND / OR / NOT logic over two kinds of leaf: a service-name leaf (matches the service name) and an attribute leaf (matches a resource-attribute value). Operators: equals, not_equals, prefix, suffix, contains, regex, in, and — for attribute leaves — exists / not_exists.

Example — services starting with ABC, on team orders or payments, but not the sandbox ones:

{
  "kind": "expression",
  "conditions": {
    "op": "and",
    "children": [
      { "match": "prefix", "value": "ABC" },
      { "op": "or", "children": [
        { "attr": "team", "match": "equals", "value": "orders" },
        { "attr": "team", "match": "equals", "value": "payments" }
      ]},
      { "op": "not", "children": [
        { "attr": "env", "match": "equals", "value": "sandbox" }
      ]}
    ]
  }
}

Expression policies fail closed — a malformed or empty tree resolves to no services, never “all” — and NOT complements against your own org’s services only.

Group roles: scoped manage (Enterprise)

Within a group, each member has a group role:

• Group-viewer — see the group’s scope.
• Group-editor — additionally manage within the scope: edit service configuration, create and manage integrations and systems whose services fall inside it — without being an org-wide editor.

Two invariants:

• Managed ⊆ Visible, always. Manage implies view; nothing grants manage over something you can’t see.
• A group-editor can never edit the policy that defines their own scope — policies are org-admin territory, so nobody can widen their own reach.

The recommended pattern

Keep org admins to a handful of people. Make everyone else an org viewer, divided into groups — with group-editor rights on their own team’s scope. Each team manages its own services; nobody touches anyone else’s.

Per-signal visibility (Enterprise)

A policy can be narrowed to a subset of signals — traces, logs, metrics, messages. A signal-narrowed policy contributes visibility for those signals only, and never contributes manage rights: managing a service you can only partially observe is incoherent, so manage always requires full-signal scope.

This is how you give a stakeholder group the traces and logs of a flow without exposing its metrics, or vice versa.

Sharing (Enterprise)

Sometimes a group is too heavy: you want one person to see one thing. A share grants a single user visibility of one integration or system — it expands into their Visible set and never into Managed. Shares are viewer-only by design, which makes them safe for one-off or temporary access; revoking the share removes the visibility again.

Service accounts

Service accounts join groups exactly like users and resolve visibility the same way — so a token for an export job or a bot can be scoped to precisely one team’s services. Making a service account org-wide is an explicit opt-in, and a deployment can forbid org-wide service accounts cell-wide.

Community vs Enterprise

Advanced RBAC is gated by the rbac_advanced Enterprise entitlement — but the gate is on configuration, not enforcement. Deny-by-default and visibility filtering are identical in both editions; the license only decides which scoping tools you can configure.

Capability	Community	Enterprise (rbac_advanced)
Org roles, groups, members	✅	✅
Attach a group as viewer to an integration or system	✅	✅
Full policy language (service / attributes / compound / expression / all_org)	❌	✅
Scoped manage (group-editor)	❌ — group roles above viewer have no effect	✅
Sharing with a user	❌	✅
Per-signal visibility	❌	✅

In the Community Edition, attaching a group as viewer to an integration or system is the only visibility-granting mechanism — members of the attached group see it, its services, and their telemetry, read-only.

If an Enterprise license lapses, existing rich policies keep enforcing — they just stop being editable. A downgrade never silently widens access.

Worked example

An org with two product teams, a NOC, and some external stakeholders:

• Groups Team Payments and Team Orders, each with an attributes policy on team=payments / team=orders.
• Group NOC with an all_org policy narrowed to traces + logs.
• A stakeholder gets a share of the Checkout system.

Persona	Sees	Manages
Org admin	everything (visibility bypass)	everything
Org editor, no groups	nothing — empty catalog until grouped	anything they can reach (org-wide capability)
Org viewer + group-editor on Team Payments	the payments services	exactly the payments services
Org viewer in NOC	all services — traces and logs only	nothing
Org viewer with the Checkout share	the Checkout system and its services	nothing

The onboarding gotcha

Deny by default has one operational consequence worth planning for: a newly added viewer sees nothing — no services, no dashboards data, no telemetry — until an admin adds them to a group.

Add member + assign group as one step

Members are created under Settings → Members; group membership is assigned separately, under the group. Treat the two as a single onboarding step. A new member who logs in to an empty catalog will assume something is broken — it isn’t; it’s strict isolation working as designed.