Skip to main content

Managing Permissions

Permissions define what actions users can perform on specific resources. This guide explains how to work with permissions, assign them to roles, and manage fine-grained access control in the Workspace platform.

Understanding Permissions​

Permissions are specific actions that can be performed on resources in the Workspace platform. They work together with roles to provide granular access control.

Permission Structure​

Every permission follows a consistent pattern:

  • Resource Type: What the permission applies to (workspace, project, team, etc.)
  • Action: What can be done (read, write, delete, deploy, etc.)
  • Scope: Where the permission is valid (specific workspace, project, etc.)

Permission Categories​

Standard Permissions (Available for All Resources)​

  • Read: View resource details and contents
  • Write/Update: Modify resource settings and contents
  • Delete: Remove the resource entirely
  • All: Complete control over the resource

Resource-Specific Permissions​

Each resource type has specialized permissions:

Workspace Permissions:

  • Invite Users: Add new members to the workspace
  • Manage Roles: Create and modify role definitions
  • Manage Members: Add/remove workspace members
  • View Billing: Access billing and usage information

Project Permissions:

  • Deploy: Push workflows and bots to production
  • Export: Download project data and configurations
  • Create Child Resources: Make new workflows, bots, or knowledge bases

Team Permissions:

  • Add Members: Invite users to join the team
  • Remove Members: Remove users from team membership
  • Manage Team Settings: Configure team properties

Accessing Permission Management​

  1. Navigate to Settings

    • Click your workspace name in the top navigation
    • Select "Settings" from the dropdown

  2. Open Roles & Permissions

    • Click "Roles & Permissions" in the settings sidebar
    • Select the "Permissions" tab

Here you'll see all available permissions organized by resource type.

Working with Permission Categories​

Basic Permissions​

These are the foundation permissions that almost all roles need:

Read Permissions​

  • Who needs it: Everyone who needs visibility into resources
  • Common use: Allow team members to see project status, team members, workspace information
  • Safe to grant: Generally low-risk permissions

Write/Update Permissions​

  • Who needs it: Active contributors who modify resources
  • Common use: Developers updating workflows, managers modifying team settings
  • Consider carefully: These permissions allow changes to important resources

Delete Permissions​

  • Who needs it: Senior team members, administrators
  • Common use: Cleaning up old projects, removing obsolete workflows
  • Grant sparingly: Deletion is usually irreversible

Management Permissions​

These permissions control access to administrative functions:

Create Permissions​

  • Projects: Who can start new projects
  • Teams: Who can form new teams
  • Resources: Who can add workflows, bots, etc. to projects

Member Management​

  • Invite Users: Who can add people to workspace/teams
  • Remove Members: Who can remove access
  • Manage Roles: Who can assign roles to others

Advanced Operations​

  • Deploy: Who can push changes to production
  • Export: Who can download sensitive data
  • Archive: Who can deactivate resources

Permission Assignment Strategies​

Instead of assigning permissions directly to users:

  1. Create or Select a Role

    • Go to the "Roles" tab
    • Either create a new role or edit an existing one

  2. Add Permissions to the Role

    • In role editing, browse available permissions
    • Select permissions that make sense together
    • Example: "Project Developer" might need:
      • Project: Read, Write
      • Workflow: Read, Write, Create
      • Bot: Read, Write, Create

  3. Assign Role to Users

    • Go to "User Assignments" tab
    • Assign the role to appropriate users

Direct Permission Assignment (Use Sparingly)​

For exceptional cases, you can assign permissions directly:

  1. Go to User Assignments

    • Find the specific user
    • Click "Manage Direct Permissions"

  2. Select Specific Permissions

    • Choose individual permissions
    • Set expiration dates for temporary access
    • Document why direct assignment was necessary

  3. Apply Changes

    • Save the direct permission assignments
    • Note: These override role-based permissions
warning

Best Practice: Use direct permissions only for temporary access or highly specific needs. Role-based permissions are much easier to manage at scale.

Permission Inheritance and Hierarchy​

Resource Hierarchy​

Workspace Platform follows a logical hierarchy:

Workspace
├── Team
├── Project
│   ├── Workflow
│   ├── Bot
│   └── Knowledge Base
└── Billing Account

How Inheritance Works​

Parent-to-Child Permissions​

  • Workspace permissions often apply to projects within that workspace
  • Project permissions may affect workflows and bots in that project
  • Team permissions cascade to all team members

Create Permissions​

  • Create Project permission at workspace level allows project creation
  • Create Workflow permission at project level allows workflow creation
  • These are granted by the parent resource, used on the child resource

Permission Checking Order​

When a user tries to perform an action in the Workspace platform:

  1. Check direct permissions on the resource
  2. Check role permissions on the resource
  3. Check team role permissions
  4. Check parent resource permissions (if applicable)
  5. Check visibility rules

