Overview
Glossa uses an organization-level access model: every member of your organization can view and edit every project within that organization. There are no per-project permissions, no restricted access to specific projects, and no read-only modes.
This design keeps permissions simple and encourages team transparency, but it requires thoughtful member management since everyone you invite gets access to everything.
How Organization-Level Access Works
Every Member Sees Everything
When you invite someone to your Glossa organization:
They can view all existing projects
They can edit all existing projects
They can create new projects
They can delete projects (if they have sufficient role permissions)
Example: If your organization has 15 projects across 5 different clients:
A new team member can access all 15 projects immediately
They see all requirements, files, and data in every project
They can make changes to any project
No Project-Level Restrictions
You cannot:
Restrict someone to specific projects only
Give someone read-only access to a project
Hide projects from certain team members
Create project-specific permissions
Grant different access levels in different projects
Role-Level Restrictions Only
The only access distinction is by role (Owner vs. Member):
Owners - Can manage billing and integrations + all project work
Members - Can do all project work but not billing/integrations
Both roles have full access to all projects. See the User Roles article for detailed role comparison.
Why Organization-Level Access?
Simplicity
Benefits:
No complex permission matrices to manage
No confusion about "who can see what"
Easy to understand and explain to team
Faster onboarding for new members
Fewer support issues related to access
Alternative (project-level permissions):
Would require managing permissions for each person on each project
Complexity increases exponentially with team and project size
Easy to make mistakes in permission assignment
More time spent on administration vs. actual work
Transparency
Benefits:
Everyone knows what everyone else is working on
Easy collaboration across projects
Knowledge sharing between projects
Reduced silos and information hoarding
Better continuity when team members change
Trade-offs:
Less privacy between projects
Requires trust among team members
Not suitable for highly confidential projects
Collaboration
Benefits:
Anyone can help on any project without permission requests
No bottlenecks waiting for access grants
Encourages cross-functional collaboration
Easier to shift resources between projects
Better utilization of expertise across projects
Trade-offs:
No natural boundaries between project teams
Requires good communication and coordination
May need other tools for role clarity
Implications for Your Organization
Who You Invite Matters
Since everyone sees everything:
Only invite people you trust with access to all your projects
Think carefully before inviting external contractors or temporary staff
Consider whether someone really needs Glossa access or just exports/summaries
Internal Team Members Only
Glossa is designed for internal teams:
Implementation consultants and their team
Internal IT or business teams
Trusted long-term contractors
Not suitable for:
External clients (no read-only access available)
Temporary or short-term contractors
Third-party vendors who only need limited visibility
Anyone who shouldn't see all your client work
Confidentiality Across Clients
Challenge: If you work with multiple clients:
Team member working on Client A can see Client B's project
May see sensitive client information across all clients
Requires appropriate confidentiality agreements
Mitigations:
Include Glossa access in confidentiality agreements
Set clear expectations about data privacy
Only hire trustworthy team members
Consider separate organizations for highly sensitive clients
Size of Your Team
Practical considerations:
Small teams (2-10 people):
Organization-level access works very well
Everyone knows what everyone is doing anyway
Easy collaboration and knowledge sharing
Medium teams (10-30 people):
Still manageable if everyone is full-time internal
May need clear project ownership to avoid confusion
Communication becomes more important
Large teams (30+ people):
Consider whether everyone truly needs access to everything
May want to split into multiple organizations by business unit
More critical to have strong data governance
Workarounds and Alternatives
If You Need Project Restrictions
Since Glossa doesn't support per-project permissions, here are alternatives:
Option 1: Multiple Organizations
Create separate Glossa organizations for different business units or clients:
Setup:
Organization A: Projects for Client X and Client Y
Organization B: Projects for Client Z
Each organization has its own members
Pros:
True project separation and access control
Different billing for different units
Clear boundaries between teams
Cons:
Multiple subscriptions/bills
Members can't easily switch between organizations
Duplication of effort (categories, integrations)
More administrative overhead
When to use:
Highly confidential projects that need strict separation
Completely separate business units or subsidiaries
Different legal entities
Client contracts require access isolation
Option 2: Careful Member Management
Keep one organization but manage members strictly:
Approach:
Only invite people who need access to all projects
Remove members as soon as they finish engagements
Use role assignments thoughtfully
Document who should have access and why
Pros:
Single organization to manage
Easier collaboration when needed
Lower cost (one subscription)
Cons:
Everyone still sees everything
Requires trust and good judgment
Need to actively remove people
When to use:
Internal teams only
High trust environment
Collaborative culture
Projects aren't strictly confidential
Option 3: Export and Share Externally
Keep sensitive details in Glossa, share summaries externally:
Approach:
Use Glossa for internal requirements work
Export to CSV or Jira for external sharing
Share only what external stakeholders need
Keep full detail in Glossa
Pros:
Full detail and collaboration internally
Controlled information externally
Works with Glossa's access model
Cons:
Manual export process
External stakeholders don't see real-time updates
Potential for version drift
When to use:
Clients or partners need limited visibility
Regulatory or compliance requirements for data sharing
External teams use different tools (Jira, etc.)
Best Practices
Be Selective About Invitations
Before inviting someone, ask:
Do they need access to all projects, or just one?
Will they only need access for a short time?
Are they trustworthy with all client data?
Could we share exports/summaries instead?
Default position:
When in doubt, don't invite
Start with exports and meetings
Invite only when clearly needed
Set Clear Expectations
When inviting new members:
Explain they'll see all projects
Set expectations about confidentiality
Clarify which projects they'll actively work on
Explain organizational norms about data privacy
Remove Members Promptly
When people no longer need access:
Remove them within 24 hours
Don't wait "just in case they need it"
Re-invite later if needed
Better to remove and re-invite than leave access open
Use the Library and Categories for Organization
Since you can't restrict project access:
Build your Capabilities Library by importing historical SOWs — this gives your team a shared vocabulary of standard components
Use Capability Review to match requirements to library categories in each project
Makes it easier to navigate large project sets and understand what's standard vs. custom
Keep in mind that all organization members can see the Library, including imported SOW file names and extracted content
Document Who Should Have Access
Maintain documentation:
List of all current members
Why each person needs access
Which projects they actively work on
Review quarterly and remove inactive members
Consider Multiple Organizations Carefully
Before creating multiple organizations:
Evaluate whether truly needed
Understand cost implications (multiple subscriptions)
Plan integration and category setup for each
Document which organization is for which purpose
Frequently Asked Questions
Q: Can I give someone access to just one project? A: No. All members see all projects. Consider using exports or creating a separate organization.
Q: Can I give my client read-only access? A: No. Glossa doesn't support read-only access or external stakeholders. Use exports or Jira integration.
Q: What if a team member shouldn't see certain client data? A: Don't invite them, or create a separate organization for sensitive projects.
Q: Can I hide projects from certain team members? A: No. All projects are visible to all members.
Q: Is this going to change in the future? A: If you need project-level permissions, let us know at [email protected].
Q: How do other teams handle this? A: Most teams using Glossa are small-to-medium internal teams where organization-level access works well. Larger teams sometimes use multiple organizations or careful member management.