> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiwa.codes/llms.txt > Use this file to discover all available pages before exploring further. # Roles & Permissions > Use Editor and Viewer roles to give AIWA collaborators the right access. Protect your project from unnecessary or accidental changes. When you invite someone to collaborate on an AIWA project, you can control the level of access they receive. Not every collaborator needs the ability to make changes. AIWA uses roles to help you give people the access they need while protecting your project from unnecessary or accidental changes. The two primary collaboration roles are: * Editor * Viewer **Give people the access they need, and no more than they need.** ## Understanding Roles Roles determine what a collaborator can do within the project. A simple way to think about them is: ```text theme={null} PROJECT ↓ COLLABORATORS ↓ ┌─────────────┐ ↓ ↓ EDITOR VIEWER ↓ ↓ Build & Review & Edit View ``` Use Editor for people who actively work on the project. Use Viewer for people who primarily need to review it. ## Editor An Editor is an active project collaborator. This role is appropriate for someone who needs to participate in building or modifying the application. Editors may be people such as: * Developers * Designers * Product team members * Technical partners * Contractors * Other people actively working on the project For example: ```text theme={null} PROJECT OWNER ↓ Invite Developer ↓ EDITOR ↓ Collaborate on Project ``` If someone needs to actively help you build the product, Editor is generally the appropriate role. ## When to Use Editor Use Editor access when someone needs to make changes to the project. For example, you may invite a developer to: * Add functionality * Improve an existing feature * Fix issues * Refine application workflows Or you might invite a designer who needs to actively improve: * Layouts * Navigation * Mobile responsiveness * User experience * Visual consistency The key distinction is that an Editor is participating in the creation of the product, rather than simply reviewing it. ## Viewer A Viewer is intended for someone who needs to see or review the project without the same editing capabilities as an Editor. Viewer access can be useful for: * Business partners * Stakeholders * Reviewers * Team members who don't build * People checking progress * People providing feedback For example: ```text theme={null} PROJECT OWNER ↓ Invite Stakeholder ↓ VIEWER ↓ Review Project ``` This lets you involve more people without giving everyone editing access. ## Editor vs Viewer Here's the easiest way to decide: | Capability | Editor | Viewer | | - | - | - | | Access the shared project | ✅ | ✅ | | Review the project | ✅ | ✅ | | Participate in building | ✅ | ❌ | | Make project changes | ✅ | ❌ | | Best for developers | ✅ | ❌ | | Best for active designers | ✅ | ❌ | | Best for stakeholders | Optional | ✅ | | Best for review-only access | ❌ | ✅ | If someone only needs to review your work, start with Viewer access. You can change their role later if they need to participate more actively. ## Choosing the Right Role Before inviting someone, ask: > Does this person need to change the project, or do they only need to review it? If they need to actively work on it: ```text theme={null} EDITOR ``` If they only need to review: ```text theme={null} VIEWER ``` That simple distinction will cover most situations. ## Example: Startup Team Suppose you're building a SaaS product with a small team. You have: * Founder * Developer * Designer * Marketing Manager * Investor Their access might look like: | Person | Suggested Role | | - | - | | Founder | Owner | | Developer | Editor | | Designer | Editor | | Marketing Manager | Viewer or Editor, depending on responsibilities | | Investor | Viewer | There's no benefit in giving someone editing access if they don't need it. ## Example: Working With a Contractor Suppose you bring in a contractor to help improve your application. You could give them Editor access while they're actively working on the project. ```text theme={null} Invite Contractor ↓ Editor Access ↓ Complete Work ↓ Review Changes ↓ Remove Access When Finished ``` This is better than sharing your personal AIWA credentials. ## Example: Internal Review Suppose your application is nearly ready for launch and you want several people on your team to review it. They don't need to modify anything. Give them Viewer access. ```text theme={null} PROJECT ↓ VIEWERS ↓ Review ↓ Feedback ↓ Owner / Editors Make Changes ``` This keeps the review process separate from the building process. ## Protect Production Projects Role management becomes especially important when your application is already live. A production project may power: * Customer accounts * Payments * Bookings * Business operations * Client portals * Internal systems Avoid giving editing access simply because someone wants to see the application. Use Viewer access when editing isn't necessary. Be particularly careful when granting Editor access to projects that are already being used by real customers. ## Changing Someone's Role A person's responsibilities may change over time. For example: ```text theme={null} Viewer ↓ Joins Product Team ↓ Editor ``` Or: ```text theme={null} Editor ↓ Finishes Development Work ↓ Viewer / Remove Access ``` AIWA allows role changes from the collaboration area, update the collaborator's role there rather than creating unnecessary additional accounts. ## Review Access Regularly As your team grows, periodically review who has access to important projects. Ask: * Does this person still work on the project? * Do they still need Editor access? * Could they use Viewer instead? * Does this contractor still need access? * Has someone's role changed? * Are there collaborators who should be removed? A simple principle is: ```text theme={null} RIGHT PERSON + RIGHT ROLE + RIGHT PROJECT ``` ## Remove Access When Necessary If someone no longer needs access to the project, remove them. Common situations include: * Contractor engagement completed * Employee leaves the company * Partner relationship ends * Temporary review finishes * Client project ends * Responsibilities change Don't leave unnecessary access active indefinitely. ## Roles Are Better Than Shared Accounts Avoid: ```text theme={null} ONE ACCOUNT ↓ SHARED PASSWORD ↓ Entire Team ``` Instead use: ```text theme={null} PROJECT OWNER ↓ INDIVIDUAL ACCESS ┌────┼────┐ ↓ ↓ ↓ Editor Editor Viewer ``` This gives you much better control over project access. ## What About Clients? Clients are slightly different from ordinary team collaborators. An agency client often needs to: * See what you've built * Review the latest version * Provide feedback * Request changes * Approve work But they don't necessarily need full editing access. That's why we'll cover Client Sharing & Review \[Agency] separately on the next page. ## Roles & Permissions at a Glance Remember: **Editor** For people who actively help build or modify the project. ```text theme={null} BUILD EDIT COLLABORATE ``` **Viewer** For people who need to see and review the project without actively building it. ```text theme={null} VIEW REVIEW FOLLOW PROGRESS ``` When you're unsure, start with the lower level of access and increase it when there's a genuine need. ## Next: Client Sharing & Review \[Agency] The next page is especially important for AIWA's agency positioning: Client Sharing & Review \[Agency]. We'll cover how agencies can bring clients into the development process without treating them like developers, including: * Sharing a client project * Giving clients review access * Previewing work before publishing * Gathering feedback * Making requested changes * Getting approval * Keeping clients away from unnecessary editing controls Share projects with clients for review and approval without giving them editing access. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.