Documentation

Console

Roles and visibility

Roles are named groups in a tree. You assign them to people and to Blueprint folders, bookmarks, and internal apps. The server filters the Blueprint first. Each member then applies a personal overlay. This page is the permission model for an organization workspace — not OAuth scopes on a LoginSign App.

Read the workspace picture first: Structure.

Who can change roles

Only the owner and members with the built-in Admin role open Console → Roles. Developer and Accounting open Console for their own menus. They do not edit the role tree. Assigning Admin, Developer, or Accounting is how you give someone those Console rights.

What a role is

  • A named group, optionally nested under a parent.
  • Assigned to members on Users (permissionNodeIds).
  • Assigned to Blueprint items in Blueprint (one or more roles per object).
  • Assigned to an internal app via permissionNodeId.
  • Reused as an SSO assignment target (grant an application to everyone who has that role).

Disabled roles (canView false) do not grant visibility and do not count for SSO assignment. Built-in Console roles are the exception: they stay active, cannot be renamed or deleted, and are not visibility filters.

Built-in Console roles

  • Admin — users, roles, Blueprint, settings. Can see the current plan. Not billing write. Sees the full Blueprint.
  • Developer — Applications, Assignments, Sessions, On-premise, and branding settings.
  • Accounting — current plan and invoices.

Every organization heals these three roles. The workspace owner always has owner capabilities even without a role assignment. Extra people appear in the Console switcher when they have one of these roles. An Admin still has a personal overlay on /org/:slug. Changing the shared collection happens only in Console.

How visibility is decided

  1. Load the shared Blueprint.
  2. Drop every folder, bookmark, and internal app the member's active roles do not cover.
  3. If a folder is hidden, everything inside it is hidden.
  4. Add assigned SSO tiles (sso_…) the member may launch.
  5. Merge that person's overlay (renames, icons, personal folders).
  • No role on an item → every active member can see it.
  • One or more roles on an item → the member needs at least one matching active role.
  • Search, share, and the consume API never see hidden Blueprint items.

Worked example

Suppose the role tree is Organization → Sales, and Organization → Finance.

  • A “All staff” folder with no roles is visible to everyone.
  • A “Pipeline” folder tagged Sales is visible only to members who have Sales (or Admin).
  • A bookmark inside Pipeline is also hidden from Finance, even if that bookmark has no roles of its own.
  • A member with both Sales and Finance sees both tagged areas, plus everything untagged.

Plans

Every live plan can create roles and assign them to people and Blueprint items. Company and Enterprise include role governance. Team is the basic workspace: same tree, smaller seat limit, no custom domain. Applications that reuse these roles for SSO need Enterprise.

Create roles

  1. Open Console → Organisation → Roles.
  2. Create a role and optionally add an internal description or parent.
  3. Open Users and assign one or more roles to each member.
  4. Open Blueprint and tag folders or bookmarks that should not be organization-wide.

Owner API

GET    /api/developer/teamspaces/:id/permissions
POST   /api/developer/teamspaces/:id/permissions
PATCH  /api/developer/teamspaces/:id/permissions/:nodeId
DELETE /api/developer/teamspaces/:id/permissions/:nodeId

PUT    /api/developer/teamspaces/:id/collection/object-permissions/:objectId
       { "nodeIds": ["…"] }

POST body: { name, parentId?, description? }. Each node stores canView, canNavigate, and sortOrder. An empty nodeIds array on a Blueprint object restores organization-wide visibility.