Permissions & Invitation Flows Across Subscription, Product, and Team Hierarchy
Shorter Loop uses a three-level hierarchy—Subscription → Product → Team—to control who can see and do what inside your workspace. Each level has its own roles and permissions so that you can safely delegate access without over‑provisioning.
Access hierarchy#
Shorter Loop organizes all work under a subscription, which may contain multiple products, and each product may contain multiple teams.Represents your company or organization account.
Owns billing, company profile, and global configuration.
Represents an individual product, portfolio, or major initiative you manage in Shorter Loop.
Owns product-level configuration and teams.
Represents a cross-functional squad or group working on a product.
Owns artifacts, work items, and day‑to‑day collaboration.
Roles at each level#
At every hierarchy level, Shorter Loop uses three core roles: Admin, Editor, and Viewer.Level and role matrix#
| Level | Available roles | Typical use case |
|---|
| Subscription | Subscription Admin, Editor, Viewer | Company‑wide admins and stakeholders across all products |
| Product | Product Admin, Editor, Viewer | Product leadership and contributors for a specific product |
| Team | Team Admin, Editor, Viewer | Squad‑level leads and ICs working on day‑to‑day execution |
How this maps to RBAC#
Shorter Loop’s model follows hierarchical role‑based access control (RBAC): assigning a role at a parent scope (for example, a subscription) automatically grants access to the child resources beneath it. The Admin–Editor–Viewer trio mirrors common SaaS patterns, where Admin controls configuration and user management, Editors can modify content, and Viewers have read‑only access to shared resources. docs.secureauth
Top‑down invitations (starting at subscription)#
When you invite users from the top level (Subscription), Shorter Loop automatically propagates their access to all products and teams under that subscription.Auto‑assignment behavior#
If you invite a user from the subscription‑level “Users” or “Access” area:Invite as Subscription AdminAutomatically added to all products and all teams.
Receives Admin role at subscription, product, and team levels.
Invite as Product Admin (from top‑level invite UI)Automatically added to all products and all teams.
Receives Product Admin at product level and Team Admin (or equivalent admin) at team level, as configured in your implementation.
Invite as Team Admin (from top‑level invite UI)Automatically added to all products and all teams.
Receives Team Admin at team level across teams.
Role consistency across levels#
Top‑down invites always preserve role consistency:Admin at top level → Admin everywhereIf a user is invited as an Admin at the subscription level, they are Admin on all products and teams.
Editor at top level → Editor everywhereInviting someone as an Editor at the subscription level makes them Editor on all products and teams.
Viewer at top level → Viewer everywhereInviting someone as a Viewer at the subscription level gives them read‑only access to all products and teams.
Visibility rules for top‑down invites#
Users invited from the subscription:Can see all products in the subscription.
Can see all teams within those products.
Their exact capabilities inside each team depend on whether they are Admin, Editor, or Viewer, but visibility is global.
Top‑down invite outcomes#
| Role chosen in subscription invite | Subscription scope | Product scope | Team scope | Visibility |
|---|
| Admin | Subscription Admin | Admin on all products | Admin on all teams | Sees all products and all teams |
| Editor | Subscription Editor | Editor on all products | Editor on all teams | Sees all products and all teams |
| Viewer | Subscription Viewer | Viewer on all products | Viewer on all teams | Sees all products and all teams (read‑only) |
Bottom‑up invitations (starting at product or team)#
When you invite users from lower levels (Product or Team), Shorter Loop automatically grants them minimal visibility upwards, without escalating their permissions.Default higher‑level role: Viewer#
If a user is first invited at the Team level:If a user is first invited at the Product level:Product: Admin / Editor / Viewer (as chosen)
Subscription: Viewer (automatically)
Any teams they are added to under that product:Inherit the product‑level intent (e.g., Editor or Admin) as per your configuration.
No privilege escalation from below#
Any role first assigned at a lower level (Product or Team) will automatically become Viewer at all higher levels.
Users gain the visibility they need (to navigate to their team/product).
They do not become subscription‑wide admins or editors just because they joined a single team.
Core roles and capabilities#
This section summarizes what the main roles can and cannot do, based on the access control list (ACL) configuration.High‑level capabilities by role#
| Capability / Action | Subscription Admin | Product Admin | Team Admin | Editor | Viewer | Portfolio Manager |
|---|
| Manage subscription admins | Yes | No | No | No | No | No |
| View & edit company profile | View & edit | View only | View only | View only | View only | View only |
| Create new products | Yes | No | No | No | No | No |
| Modify product details | Yes | Yes | No | No | No | No |
| Add/remove product admins | Yes | Yes | No | No | No | No |
| Add/remove team admins | Yes | Yes | Yes | No | No | No |
| View teams | Yes | Yes | Yes | Yes | No | Yes |
| Create/modify teams | Yes | Yes | Yes | No | No | No |
| Invite Editors / Viewers | Yes | Yes | Yes | No | No | No |
| Invite Portfolio Managers | Yes | Yes | No | No | No | Yes (can invite PMs) |
| Remove Editors / Viewers | Yes | Yes | Yes | No | No | No |
| Deactivate users from subscription | Yes | No | No | No | No | No |
| Comment on items | Yes | Yes | Yes | Yes | Yes | Yes |
| Edit artifacts | Yes | Yes | Yes | Yes | No | Yes |
| View artifacts | Yes | Yes | Yes | Yes | Yes | Yes |
| Edit work items | Yes | Yes | Yes | Yes | No | Yes |
| View work items | Yes | Yes | Yes | Yes | Yes | Yes |
| Access IDM admin pages / end‑user management | Yes | Yes | No | No | No | Yes |
| Manage integrations | Yes | Yes | Yes | Yes | No | Yes |
| View organization portfolio | Yes | Yes | Yes | Yes | Yes | Yes |
| Create/delete portfolio themes | Yes | Yes | No | No | No | Yes |
Note: Plan‑specific flags (enterprise-USD-Yearly, startup-USD-Monthly, etc.) follow the same pattern—Subscription Admin, Product Admin, and Portfolio Manager can view and create portfolio themes; other roles are view‑only when the portfolio is enabled on their plan.
Editor vs Viewer behavior#
While Admin roles focus on configuration and user management, Editors and Viewers focus on day‑to‑day work inside teams.Editor#
Can edit artifacts (documents, themes, etc.) within teams they belong to.
Can edit work items (create, update, manage status) within those teams.
Can view teams and products where they are granted access.
Cannot manage users (no invites, no role changes, no deactivation).
Has access to many insight/IDM‑related views (summaries, categories, statuses) but cannot change global settings.
Viewer#
Has read‑only access to artifacts and work items within teams they belong to.
Can comment but cannot edit artifacts or work items.
Cannot see teams or products they are not explicitly granted access to.
Has no access to configuration, integrations, or IDM admin pages.
Special roles: IDM Member and Anonymous#
Shorter Loop has two additional special‑purpose roles that are not part of the subscription/product/team triplet but appear in the ACL.IDM Member#
Use this role when you want a very restricted user in the insights/IDM module:Cannot see company profile, products, teams, artifacts, or work items globally.
Can edit work items they created themselves (through idmEditWorkItemCreatedByMe), but cannot browse the broader workspace.
Has no access to portfolio themes, integrations, or IDM admin pages.
Typically used for tightly scoped collaboration scenarios where a user should only touch the items they submit.
Anonymous#
Anonymous usually represents public or link‑based access:Can view artifacts and work items and leave comments, but cannot change them.
Cannot see company profile, products, or teams in navigation.
Has no access to user management, IDM admin, integrations, or portfolio creation.
Useful for sharing read‑only views with external stakeholders via links, while keeping admin surfaces locked down.
Portfolio Manager#
The Portfolio Manager role is optimized for users who manage cross‑product portfolios and themes:Can view and create portfolio themes across supported plans.
Can edit artifacts and work items, similar to powerful editors.
Can view teams and products, but does not manage subscription admins or product admins.
Has access to many IDM pages and integration controls, enabling them to coordinate portfolio‑level workflows.
Can invite other Portfolio Managers where allowed, but cannot elevate users to subscription admins.
Practical examples#
Company admin onboarding a new head of productInvite them from the Subscription level as a Product Admin so they can manage all products and teams without touching subscription billing or global deactivation.
Team lead adding a new engineer to their teamInvite them from the Team page as an Editor.
They will automatically be Viewer at the product and subscription levels, so they can navigate but not change global settings.
Portfolio lead coordinating themes across productsAssign them the Portfolio Manager role so they can create portfolio themes, manage related artifacts and work items, and leverage integrations without full subscription admin rights.
Modified at 2026-02-23 10:05:15
