Roles and Permissions

Understand the different collaboration roles in Juliet and what each role can do.

Written By Samir Patel

Last updated 3 months ago

Role Overview

Juliet uses role-based access control (RBAC) to manage project collaborators. Each role has specific permissions designed for different collaboration scenarios.

Four Roles:

Owner - Created the project, full control
Admin - Manage collaborators and project settings
Editor - Edit code and files
Viewer - Read-only access

Owner

Who is the Owner?

The person who created the project:

Started the project from dashboard or homepage
Has ultimate control
Cannot be removed from the project
There is only one owner per project

Owner badge:

Shows "Owner" or "You (Owner)" in collaborators list
Distinct visual indicator

Owner Permissions

Full Control: ✅ View all files and code ✅ Edit any file ✅ Chat with AI and request changes ✅ View preview and terminal ✅ Add collaborators (Viewer, Editor, Admin) ✅ Remove any collaborator ✅ Change collaborator roles ✅ Edit project name and description ✅ Download project ✅ Delete project permanently ✅ Manage all project settings ✅ Transfer ownership (if feature available)

Unique to Owner:

Delete project - Only owner can permanently delete
Ultimate authority - Final decision maker
Cannot be removed - Permanent member of project

Owner Responsibilities

As owner, you should:

Manage collaborator access appropriately
Protect project from accidental deletion
Ensure proper role assignments
Maintain project security
Backup important work

Admin

Purpose of Admin Role

Team leads and project managers:

Help manage the project
Can add/remove collaborators
Edit project settings
Almost full control (except deletion)

When to use:

Trusted team member
Project manager
Co-lead on project
Someone who needs management access

Admin Permissions

