Permissions and Access Control

Difficulty: Advanced

Overview

Security isn't about blocking people—it's about giving the right access to the right people at the right time. A well-configured permission model prevents accidental deletions, protects sensitive data, maintains compliance, and ensures team members can do their jobs without friction.

Waymaker uses Role-Based Access Control (RBAC) with permission inheritance from organization down to individual boards. Understanding this model is critical for administrators managing teams, protecting client data, and ensuring regulatory compliance. This guide provides a comprehensive reference to Waymaker's permission system and teaches you how to configure access control strategically.

What You'll Learn

• Role-Based Access Control (RBAC) fundamentals
• Five permission roles and what each can do
• Organization vs workspace vs board permissions
• Permission inheritance and override patterns
• How to change user roles
• Security best practices for access control
• Compliance considerations (GDPR, SOX, HIPAA)
• Audit logging and activity tracking
• Troubleshooting permission issues

Prerequisites

• A Waymaker account with Admin or Owner role
• Understanding of organization structure (organizations → workspaces → projects → boards)
• Familiarity with board settings (see Board Settings)
• Experience with team collaboration features (see Inviting Team Members)

Role-Based Access Control (RBAC)

What is RBAC?

Role-Based Access Control assigns permissions based on roles, not individuals.

Instead of:

• "Sarah can edit tasks"
• "Tom can delete boards"
• "Jane can invite members"

You assign roles:

• Sarah = Member (Members can edit tasks)
• Tom = Admin (Admins can delete boards)
• Jane = Admin (Admins can invite members)

Benefits:

• ✅ Consistent permissions: All Admins have same rights
• ✅ Easier management: Change role once, not 50 individual permissions
• ✅ Clear expectations: Team knows what each role can do
• ✅ Scalable: Add 100 members without configuring individual permissions

Waymaker's Five Roles

From most to least permissions:

1. Owner - Full control, can delete
2. Admin - Manage everything except deletion
3. Member - Create and edit content
4. Viewer - Read-only access
5. Guest - Limited, board-specific access

Each level includes all permissions of levels below it (Owner > Admin > Member > Viewer > Guest).

Permission Hierarchy

Levels of Permission

Waymaker has four permission levels:

Organization (top level)
└── Workspace
    └── Project
        └── Board (specific taskboard)

Permission Inheritance:

• Organization role applies to all workspaces, projects, and boards within
• Workspace role can override organization role for that workspace and below
• Project role can override workspace role for that project and below
• Board role can override project role for that specific board

Example:

• Sarah is Organization Member (can edit tasks across all boards)
• Sarah is Project Admin on "Client A" project (can manage Client A boards)
• Sarah is Board Owner on "Client A Onboarding" board (full control over that board)

Sarah's effective permissions:

• Client A Onboarding board: Owner (board role)
• Other Client A boards: Admin (project role)
• All other boards: Member (organization role)

Organization-Level Permissions

Set in Organization Settings → Members:

Organization Owner:

• One person (usually founder/CEO)
• Full control over organization
• Can delete organization
• Can change billing and plan
• Can demote/remove any member (including other Owners in multi-owner orgs)

Organization Admin:

• Manage workspaces, projects, boards
• Invite/remove members
• Configure integrations
• View billing (cannot change)
• Cannot delete organization

Organization Member:

• Create workspaces and projects
• Create boards within projects they have access to
• Edit tasks across organization
• Cannot manage members or settings

Organization Viewer:

• Read-only across organization
• See all boards, tasks, comments
• Cannot create or edit anything
• Good for stakeholders, observers

Board-Level Permissions

Set in Board Settings → Members:

Board Owner:

• Full control over this specific board
• Can delete board (destructive action)
• Can change board settings
• Can manage board members
• Can archive/restore board
• Usually the person who created the board

Board Admin:

• Manage board settings (name, description, sections)
• Manage board members (add, remove, change roles)
• Cannot delete board
• Good for project leads

Board Member:

• Create, edit, delete tasks
• Add comments and @mentions
• Upload files
• Move tasks between sections
• Assign tasks
• Cannot manage board settings or members

Board Viewer:

• Read-only access to this board
• See tasks, comments, files
• Cannot create or edit anything
• Good for stakeholders, clients (as guests)

Comprehensive Permission Matrix

What Each Role Can Do

Organization-Level Actions:

Action	Owner	Admin	Member	Viewer
Delete organization	✅	❌	❌	❌
Manage billing	✅	View only	❌	❌
Add/remove members	✅	✅	❌	❌
Create workspaces	✅	✅	✅	❌
Configure integrations	✅	✅	❌	❌
View all boards	✅	✅	✅	✅

Board-Level Actions:

