Understanding Roles and Permissions

Understanding Roles and Permissions

Understanding Roles and Permissions

💡
Proper access control is essential for secure collaboration in CAD ROOMS. Understanding roles and permissions helps you protect sensitive designs, enable effective teamwork, and maintain control over who can do what in your workspaces and projects.
This guide explains the permission model, how to choose the right role for each team member, and best practices for maintaining security while enabling collaboration.

The Permission Model

CAD ROOMS uses a role-based access control system with permissions at two levels:
  1. Workspace Level - Controls who can access the workspace and create projects
  1. Project Level - Controls who can access specific projects and what they can do
This two-level system provides flexibility: give broad access to trusted team members, and limited access to external collaborators or clients.

The Three Core Roles

CAD ROOMS has three primary roles, each with different capabilities:

1. Admin (Full Control)

Who should be an Admin: Workspace owners, project managers, team leads
Capabilities:
  • ✅ Create, rename, and delete projects
  • ✅ Add and remove workspace members
  • ✅ Assign roles to other members
  • ✅ Manage billing and subscription
  • ✅ Configure workspace settings
  • ✅ Check out, check in, and contribute files
  • ✅ Create and approve Engineering Change Orders (ECOs)
  • ✅ Delete files and folders
  • ✅ Access all projects in the workspace
  • ✅ Promote file releases
  • ✅ View complete audit logs
Use Cases:
  • Company owners or executives
  • Engineering managers
  • Project leads who need full control
  • IT administrators managing the workspace
Security Consideration: Limit the number of admins. Too many admins increases risk of accidental deletions or unauthorized changes.

2. Collaborator (Edit Access)

