Enterprise role-based access control for Granola.
Use when configuring user roles, setting permissions,
or implementing access control policies.
Trigger with phrases like "granola roles", "granola permissions",
"granola access control", "granola RBAC", "granola admin".
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Enterprise role-based access control for Granola.
Use when configuring user roles, setting permissions,
or implementing access control policies.
Trigger with phrases like "granola roles", "granola permissions",
"granola access control", "granola RBAC", "granola admin".
allowed-tools
Read, Write, Edit
version
1.0.0
license
MIT
author
Jeremy Longshore <jeremy@intentsolutions.io>
Granola Enterprise RBAC
Overview
Configure enterprise role-based access control for Granola meeting notes.
Prerequisites
Granola Business or Enterprise plan
Organization admin access
SSO configured (recommended)
Security policy defined
Role Hierarchy
Built-in Roles
Organization Owner (Super Admin)
↓
Organization Admin
↓
Workspace Admin
↓
Team Lead
↓
Member
↓
Viewer
↓
Guest (External)
## Role Assignment
Via Admin Panel:
1. Settings > Users
2. Find user
3. Click "Edit Role"
4. Select role
5. Choose workspace scope (if applicable)
6. Save changes
Via SSO Group Mapping:
1. Settings > SSO > Group Mapping
2. Map SSO group to Granola role
3. Set default workspace
4. Enable auto-provisioning
Custom Roles (Enterprise)
# Custom Role DefinitionRole:ContentManagerBase:MemberScope:MarketingWorkspaceAdditional Permissions:templates:create_edit_deleteshared_notes:edit_allexternal_sharing:enabledanalytics:workspace_viewRestrictions:cannot:delete_others_notescannot:manage_users
Role Inheritance
## Inheritance Rules1. Workspace role inherits org permissions
2. Higher role can access lower role data
3. Explicit deny overrides inheritance
4. Guest role has no inheritance
Example:
- User is Org Admin → auto Workspace Admin everywhere
- User is Team Lead in Eng → Member elsewhere
# Just-in-Time User CreationSettings:jit_provisioning:enableddefault_role:memberdefault_workspace:generalrequire_email_domain:"@company.com"Process:1.UsersignsinviaSSO2.Accountcreatedautomatically3.Groupsevaluated4.Roleassignedbasedongroups5.Accessgrantedimmediately
Access Policies
Sharing Policy
# Organization Sharing PolicyInternal Sharing:default:enabledteam_sharing:automaticcross_workspace:admin_approvalExternal Sharing:enabled:truerequire_approval:workspace_adminlink_expiration:30_dayspassword_protection:optionalPublic Links:enabled:false# Disabled for security
Data Access Policy
# Data Access RestrictionsBy Workspace:Corporate:visibility:owners_onlydownload:disabledexternal:prohibitedEngineering:visibility:workspacedownload:enabledexternal:with_approvalSales:visibility:workspacedownload:enabledexternal:enabledcrm_sync:automatic
## Access Guidelines1. Start with Viewer role
2. Upgrade as needed
3. Use workspace-specific roles
4. Review access quarterly
5. Remove access promptly when role changes
Anti-patterns:
✗ Everyone as Admin
✗ Permanent guest access
✗ Unused workspace admin rights
✗ Orphaned accounts
Role Lifecycle
## User Lifecycle
Onboarding:
1. Create via SSO/JIT
2. Assign default role
3. Add to relevant workspaces
4. Provide training
Role Change:
1. Request from manager
2. Approve by workspace admin
3. Update role
4. Verify access
Offboarding:
1. Triggered by HR system
2. Disable account
3. Revoke all access
4. Transfer note ownership
5. Archive after 30 days
