Roles & Permissions

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:

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:

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:

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:

EDITOR

If they only need to review:

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.

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.

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:

Viewer
  ↓
Joins Product Team
  ↓
Editor

Or:

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:

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:

ONE ACCOUNT
     ↓
SHARED PASSWORD
     ↓
Entire Team

Instead use:

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.