Skip to main content

​
Understanding Paradigm’s Access Control Architecture

Paradigm’s security model is built on a three-tier hierarchy that controls who can access what content: 
👤 Users (Identity)
    ↓
👥 Teams (Grouping)
    ↓
📁 Workspaces (Content Scope)
    ↓
📄 Documents (Actual Content)
This architecture ensures that access control is:
  • Scalable: Manage hundreds of users through team memberships
  • Secure: Clear boundaries between different content scopes
  • Flexible: Fine-grained control from company-wide to private access
  • Auditable: Track who has access to what and when

​
The Three Core Components

​
1. Users - Your Identity Layer

Users are individual accounts in Paradigm. Each user:
  • Has a unique email and authentication
  • Belongs to exactly one company
  • Can be assigned multiple roles that define their permissions
  • Automatically gets a Private Team for personal workspace access
Key Concept: Users never directly access documents. Access is always mediated through team membership and workspace associations.
Learn more: User Management →

​
2. Teams - Your Grouping Layer

Teams are the central mechanism for organizing users and controlling access. There are three types:

​
Company Team (Automatic)

  • Automatically created for each company
  • All users in the company are automatically members
  • Controls access to company-wide workspaces
  • Cannot be deleted or modified

​
Custom Teams

  • Manually created by administrators
  • Used for departments, projects, or any grouping you need
  • Members are explicitly assigned
  • Example: “Engineering Team”, “Sales EMEA”, “Project Phoenix”

​
Private Teams (Automatic)

  • Automatically created for each user
  • Only that user is a member
  • Controls access to that user’s private workspace
  • Cannot be deleted or modified
Critical Understanding: Teams are how you control workspace access. When you add a team to a workspace, all team members get access to that workspace’s documents.
Learn more: Team Management →

​
3. Workspaces - Your Content Scope Layer

Workspaces are containers that organize documents and control access through team membership. Each workspace:
  • Contains a Collection of documents
  • Has one or more Teams as members
  • Defines the scope of document accessibility
  • Can be linked to external data sources
There are three workspace types that mirror the three team types:
Workspace TypeLinked TeamAccess LevelUse Case
CompanyCompany TeamAll company usersHR policies, general docs
CustomCustom Team(s)Specific team membersProjects, departments
PrivatePrivate TeamIndividual user onlyPersonal notes, drafts
The Key Relationship: Workspace access is determined by team membership. If you’re a member of a team that’s associated with a workspace, you can access that workspace’s documents.
Learn more: Workspace Fundamentals →

​
How Access Control Works in Practice

​
Example 1: Department Access

Scenario: Engineering team needs access to technical documentation

1. Create Custom Team: "Engineering Team"
2. Add engineers as team members
3. Create Custom Workspace: "Engineering - Technical Docs"
4. Associate "Engineering Team" with the workspace
5. Upload documents to the workspace

Result: All engineering team members can now access these documents

​
Example 2: Project-Based Access

Scenario: Cross-functional project needs temporary access

1. Create Custom Team: "Project Phoenix"
2. Add members from different departments
3. Create Custom Workspace: "Project Phoenix - Documentation"
4. Associate "Project Phoenix" team with workspace
5. When project ends, remove team members

Result: Only project team members have access during project lifecycle

​
Example 3: Company-Wide Policy

Scenario: HR policies need to be accessible to everyone

1. Use existing Company Team (automatic)
2. Use existing Company Workspace (or create new company workspace)
3. Upload HR documents to company workspace

Result: All company employees automatically have access

​
Permission Model

​
User Roles Define Actions

User roles control what actions a user can perform:
RoleCreate WorkspacesUpload DocumentsManage MembersView All Docs
Admin✅ All companies✅ All Workspaces✅ All companies✅ All companies
SysAdmin✅ All companies❌✅ All companies✅ Where member
Account Manager✅ All companies❌✅ All companies✅ Where member
Company Admin✅ Own company❌✅ Own company✅ Where member
Document Manager❌✅ Where member❌❌
Standard User❌❌❌❌

​
Team Membership Defines Scope

Team membership controls what content a user can access: 
User's Accessible Documents = 
  Documents in workspaces whose member teams include the user
Important: All roles can only see documents in workspaces where they’re a member (directly or through teams), unless they explicitly have cross-company access.

​
Security Principles

​
1. Principle of Least Privilege

Users should only have access to:
  • The minimum role needed to perform their job
  • The minimum team memberships needed for their work
  • The minimum workspaces needed for their projects

​
2. Segregation of Duties

Different roles have different capabilities:
  • Admins manage structure (users, teams, workspaces)
  • Document Managers manage content (upload, delete documents)
  • Users consume content (read, query documents)

​
3. Audit Trail

All access-related events are logged:
  • User creation and role changes
  • Team membership changes
  • Workspace access attempts
  • Document uploads and deletions

​
Common Access Patterns

​
Pattern 1: Departmental Structure

Marketing (Custom Team)
  └── Marketing Workspace
      └── Campaign docs, brand assets

Sales (Custom Team)
  └── Sales Workspace
      └── Playbooks, proposals

Engineering (Custom Team)
  └── Engineering Workspace
      └── Technical docs, specs

​
Pattern 2: Project-Based Structure

Project Alpha Team (Custom Team)
  └── Project Alpha Workspace
      └── All project documentation

Project Beta Team (Custom Team)
  └── Project Beta Workspace
      └── All project documentation

Company Team
  └── Company Workspace → HR policies, general info

Engineering Team
  └── Engineering Workspace → Shared technical docs

Project Phoenix Team
  └── Project Phoenix Workspace → Project-specific docs

Each User's Private Team
  └── Each User's Private Workspace → Personal drafts

​
Decision Framework

​
When to Create a New Team

✅ Create a new custom team when:
  • A distinct group needs access to specific content
  • The group will persist over time
  • Members need to collaborate on shared documents
❌ Don’t create a team if:
  • It’s for a one-time document share (use existing team)
  • Only one person needs access (use private workspace)
  • Everyone in company needs access (use company team)

​
When to Create a New Workspace

✅ Create a new workspace when:
  • Content has different access requirements
  • Documents form a coherent knowledge domain
  • You need to isolate sensitive information
❌ Don’t create a workspace if:
  • Documents can fit in existing workspace
  • Same team needs access
  • It’s just for organization (use folders instead)

​
Next Steps

Now that you understand the architecture, dive into each component:

User Management

Create users, assign roles, and manage permissions

Team Management

Organize users into teams for access control

Workspace Management

Create and manage content containers

Document Access Control

Understand how documents are secured

​
Quick Reference

​
Access Control Flow

​
Key Relationships

  • 1 User → 1 Company (fixed)
  • 1 User → Many Teams (flexible)
  • 1 Team → Many Workspaces (flexible)
  • 1 Workspace → Many Teams (flexible)
  • 1 Workspace → 1 Collection (fixed)
  • 1 Collection → Many Documents (flexible)