Almost Full Control: ✅ View all files and code ✅ Edit any file ✅ Chat with AI and request changes ✅ View preview and terminal ✅ Add collaborators (Viewer, Editor, Admin) ✅ Remove collaborators (except Owner) ✅ Change collaborator roles (except Owner's role) ✅ Edit project name and description ✅ Download project ✅ Manage most project settings

Cannot do: ❌ Delete the project ❌ Remove the Owner ❌ Change Owner's role ❌ Transfer ownership

Admin Use Cases

Scenarios for Admin:

Co-founder/Partner:

You: Owner
Your partner: Admin → Both manage project together

Project Manager:

You: Owner (developer)
PM: Admin (manages team access) → PM handles collaborator management

Team Lead:

You: Owner (client/stakeholder)
Dev lead: Admin (manages developers) → Lead assigns work and manages team

Editor

Purpose of Editor Role

Active contributors:

Developers working on code
Designers implementing UI
Content creators adding content
Anyone who needs to modify files

When to use:

Team members actively developing
Contributors who need edit access
Freelancers/contractors working on project
Most common collaborator role

Editor Permissions

Edit and View: ✅ View all files and code ✅ Edit any file ✅ Create new files (via AI or manual) ✅ Delete files (via AI) ✅ Chat with AI and request changes ✅ View preview and terminal ✅ Download project ✅ Save files

Cannot do: ❌ Add or remove collaborators ❌ Change collaborator roles ❌ Edit project name or description ❌ Delete project ❌ Manage project settings

Limited to:

Code and content
Development work
AI interactions
File operations

Editor Use Cases

Scenarios for Editor:

Development Team:

You: Owner
Developers: Editors → Devs write code, you manage access

Contractors:

You: Owner/Admin
Freelancer: Editor → Contractor works on specific features

Design Implementation:

You: Owner (designer)
Developer: Editor (implements designs) → Dev codes, you approve

Viewer

Purpose of Viewer Role

Read-only stakeholders:

Clients reviewing progress
Managers overseeing work
Team members who need visibility
Reviewers and approvers

When to use:

Stakeholders who shouldn't edit
Clients checking progress
Observers and learners
Anyone needing view-only access

Viewer Permissions

View Only: ✅ View all files and code ✅ View preview ✅ View terminal output ✅ Read chat history ✅ See who's collaborating

Cannot do: ❌ Edit any files ❌ Chat with AI ❌ Request changes ❌ Add/remove collaborators ❌ Change settings ❌ Download project (typically) ❌ Create or delete files

Strictly read-only:

No modifications possible
Safe for clients/stakeholders
Prevents accidental changes

Viewer Use Cases

Scenarios for Viewer:

Client Review:

You: Owner/Developer
Client: Viewer → Client sees progress, cannot break things

Manager Oversight:

You: Editor (developer)
Your manager: Viewer → Manager monitors, doesn't interfere

Stakeholder Updates:

Team: Editors
Executives: Viewers → Leadership visibility without access risk

Learning/Training:

Mentor: Editor/Admin
Student: Viewer → Student observes, learns, doesn't disrupt

Choosing the Right Role

Decision Framework

Ask yourself:

Do they need to edit code?
- Yes → Editor or higher
- No → Viewer
Do they need to manage team?
- Yes → Admin
- No → Editor or Viewer
Do they need ultimate control?
- Yes → Transfer ownership (if possible)
- No → Admin at most
Are they just observing?
- Yes → Viewer
- No → Editor or higher

Common Mistakes

Over-permissioning: ❌ Making everyone Admin

Security risk
Too many people with management access
Confusing responsibility

✅ Use Editor for most collaborators

Appropriate for developers
Limits management access
Clear hierarchy

Under-permissioning: ❌ Making developers Viewers

They can't do their job
Frustrating
Inefficient

✅ Use Editor for active contributors

They can work effectively
Appropriate access level

Best Practices

Principle of Least Privilege Give minimum necessary access:

Start with Viewer
Upgrade to Editor if needed
Reserve Admin for management
Don't default to highest role

Why:

Security
Prevents accidents
Clear responsibilities
Easier to manage

Review Roles Regularly Audit access:

Monthly or quarterly
After project milestones
When team changes
Remove/downgrade as appropriate

Document Role Expectations Clarify what each role means in your project:

Viewers: Clients and stakeholders, review only
Editors: Developers, implement features
Admins: Team leads, manage collaborators
Owner: Final authority, can delete

Communicate:

In project description
When sending invitations
In README file
Team onboarding docs

Use Viewer for External Stakeholders Clients, managers, observers:

Always start with Viewer
Prevents accidental changes
Upgrade only if they need edit access

Safety:

Client can't break the code
Manager can't accidentally delete files
Observer can learn without risk

Promote Trusted Editors to Admin When Editor needs more:

Consistently reliable
Needs to manage team
Trusted collaborator
Taking on leadership

Upgrade:

Editor → Admin
Now can add/remove team
Helps with management

Be Cautious with Admin Role Admin is powerful:

Can remove other Editors
Can add anyone
Almost full control

Only assign to:

Trusted team members
Co-leads
Project managers
People you trust completely

Security Considerations

Protecting Your Project

Owner responsibilities:

Don't give Admin to everyone
Review who has access
Remove access when not needed
Download backups regularly

Risks of over-permissioning:

Accidental deletions
Unauthorized changes
Security breaches
Loss of control

Access Hygiene

Good practices:

Remove when done - Completed collaborators don't need ongoing access
Downgrade instead of remove - Editor → Viewer if still need visibility
Audit regularly - Check who has what access
Revoke immediately - When someone leaves team
Use specific roles - Don't default to Admin

Troubleshooting Roles

"I can't edit files" → You're probably a Viewer. Ask owner for Editor role.

"I can't add collaborators" → You're probably an Editor. Ask owner for Admin role.

"I can't delete the project" → Only Owner can delete. Contact owner.

"Someone removed me by accident" → Ask owner to re-invite you with appropriate role.

"I want to transfer ownership" → Check settings or contact support (feature may not be available).