Who should be a Collaborator: Engineers, designers, active contributors in the project.
Capabilities:
  • ✅ Check out and check in files
  • ✅ Upload and contribute files
  • ✅ Replace files they've checked out
  • ✅ Create Engineering Change Orders (ECOs)
  • ✅ Comment and use @mentions
  • ✅ View all files in assigned projects
  • ✅ Download files
  • ✅ Use the CAD viewer
  • ✅ View version history and activity logs
  • ❌ Cannot delete files (unless they uploaded and haven't contributed yet)
  • ❌ Cannot add/remove members
  • ❌ Cannot delete projects
  • ❌ Cannot access workspace settings
Use Cases:
  • Design engineers creating and modifying CAD files
  • Mechanical engineers working on assemblies
  • Electrical engineers managing PCB designs
  • Team members actively contributing to projects
Security Consideration: This is the appropriate role for most active team members. They can do their work without risk of accidentally deleting projects or changing critical settings.

3. Viewer (Read-Only Access)

Who should be a Viewer: Reviewers, clients, manufacturing partners, management
Capabilities:
  • ✅ View files in the CAD viewer
  • ✅ Download files (if enabled)
  • ✅ Add comments
  • ✅ View version history
  • ✅ View activity logs
  • ❌ Cannot check out files
  • ❌ Cannot upload or contribute files
  • ❌ Cannot create ECOs
  • ❌ Cannot replace or delete files
  • ❌ Cannot check in/out files
Use Cases:
  • Clients reviewing designs
  • Manufacturing partners viewing production files
  • Management reviewing project status
  • Quality assurance teams
  • Regulatory reviewers
  • External consultants providing feedback only
Security Consideration: Perfect for external parties who need visibility but shouldn't modify files. Prevents accidental changes while enabling collaboration.

Role Comparison Table

  • Project-level
Capability
Admin
Collaborator
Viewer
View files
✅
✅
✅
Download files
✅
✅
✅*
Use CAD viewer
✅
✅
✅
Add comments
✅
✅
✅
Check out files
✅
✅
❌
Upload files
✅
✅
❌
Contribute changes
✅
✅
❌
Replace files
✅
✅
❌
Delete files
✅
⚠️
❌
Create ECOs
✅
✅
❌
Approve ECOs
✅
⚠️*
❌
Create projects
✅
❌
❌
Delete projects
✅
❌
❌
Add members
✅
❌
❌
Manage billing
✅
❌
❌
Access settings
✅
❌
❌
* Download can be restricted by admin
* Collaborators can delete files they uploaded before contribution
* ECO approval permissions can be configured per project

Workspace-Level vs. Project-Level Permissions

Understanding the difference between workspace and project permissions is crucial for proper access control.

Workspace-Level Permissions

When you add someone to a workspace, you assign them a workspace role (Admin or Member).
Workspace Admin:
  • Can access ALL projects in the workspace
  • Can create new projects
  • Can manage workspace members
  • Can configure billing and settings
Workspace Meber:
  • Can access projects they're invited to
  • Cannot create projects
  • Cannot manage members
💡
Tip: When a file is shared externally, the recipient is automatically added as a Guest. Guests have read-only access and do not consume workspace seats

Project-Level Permissions

You can invite workspace members to specific projects and assign project-specific roles.
Key Points:
  • Workspace Admins automatically have admin access to all projects
  • Workspace members must be invited to each project
  • You can assign different roles per project (e.g., Collaborator in Project A, Viewer in Project B)
Example:
John (Workspace
This flexibility allows you to:
  • Give someone full control of their projects
  • Let them collaborate on team projects
  • Give them read-only access to reference projects

Choosing the Right Role

Use this decision framework to assign appropriate roles:

For Workspace Roles

Make them a Workspace Admin if:
  • They own or manage the company/team
  • They need to create projects
  • They need to manage members and billing
  • They need access to all projects
Make them a Workspace Member if:
  • They actively work on multiple projects
  • They're a full-time team member
  • They need to contribute files regularly
  • They don't need administrative control
Make them a Guest if:
  • They only need access to one specific file
  • They're external to your organization
  • Access is temporary or limited scope
  • You want to minimize their visibility

For Project Roles

Make them a Project Admin if:
  • They lead or manage that specific project
  • They need to add/remove project members
  • They need to configure project settings
  • They're responsible for that project's success
Make them a Project Collaborator if:
  • They actively work on the project
  • They need to create and edit files
  • They're part of the core project team
Make them a Project Viewer if:
  • They need to review the project
  • They provide feedback but don't edit
  • They're stakeholders or reviewers
  • They're from manufacturing, QA, or management

Permission Scenarios

Scenario 1: Internal Engineering Team

Team: 10 engineers, 1 manager, 5 products
Structure:
  • Manager: Workspace Admin (manages everything)
  • Senior Engineers (2): Workspace Admins (can create projects, help manage)
  • Engineers (8): Workspace Members (work on assigned projects)
  • Project assignments: Engineers invited to relevant projects as Collaborators
Why: Manager has full control, senior engineers can help manage, regular engineers have appropriate access without administrative burden.

Scenario 2: Client Collaboration

Team: Your 5 engineers + 2 client reviewers
Structure:
  • Your Engineers: Workspace Members and added to the project as Collaborators
  • Client Reviewers: Workspace Members and added to the project as Viewers (limited to their specific client project)
Why: This setup allows clients to log into the workspace and view their project directly, without seeing or accessing other internal projects. As Viewers, they can inspect files, review progress, and stay informed — but cannot modify, upload, or delete anything.

Scenario 3: Manufacturing Partner

Team: Your team + manufacturing partner
Structure:
  • Your Team: Workspace Members and added to the project as Collaborators
  • Manufacturing Partner: Workspace Member and added to a specific project as viewer
Why: Partner can download production files but can't modify designs. Access limited to manufacturing project only.

Scenario 4: External Consultant

Team: Your team + consultant working on one subsystem
Structure:
  • Your Team: Workspace Members and added to the project as Collaborators
  • Consultant: Workspace Member and added to a specific project as collaborators
Why: Consultant can actively work on their project but can't see other projects or workspace settings.

Scenario 5: Management Oversight

Team: Engineering team + executives
Structure:
  • Engineering Manager:
    Workspace Admin (manages team and projects)
  • Engineers: Workspace Members and added to projects as Collaborators
  • Executives:
    Workspace Members with Viewer roles on all projects
Why: Executives can monitor all projects without risk of accidental changes.

Security Best Practices

Principle of Least Privilege

Give users the minimum access they need to do their job:
✅ Do:
  • Start with Viewer, upgrade if needed
  • Limit the number of Admins
  • Review permissions regularly
❌ Don't:
  • Make everyone an Admin "just in case"
  • Give Project Collaborator access to people who only need to view and edit
  • Add external parties as workspace members if project-only access suffices

Regular Access Reviews

Monthly: Review active projects and remove members who no longer need access
Quarterly: Review workspace members and adjust roles as needed
When someone leaves: Immediately remove their access or transfer ownership of their projects

Sensitive Projects

For highly sensitive projects:
  • Limit to essential team members only
  • Use Viewer role for anyone who doesn't need to edit
  • Consider separate workspace for maximum isolation
  • Enable audit logging and review regularly

External Collaboration

When working with external parties:
  • Always use Guest access vis file sharing, not workspace membership
  • Start with Project Viewer role, upgrade only if necessary
  • Set clear expectations about what they can access
  • Remove access when project completes

Common Permission Mistakes

❌ Too Many Admins

Problem: Everyone is an admin "to make things easier"
Risk: Accidental deletions, unauthorized changes, billing issues
Solution: Limit admins to 1-3 people who actually need administrative control

❌ Collaborator When Viewer Suffices

Problem: Giving edit access to people who only need to review
Risk: Accidental file modifications, check-outs blocking others
Solution: Start with Viewer, upgrade only if they need to edit

❌ External Parties as Workspace Admin

Problem: Adding clients or contractors as workspace members
Risk: They can see all projects, not just theirs
Solution: Use Guest access for external parties

❌ Not Removing Old Access

Problem: Former employees or completed contractors still have access
Risk: Security breach, unauthorized access to current designs
Solution: Remove access immediately when someone leaves or project completes

❌ One-Size-Fits-All Permissions

Problem: Everyone has the same role across all projects
Risk: Over-access to some projects, under-access to others
Solution: Assign project-specific roles based on actual involvement

Related Articles