Action	Owner	Admin	Member	Viewer	Guest (M)	Guest (V)
Delete board	✅	❌	❌	❌	❌	❌
Archive board	✅	✅	❌	❌	❌	❌
Manage board settings	✅	✅	❌	❌	❌	❌
Add/remove members	✅	✅	❌	❌	❌	❌
Create layers	✅	✅	✅	❌	❌	❌
Edit layers	✅	✅	✅	❌	❌	❌
Create sections	✅	✅	❌	❌	❌	❌
Create tasks	✅	✅	✅	❌	✅	❌
Edit tasks	✅	✅	✅	❌	✅	❌
Delete tasks	✅	✅	✅	❌	✅	❌
Add comments	✅	✅	✅	❌	✅	❌
Upload files	✅	✅	✅	❌	✅	❌
View all content	✅	✅	✅	✅	✅	✅
Download files	✅	✅	✅	✅	✅	✅
Export data	✅	✅	✅	✅	❌	❌
Invite guests	✅	✅	❌	❌	❌	❌

Legend:

• Guest (M): Guest with Member permission
• Guest (V): Guest with Viewer permission

Task-Level Permissions

Special case: Task ownership

Action	Task Owner	Assignee	Other Members	Viewer
Edit task details	✅	✅	✅	❌
Delete task	✅	✅	✅ (if Member)	❌
Assign/reassign	✅	✅	✅	❌
Add comments	✅	✅	✅	❌
View task	✅	✅	✅	✅

Note: Task-level permissions are minimal. Board Members can edit any task on the board, regardless of who created or is assigned to it.

Managing User Roles

Changing Organization Roles

Requires: Organization Owner or Admin

1. Click Organization menu (top-left)
2. Select "Settings"
3. Click "Members" tab
4. Find user in members list
5. Click Role dropdown next to their name
6. Select new role:
   • Owner
   • Admin
   • Member
   • Viewer
7. Confirm: "Change [Name]'s role to [Role]?"
8. Click "Change Role"
9. Change applies immediately across all boards

Effect:

• User's permissions update organization-wide
• If promoted to Admin: Can now manage members, workspaces
• If demoted to Viewer: Loses edit access to all boards
• Existing board-specific role overrides remain (see below)

Changing Board Roles

Requires: Board Owner or Admin

1. Open board
2. Board Menu → Settings
3. Click "Members" tab
4. Find member in board members list
5. Click Role dropdown next to their name
6. Select new role:
   • Owner
   • Admin
   • Member
   • Viewer
   • Or "Remove from board"
7. Role updates immediately for that board only

Board-Specific Override:

Example:

• Tom is Organization Member (can edit tasks across org)
• You change Tom's role on "Confidential Project" board to Viewer
• Tom's effective permissions:
  • Confidential Project board: Viewer (read-only)
  • All other boards: Member (can edit)

Removing Members

From Organization:

Requires: Organization Owner or Admin

1. Organization Settings → Members
2. Find member
3. Click "Remove" (🗑) button
4. Confirm: "Remove [Name] from organization?"
5. Warning: "They will lose access to all workspaces, projects, and boards."
6. Click "Remove Member"
7. Member removed immediately

What happens:

• User loses all organization access
• User's tasks remain on boards (not deleted)
• User's comments remain visible
• Activity history preserved
• User cannot log in to this organization

From Board Only:

Requires: Board Owner or Admin

1. Board Settings → Members
2. Find member
3. Click Role dropdown → "Remove from board"
4. Confirm removal
5. Member removed from this board only (still has org access)

Permission Scenarios

Scenario 1: Client Board with External Stakeholders

Requirement: Client needs to review deliverables but shouldn't see internal boards or edit anything.

Solution:

1. Create dedicated board: "Client A - Deliverables"
2. Add internal team as Board Members
3. Invite client as Guest with Viewer permission
4. Client sees:
   • ✅ This board only (not other org boards)
   • ✅ All tasks, comments, files (read-only)
   • ❌ Cannot edit or create tasks
   • ❌ Cannot see organization structure

Security: Client has zero visibility into other clients or internal projects.

Scenario 2: Department Lead Managing Team Boards

Requirement: Department lead needs to manage all department boards but not billing or organization settings.

Solution:

1. Create workspace: "Marketing Department"
2. Add all department boards to this workspace
3. Make department lead Workspace Admin (not Organization Admin)
4. Department lead can:
   • ✅ Create/delete boards within Marketing workspace
   • ✅ Manage members on Marketing boards
   • ✅ Configure board settings
   • ❌ Access other departments' workspaces
   • ❌ Change organization billing or settings

Scope: Permissions limited to Marketing workspace only.

