Overview
Glossa has a simple two-role permission structure: Owner and Member. These roles apply at the organization level, meaning all users have the same role across all projects in the organization—there are no per-project permissions.
This straightforward role system makes it easy to manage team access while ensuring appropriate controls over billing and integration settings.
The Two Roles
Owner
Owners have full administrative access to the organization.
What Owners can do:
Manage billing - View invoices, update payment methods, change plans
Enable integrations - Connect and configure all integrations (Gmail, Jira, Slack, etc.)
Everything Users can do - All project work, requirements, files, etc.
Invite members - Add new team members to the organization
Change roles - Upgrade Members to Owner role
Remove members - Remove people from the organization
Important limitation:
Once someone is made an Owner, they cannot be downgraded to a Member role through the UI
If downgrade is needed, contact [email protected]
Use cases for Owner role:
Leadership and executives who need billing access
Implementation leads who configure integrations
Team managers who handle member management
Anyone who needs full administrative control
Member
Members have access to all project work but cannot manage billing or integrations.
What Members can do:
All project work - Create, edit, delete projects
Requirements - Create, edit, delete, send to Jira
Files - Upload, view, download, delete
Acceptance criteria - Generate, edit, create
Tasks - Generate, edit, assign, create
Categories - Create, edit, delete
Clients - Create, edit, delete
Invite members - Add new team members
View all projects - Access every project in the organization
What Members cannot do:
Access billing information or change plans
Enable or configure integrations
Change their own role or others' roles
Remove other members (including themselves)
Use cases for Member role:
Project managers and consultants
Business analysts
Developers and technical staff
Anyone doing day-to-day project work
Role Comparison
Permission | Owner | Member |
Create/edit/delete projects | ✅ | ✅ |
Create/edit requirements | ✅ | ✅ |
Upload/manage files | ✅ | ✅ |
Generate ACs and tasks | ✅ | ✅ |
Send requirements to Jira | ✅ | ✅ |
Invite new members | ✅ | ✅ |
Manage billing | ✅ | ❌ |
Enable integrations | ✅ | ❌ |
Change user roles | ✅ | ❌ |
Remove members | ✅ | ❌ |
Organization-Level Permissions
No Per-Project Permissions
Glossa permissions work at the organization level only:
Every user can see every project in the organization
Every user can edit every project in the organization
You cannot grant different roles in different projects
You cannot revoke access to specific projects without removing someone from the organization entirely
Example: If you have 10 projects and 5 team members:
All 5 team members can access all 10 projects
There's no way to restrict someone to only 2 of the projects
Everyone sees everything
Why Organization-Level?
This design keeps permissions simple and encourages transparency:
No complex permission matrices
No confusion about who can access what
Easy collaboration across projects
Simpler onboarding for new team members
Working Around This Limitation
If you need to restrict access to certain projects:
Option 1: Separate organizations
Create different Glossa organizations for different clients or business units
Invite only relevant team members to each organization
Each organization has its own billing and integrations
Option 2: Careful member management
Only invite internal team members
Remove people when they no longer need access
Trust your team with full access
Multiple Owners
Allowed and Recommended
Organizations can and should have multiple Owners:
All Owners have equal permissions
No "primary owner" or hierarchy
Multiple Owners ensure continuity if someone leaves
Best practices:
Have at least 2-3 Owners for redundancy
Include leadership who manages billing
Include implementation leads who configure integrations
Don't make everyone an Owner (defeats the purpose)
Recommended setup:
Small team (2-5 people): 1-2 Owners
Medium team (6-15 people): 2-3 Owners
Large team (15+ people): 3-5 Owners
Changing Roles
Upgrading Member to Owner
Any Owner can upgrade a Member to Owner:
Go to Members tab
Find the person's row
Click the three-dot menu (⋮)
Select Change Role
Choose Owner
Confirm the change
The person immediately gains Owner permissions.
Downgrading Owner to Member
This cannot be done through the UI.
Once someone is made an Owner, the UI does not provide an option to downgrade them to Member.
If downgrade is needed:
Contact [email protected]
Explain the situation
Support can manually change the role on the backend
This is intentionally difficult to prevent accidental permission loss
Why this limitation?
Prevents accidental removal of Owner permissions
Ensures deliberate decisions about administrative access
Encourages thoughtful role assignment
Role Assignment Best Practices
Start Conservative
When inviting new team members:
Default to Member role for most people
Only make someone Owner if they specifically need billing or integration access
You can always upgrade later
Make Strategic Owners
Good candidates for Owner role:
✅ Company executives or department heads
✅ Finance team members who manage billing
✅ Technical leads who configure integrations
✅ Long-term team members who need full admin access
Not ideal for Owner role:
❌ Contractors or temporary team members
❌ New hires still in onboarding
❌ People who only need project work access
❌ Anyone who doesn't specifically need billing/integration access
Plan for Continuity
Ensure business continuity:
Have at least 2 Owners (preferably 3+)
Don't make the CEO the only Owner (they may not be hands-on)
Include operational leaders who are actively using Glossa
Document who has Owner access
Communicate Role Expectations
When assigning roles:
Explain what the role includes
Clarify why someone was made Owner (or not)
Set expectations about responsibilities
Document role assignments for the team
Role Limitations and Workarounds
Limitation: Can't Restrict Project Access
Problem: Everyone sees all projects
Workarounds:
Use clear project naming conventions
Create separate organizations for truly separate business units
Accept that transparency can be beneficial
Limitation: Users Can't Remove Themselves
Problem: Users cannot remove themselves from an organization
Workarounds:
Ask an Owner to remove you
Contact support if all Owners are unavailable
Owners should monitor and remove inactive members
Limitation: No Read-Only Access
Problem: Can't give someone view-only access
Workarounds:
Trust team members with edit access
Use exports for external stakeholders
Create separate organizations if truly needed
Limitation: Can't Downgrade Owners Easily
Problem: Made someone Owner by mistake
Workarounds:
Contact support to manually downgrade
Be careful when assigning Owner role
Consider impact before upgrading someone
Security Implications
Owner Role Security
Owners have access to sensitive information:
Billing data - Credit card info, invoices, spending
Integration credentials - Connected accounts for Gmail, Jira, etc.
Member management - Can remove people from the organization
Security best practices:
Limit Owner role to trusted, long-term team members
Review Owner list periodically
Remove Owner access when people leave the company
Use strong passwords and MFA for Owner accounts
Member Role Security
While Members can't access billing or integrations, they can:
View all project data across the organization
Edit and delete requirements, files, and projects
Invite new members to the organization
Security best practices:
Only invite internal team members
Remove users promptly when they leave
Monitor member activity
Use strong passwords and MFA for all accounts