Advanced Permission Concepts​

Time-Limited Permissions​

For temporary access needs in the Workspace platform:

  1. Set Expiration Dates

    • When assigning roles or direct permissions
    • Choose end date and time
    • System automatically revokes access

  2. Common Use Cases

    • Contractor access for specific projects
    • Temporary admin permissions for migrations
    • Intern access during internship periods

  3. Managing Expiration

    • Users get notified before permissions expire
    • Admins can extend or revoke early
    • Expired permissions can be renewed if needed

Conditional Permissions​

Some permissions have additional requirements:

Approval-Based Permissions​

  • Deploy: Might require approval from team lead
  • Export: Could need data protection officer approval
  • Delete: May require confirmation from project owner

Resource State Permissions​

  • Archive: Only works on inactive projects
  • Deploy: Only available for tested workflows
  • Export: May be restricted during maintenance windows

Permission Scoping​

Workspace-Scoped Permissions​

  • Apply to the entire workspace
  • Usually for administrative functions
  • Examples: Invite Users, Manage Billing, Create Projects

Resource-Scoped Permissions​

  • Apply to specific projects, teams, or other resources
  • More granular control
  • Examples: Edit "Project Alpha", Deploy "Marketing Workflow"

Custom Scoped Permissions​

  • Apply to specific subsets of resources
  • Examples: All projects in "Development" team, All workflows tagged "Production"

Permission Troubleshooting​

User Reports They Can't Access Something​

Check Permission Assignment​

  1. Verify User Roles

    • Go to User Assignments
    • Confirm user has expected roles

  2. Check Role Contents

    • Review what permissions each role contains
    • Ensure necessary permissions are included

  3. Test Direct Permissions

    • Check if user has any direct permission overrides
    • Direct permissions can sometimes conflict with role permissions

Check Resource Hierarchy​

  1. Verify Resource Level

    • Ensure permissions are assigned at the right level
    • Workspace permissions don't automatically grant project permissions

  2. Check Parent Resource Access

    • User might need permissions on parent resource first
    • Example: Need workspace access to see projects within it

Review Visibility Settings​

  1. Resource Visibility

    • Resource might be private or team-only
    • Check visibility settings separate from permissions

  2. Team Membership

    • If resource is team-visible, user must be team member
    • Add user to appropriate team or change visibility

Permission Changes Not Taking Effect​

Browser and Cache Issues​

  • Refresh the page: Simple but often effective
  • Clear browser cache: Old permission data might be cached
  • Try incognito mode: Rules out browser-specific issues

System Propagation​

  • Wait a few minutes: Permission changes need time to propagate
  • Check server status: Ensure all systems are operational
  • Log out and back in: Forces fresh permission loading

Too Many Permission Requests​

This usually indicates permission structure issues:

Review Role Design​

  • Roles too restrictive: Consider broader permissions for common use cases
  • Missing create permissions: Users can't make resources they need
  • Hierarchy problems: Permissions assigned at wrong levels

Improve Self-Service​

  • Team-based permissions: Let team leads manage their own members
  • Clearer documentation: Help users understand what they can do
  • Request workflows: Streamline permission request processes

Permission Security Best Practices​

Least Privilege Principle​

  • Start with minimal permissions
  • Add permissions only when demonstrated need arises
  • Regularly audit and remove unused permissions

Separation of Duties​

  • Don't give one person all critical permissions
  • Require multiple people for sensitive operations
  • Use approval workflows for high-risk actions

Regular Access Reviews​

  • Monthly review of user permissions
  • Quarterly audit of role definitions
  • Annual assessment of permission structure

Documentation and Communication​

  • Document why specific permissions were granted
  • Communicate permission changes to affected users
  • Maintain clear guides for common permission requests

Permission Templates and Patterns​

Common Role Permission Patterns​

Developer Role Template​

  • Project: Read, Write
  • Workflow: Read, Write, Create
  • Bot: Read, Write, Create
  • Team: Read (to see team members)

Manager Role Template​

  • Project: Read, Write, Deploy
  • Team: Read, Write, Add Members
  • Workspace: Read, Create Projects
  • Billing: Read (for budget visibility)

Viewer Role Template​

  • Project: Read
  • Workflow: Read
  • Bot: Read
  • Team: Read
  • Workspace: Read

Industry-Specific Templates​

Software Development Team​

  • Tech Lead: Full project + team management
  • Senior Developer: Development + limited deployment
  • Junior Developer: Development only
  • QA Engineer: Read + test execution permissions

Marketing Team​

  • Marketing Director: Campaign management + team oversight
  • Campaign Manager: Campaign creation + execution
  • Content Creator: Content modification only
  • Analyst: Read-only + export permissions

Next Steps: Learn how to manage users and assign permissions, or explore common scenarios to see these permission patterns in action.