Skip to main content
Groups are the primary way to manage permissions at scale in Credible. Instead of granting permissions to individual users, you organize users into groups and grant permissions to the entire group.

​
Understanding Groups

Groups are collections of users (and other groups) that can be granted permissions on resources. When you add a user to a group, they automatically inherit all permissions assigned to that group.

​
Group Roles

RoleCapabilities
AdminManage group membership, add/remove members, change roles, manage settings
MemberStandard group membership for permission inheritance

​
Nested Groups

Groups can contain other groups as members: 
Engineering Group
├── Backend Team Group
│   ├── Alice (admin)
│   ├── Bob (member)
│   └── Carol (member)
└── Frontend Team Group
    ├── David (admin)
    └── Eve (member)
When you grant permissions to the Engineering Group, all members of both Backend Team and Frontend Team inherit those permissions.

​
Creating and Managing Groups

Administrators can create groups through the Admin Portal or API:
  1. Provide a unique group name within your organization
  2. Add a description explaining the group’s purpose
  3. Add initial members (users or other groups)
  4. Assign member roles (admin or member)

​
Member Identifiers

Members are identified using the userGroupId format:
  • For users: user:{email} (e.g., user:alice@company.com)
  • For groups: group:{groupName} (e.g., group:backend-team)

​
Assigning Permissions to Groups

​
Organization Permissions

Roles: admin, modeler, member
  • admin: Full organization control, can create projects/workspaces/groups, manage all settings
  • modeler: Can create and manage packages across the organization
  • member: Basic membership, typically used with more specific project/workspace permissions

​
Project Permissions

Roles: admin, modeler, viewer
  • admin: Full project control, manage connections and all packages
  • modeler: Create/update packages, use connections, manage versions
  • viewer: Run queries, view model source code, read-only access

​
Package Permissions

Roles: admin, modeler, viewer Package-level roles are typically inherited from project permissions, but can be set explicitly for fine-grained control.

​
Workspace Permissions

Roles: manager, viewer
  • manager: Manage workspace, members, create/edit all documents
  • viewer: View workspace and documents, run queries, duplicate for personal exploration

​
Document Permissions

Roles: editor, viewer Document-level roles are typically inherited from workspace permissions, but can be set explicitly.

​
Permission Inheritance

Permissions flow down through the resource hierarchy: 
Organization: acme-corp
├── Permission: group:platform-admins → admin
├── Project: data-models
│   ├── Inherited: group:platform-admins → admin
│   └── Package: sales-model
│       └── Inherited: group:platform-admins → admin
└── Workspace: exploration
    ├── Inherited: group:platform-admins → manager
    └── Document: report.malloynb
        └── Inherited: group:platform-admins → editor
  • Organization admins become admins of all projects and managers of all workspaces
  • Project admins become admins of all packages in that project
  • Workspace managers become editors of all documents in that workspace

​
Common Permission Patterns

​
Team-Based Project Access

A data engineering team owns a project and its semantic models.
  1. Create data-engineering group with team members
  2. Grant modeler permission on the analytics-project
  3. Grant manager permission on a data-eng-workspace
Result: Team members can build models and collaborate.

​
Cross-Functional Analytics

Business analysts query models but don’t modify them.
  1. Create business-analysts group
  2. Grant viewer permission on multiple projects (sales, marketing)
  3. Grant manager permission on an analyst-workspace
Result: Analysts can query models and collaborate in their workspace.

​
Executive Dashboard Access

Executives need view-only access to specific reports.
  1. Create executives group
  2. Grant viewer permission on specific documents (e.g., executive dashboard)
Result: Executives can view and run queries but cannot modify.

​
Nested Group Hierarchy

Large organization with multiple engineering teams.
  1. Create engineering parent group
  2. Create sub-groups (backend-team, frontend-team)
  3. Add sub-groups to parent engineering group
  4. Grant viewer permission on app-analytics to parent group
Result: All sub-team members can query app-analytics models.

​
Workspace-Package Attachment

Workspaces can be attached to packages, granting workspace members access to query those packages without granting project-level permissions. Use case: You have a workspace for marketing analysis, and you want to give marketers access to the sales models without giving them access to the entire sales project. How it works:
  • A package permission is created with the workspace as the target
  • All workspace members can query the package
  • Workspace members don’t gain access to other packages or database connections
Example: Attaching marketing-workspace to sales-models package allows marketing workspace members to query sales models without seeing the entire sales project.

​
Requesting Access

Users can request access to resources they discover but don’t have permission to use.
  1. User finds a resource they need
  2. User submits an access request, specifying the desired role
  3. Resource administrators receive the request notification
  4. Admin reviews and approves/denies
  5. If approved, user gains the specified role

​
Viewing Permissions

Administrators can:
  • List all permissions on a specific resource
  • Check permission details (role, when granted, message)
  • View inherited permissions to understand the full chain
  • Verify admin status on resources

​
Best Practices

Use Groups, Not Individual Users
  • Easier onboarding (add to group)
  • Easier offboarding (remove from group)
  • Simpler auditing (view group membership)
  • Efficient permission changes (change group’s role once)
Create Groups by Function
  • data-engineering - modelers who build semantic models
  • business-analysts - analysts who query models
  • executives - leadership who view dashboards
  • platform-admins - infrastructure and admin team
Use Nested Groups for Large Organizations 
engineering (parent)
├── backend-team
├── frontend-team
├── data-team
└── ml-team
Grant permissions to the parent, and all sub-teams inherit. Start with Least Privilege
  • Most users should be viewer on projects
  • Only modelers need modeler on projects
  • Only a few trusted users need admin
You can always promote users later if they need more access. Use Workspace-Package Attachment for Collaboration When analysts need to use models but shouldn’t have project access:
  • Create a workspace for their team
  • Attach specific packages to that workspace
  • Gives them query access without project-level permissions

​
Next Steps

Access Control Overview

High-level overview of Credible’s permission model

Fine-Grained Access Control

Row and field-level security using Malloy annotations
⌘I