Scenario 3: Contractor Needs Task Editing on One Board

Requirement: Contractor should edit tasks on project board but not see other company boards.

Solution:

1. Invite contractor as Guest (not organization member)
2. Add to specific project board
3. Set guest permission to Member (not Viewer)
4. Contractor can:
   • ✅ Create, edit, delete tasks on this board
   • ✅ Add comments and upload files
   • ❌ Manage board settings or members
   • ❌ See any other boards

Security: Contractor isolated to one board, full task capabilities within that scope.

Scenario 4: Audit/Compliance Team Needs Read-Only Access

Requirement: Compliance team needs to review all boards for audit but shouldn't make changes.

Solution:

1. Add compliance team as Organization Viewers
2. They can:
   • ✅ View all boards, tasks, comments
   • ✅ Export data for audit reports
   • ✅ Track activity across organization
   • ❌ Edit tasks or board settings
   • ❌ Invite members or change permissions

Use case: SOX compliance, security audits, executive oversight.

Security Best Practices

Principle of Least Privilege

Grant minimum permissions needed for role:

• Default to Viewer for new members, upgrade to Member if needed
• Avoid making everyone Admin (common mistake)
• Use Member role for 80% of users (can do their job without risk)
• Reserve Owner role for 1-2 people maximum

Review regularly:

• Quarterly permission audit (who has Admin/Owner?)
• Remove members who left company
• Downgrade roles when responsibilities change
• Check guest list for inactive collaborators

Sensitive Data Protection

For confidential boards:

1. Create dedicated workspace for sensitive work
2. Explicitly add members (don't rely on org-wide access)
3. Use Viewer role for non-essential people
4. Remove external guests when project completes
5. Enable audit logging (track who accessed what)
6. Archive boards when inactive (reduce exposure)

Example: M&A Project Board

• Board: "Confidential - Acquisition Target Review"
• Only invite: CEO (Owner), CFO (Admin), M&A Lead (Member)
• Do NOT: Add entire finance team or use Guest access
• After deal: Archive board and remove all members except CEO

Guest Access Security

When inviting external guests:

• ☑ Review board content first (remove internal strategy discussions)
• ☑ Use Viewer permission by default (upgrade to Member only if needed)
• ☑ Set expiration reminder (manual, until calendar feature available)
• ☑ Communicate data handling expectations (NDA, confidentiality)
• ☑ Remove guest access immediately when engagement ends
• ☑ Don't share credentials or API keys in guest-visible tasks

Guest data:

• Guests are isolated (only see invited boards)
• Guest comments visible to all board members
• Guest file uploads stored in board storage
• Guest activity logged in audit trail

Organization-Level Security

Organization Owners should:

• ✅ Enable two-factor authentication (2FA)
• ✅ Use strong, unique passwords
• ✅ Review member list monthly
• ✅ Monitor activity for anomalies
• ✅ Configure SSO (Single Sign-On) if available
• ✅ Set up billing alerts (prevent surprise charges)
• ✅ Document permission policies (who gets what role)

Do not:

• ❌ Share Owner credentials with anyone
• ❌ Make entire team Admins "just in case"
• ❌ Leave inactive members with access
• ❌ Ignore unusual activity (bulk deletes, late-night access)

Compliance Considerations

GDPR (General Data Protection Regulation)

If you have EU users or customers:

Right to Access:

• Users can view their data (boards they have access to)
• Export feature allows data download

Right to Erasure:

• When user leaves, delete their account (Organization Settings → Remove Member)
• Tasks/comments they created remain (attributed to "Deleted User")
• Personal data (name, email) removed

Data Minimization:

• Only invite guests when necessary
• Remove guest access when engagement ends
• Don't store customer personal data in task descriptions (use integrations)

Audit Trail:

• Activity feed logs all actions
• Export activity logs for compliance reporting

SOX (Sarbanes-Oxley)

For financial services companies:

Separation of Duties:

• Financial data entry: Member role (can create tasks)
• Approval workflow: Admin reviews, Owner approves
• Audit team: Viewer role (read-only access)

Audit Logging:

• Track who created, edited, deleted financial tasks
• Activity feed provides change history
• Export logs for quarterly audits

Access Controls:

• Restrict financial boards to authorized personnel only
• Review access quarterly
• Remove access when employee role changes

HIPAA (Healthcare)

For healthcare organizations:

Protected Health Information (PHI):

• Do NOT store PHI in task descriptions (use compliant systems)
• If PHI unavoidable, use encrypted file storage integration
• Limit board access to minimum necessary personnel

Access Logs:

• Track who viewed tasks with patient information
• Activity feed shows all board access
• Report access for audit purposes

Business Associate Agreements:

• External contractors (guests) need BAA before access to boards with PHI
• Waymaker provides BAA for enterprise customers (contact sales)

ISO 27001 / SOC 2

Information Security Management:

• Access Review: Quarterly permission audits
• Role Definition: Document what each role can do (use this guide)
• Incident Response: Monitor for permission escalations, unauthorized access
• Data Encryption: All data encrypted at rest and in transit

Audit Logging

Activity Feed as Audit Log

Every board action is logged:

Tracked events:

• ✅ Task created, edited, deleted (who, when, what changed)
• ✅ Comment added (who, when, content)
• ✅ Member added, removed, role changed
• ✅ Board settings changed
• ✅ File uploaded, downloaded (future), deleted
• ✅ Layer created, edited, deleted
• ✅ Board archived, restored

Accessing activity log:

1. Open board
2. Click Activity tab (right sidebar or bottom panel)
3. Filter by:
   • Date range
   • User (specific person's actions)
   • Event type (comments, task changes, member changes)
4. Export: "Export Activity" → CSV (future feature)

Retention:

• Activity logs retained for board lifetime
• If board deleted, activity log deleted (export first!)
• Archived boards preserve activity logs

Organization-Level Audit

Future feature (Enterprise plan):

• Organization-wide activity dashboard
• Track access across all boards
• Member login history
• Permission changes log
• Automated compliance reports

Current workaround:

• Export activity from each board individually
• Aggregate in spreadsheet for org-wide view
• Review Board Settings → Members quarterly

Troubleshooting Permission Issues

"User can't create tasks"

Possible causes:

• User has Viewer role (read-only)
• Guest with Viewer permission
• Board-specific override to Viewer

Solution:

1. Check board role: Board Settings → Members → Find user → Verify role
2. If Viewer: Change to Member
3. If Guest Viewer: Upgrade to Guest Member
4. If no board access: Add user to board

"User can see boards they shouldn't"

Possible causes:

• User has Organization-level role (access to all boards by default)
• User was explicitly added to board
• Permission inheritance from workspace/project

Solution:

1. Check organization role: Organization Settings → Members → Find user
2. If Organization Member: Create board-specific override (change to Viewer on sensitive boards)
3. Or remove from board entirely (Board Settings → Members → Remove)
4. Consider moving sensitive boards to restricted workspace

"Guest can't edit tasks"

Possible causes:

• Guest has Viewer permission (not Member)
• Guest permissions may be limited by board settings

Solution:

1. Board Settings → Guests → Find guest
2. Change permission from Viewer to Member
3. Guest can now create/edit tasks

"Admin can't delete board"

Expected behavior:

• Only Board Owners can delete boards
• This prevents accidental deletion

Solution:

1. Change Admin's role to Owner (Board Settings → Members)
2. Or ask current Owner to delete board
3. Deletion requires Owner role (safeguard)

Quick Reference

Five Roles:

• Owner: Full control, can delete
• Admin: Manage settings, cannot delete
• Member: Create/edit tasks
• Viewer: Read-only
• Guest: Board-specific, limited access

Permission Hierarchy:

• Organization → Workspace → Project → Board
• Lower level can override higher level
• Board-specific role overrides organization role

Change Organization Role:

• Org Settings → Members → Role dropdown → Select role

Change Board Role:

• Board Settings → Members → Role dropdown → Select role

Guest Permissions:

• Guest Viewer: Read-only on invited boards
• Guest Member: Edit tasks on invited boards
• Guests never see other org boards

Security Best Practices:

• Least privilege (default to Viewer, upgrade as needed)
• Regular audits (quarterly permission review)
• Remove inactive users
• Sensitive boards: Explicit member list, no org-wide access

Compliance:

• GDPR: Right to erasure, data export
• SOX: Audit trail, separation of duties
• HIPAA: No PHI in tasks, BAA required for contractors

Audit Logging:

• Activity feed logs all actions
• Export for compliance reporting
• Retained for board lifetime

Common Issues:

• Can't edit → Check role (Viewer vs Member)
• Can't delete board → Requires Owner role
• Sees wrong boards → Check org-level role + board overrides

---

Related Articles

• Inviting Team Members - Adding members with proper roles
• Guest Collaboration - External guest permissions
• Board Settings - Configuring board-level permissions
• Task Assignment and Ownership - Who can assign tasks
• Notifications and Mentions - Permission-based notifications

Next Steps

You now understand Waymaker's permission system! Ready to continue?

1. Inviting Team Members - Add members with appropriate roles
2. Guest Collaboration - Invite external guests securely
3. Board Settings - Configure board permissions

---

Need to change someone's role? → Board Settings → Members → Role dropdown