Skip to main content

Common RBAC Scenarios

This guide provides real-world examples of how to set up and manage RBAC for different organizational needs and situations you'll encounter.

Team Onboarding Scenarios​

Scenario 1: Onboarding a New Software Developer​

Situation: Sarah is joining your development team as a mid-level developer.

Requirements:

  • Access to development projects
  • Ability to create and modify workflows
  • Collaboration with the development team
  • No access to production deployment or billing

Implementation:

  1. Assign Base Roles

    ✅ Project Developer (for assigned projects)
    ✅ Team Member (for Development Team)
    ❌ Project Admin (no deployment access needed)

  2. Set Up Team Access

    • Add Sarah to "Development Team"
    • Team automatically provides collaboration permissions
    • Team Lead can manage her day-to-day access needs

  3. Project-Specific Setup

    • Assign Project Developer role for "Mobile App" project
    • Assign Project Developer role for "API Integration" project
    • Leave out access to "Legacy Migration" project until needed

Result: Sarah can work on assigned projects, collaborate with team, but can't accidentally affect production systems.

Scenario 2: Promoting a Team Member to Team Lead​

Situation: Mike has been promoted from Developer to Team Lead for the Frontend Team.

Before:

Current Roles: Project Developer, Team Member

After Promotion:

New Roles: Project Admin, Team Lead, Team Member (keep for continuity)

Implementation Steps:

  1. Add Management Permissions

    • Assign Team Lead role for Frontend Team
    • Add Project Admin role for team's main projects
    • Keep Team Member role for continued collaboration

  2. Grant Additional Access

    • Deploy permissions for staging environments
    • Manage Team Members for the Frontend Team
    • Create Projects (for new frontend initiatives)

  3. Gradual Transition

    • Week 1-2: Add new permissions, keep old ones
    • Week 3-4: Mike practices with new responsibilities
    • Week 4+: Remove Project Developer from projects where he's now Project Admin

Result: Mike can manage his team and deploy to staging, while maintaining his technical access during the transition.

External Collaboration Scenarios​

Scenario 3: Working with External Contractors​

Situation: You're hiring a design agency to help with UI/UX for 3 months.

Requirements:

  • Access to design-related projects only
  • Ability to view and modify design assets
  • No access to code, deployments, or billing
  • Time-limited access that expires automatically

Implementation:

  1. Create Custom Role: "Design Contractor"

    • Project: Read, Write (for design projects only)
    • Workflow: Read (to understand user flows)
    • Knowledge Base: Read, Write (for design documentation)
    • Team: Read (to see team members)

  2. Set Up Contractor Users

    • Invite contractors with Design Contractor role
    • Expiration Date: Set to end of contract (3 months from now)
    • Project Scope: Only assign to "Web App Redesign" project

  3. Create Isolated Project

    • Set up "Web App Redesign" project
    • Visibility: Private (only visible to assigned team members)
    • Add contractors and internal design team members

Result: Contractors have exactly the access they need, with automatic expiration and no risk to other projects.

Scenario 4: Client Access for Project Review​

Situation: Your client wants to review project progress and provide feedback.

Requirements:

  • View project status and documentation
  • Comment on workflows and provide feedback
  • No ability to modify or deploy anything
  • Access only to their specific project

Implementation:

  1. Create Custom Role: "Client Reviewer"

    • Project: Read only
    • Workflow: Read only
    • Bot: Read only (to test interactions)
    • Knowledge Base: Read, Write (for feedback and comments)

  2. Set Up Client Access

    • Create user account for client contact
    • Assign Client Reviewer role for their project only
    • Set 6-month expiration (renewable)

  3. Configure Project Visibility

    • Set project visibility to "Private"
    • Add client user to project member list
    • Create dedicated "Client Feedback" knowledge base

Result: Client can review progress and provide feedback without risk of accidental changes.

Organizational Structure Scenarios​

Scenario 5: Multi-Department Company Setup​

Situation: You have Marketing, Sales, Engineering, and Operations departments, each needing different access patterns.

Department Structures:

Engineering Department​

👑 Engineering Manager: Workspace Manager + Team Lead
💻 Senior Developers: Project Admin + Team Member  
👨‍💻 Developers: Project Developer + Team Member
🆕 Junior Developers: Project Developer (limited projects) + Team Member

Marketing Department​

📈 Marketing Director: Workspace Manager + Team Lead
🎯 Campaign Managers: Project Admin (marketing projects) + Team Member
✍️ Content Creators: Project Developer (content projects) + Team Member
📊 Analysts: Project Viewer (all projects) + Export permissions

Operations Department​

⚙️ Operations Manager: Workspace Manager + Project Viewer (all)
🔧 DevOps Engineers: Project Admin + Deploy permissions
📋 Process Managers: Project Developer + Team Lead (process teams)

Implementation:

  1. Create Department Teams

    • Engineering Team, Marketing Team, Operations Team, Sales Team
    • Each team has appropriate Team Lead and Team Members

  2. Department-Specific Roles

    Engineering: Focus on technical project access
    Marketing: Campaign and content management focus
    Operations: Process optimization and deployment access
    Sales: Customer project visibility and reporting

  3. Cross-Department Projects

    • Create projects with mixed team access
    • Example: "Product Launch" project with Marketing + Engineering access
    • Use project-specific role assignments

Result: Each department has appropriate access while enabling cross-functional collaboration.

Scenario 6: Scaling Startup (10 to 100+ employees)​

Situation: Your startup is rapidly growing and you need to formalize access control.

Growth Phases:

Phase 1: Small Team (10-20 people)​

🔧 Founders: Workspace Admin
👑 Department Heads: Workspace Manager + Team Lead
👥 Everyone Else: Project Developer + Team Member

Phase 2: Medium Team (20-50 people)​

🔧 C-Level: Workspace Admin
👑 VPs/Directors: Workspace Manager + Team Lead
📋 Managers: Team Lead + Project Admin
👥 Individual Contributors: Project Developer + Team Member

Phase 3: Large Team (50+ people)​

🔧 Executive Team: Workspace Admin (limited)
🏢 Department VPs: Workspace Manager (department scope)
👑 Directors: Team Lead + Project Admin (multiple projects)
📋 Managers: Team Lead + Project Admin (specific projects)
👨‍💼 Senior ICs: Project Admin (individual projects)
👥 ICs: Project Developer + Team Member
🆕 New Hires: Project Viewer + Team Member (temporary)

Implementation Strategy:

  1. Start Simple (Phase 1)

    • Use mostly default roles
    • Focus on basic separation between admins and contributors

  2. Add Structure (Phase 2)

    • Create department-based teams
    • Introduce management hierarchy in roles
    • Add approval processes for sensitive operations

  3. Formalize Governance (Phase 3)

    • Regular access reviews
    • Formal onboarding/offboarding processes
    • Compliance and audit preparation

Project Lifecycle Scenarios​

Scenario 7: Project Development to Production​

Situation: Managing access as a project moves from development through staging to production.

Project Stages:

Development Stage​

👨‍💻 Developers: Project Developer (full access)
👀 Stakeholders: Project Viewer
🧪 QA Team: Project Developer (test workflows)

Staging Stage​

👨‍💻 Developers: Project Developer (continued development)
🚀 Tech Leads: Project Admin + Deploy (staging)
👀 Stakeholders: Project Viewer
✅ QA Team: Project Developer + Execute (run tests)
📋 Product Managers: Project Viewer + Export (data analysis)

Production Stage​

🔒 Production Team: Project Admin + Deploy (production)
📊 Monitoring Team: Project Viewer + Execute (monitoring workflows)
🆘 On-Call Engineers: Project Admin (incident response)
🚫 Developers: Project Viewer (read-only)

Implementation:

  1. Environment-Based Roles

    • Create separate roles for each environment
    • Example: "Staging Deployer", "Production Operator"

  2. Progressive Permission Removal

    • Developers lose write access to production
    • Only specialized roles can deploy to production
    • Maintain read access for troubleshooting

  3. Incident Response Access

    • Emergency procedures to grant temporary production access
    • Time-limited elevated permissions during incidents
    • Audit trail of emergency access grants

Scenario 8: Temporary Project Access​

Situation: Setting up access for time-limited projects like marketing campaigns or seasonal initiatives.

Project: "Black Friday Campaign" (November 1 - December 15)

Team Structure:

📈 Campaign Manager: Project Admin (until Dec 15)
🎨 Design Team: Project Developer (until Nov 30)  
📊 Analytics Team: Project Viewer + Export (until Dec 31)
🛍️ E-commerce Team: Project Developer (until Dec 15)

Implementation:

  1. Time-Limited Role Assignments

    • Set expiration dates on all role assignments
    • Stagger expirations based on team involvement
    • Plan for access extension if project continues

  2. Resource Cleanup

    • Schedule project archival after campaign ends
    • Transfer important assets to permanent storage
    • Remove temporary users from workspace

  3. Knowledge Transfer

    • Document lessons learned before access expires
    • Export important data and configurations
    • Plan for future similar campaigns

Security and Compliance Scenarios​

Scenario 9: Compliance-Heavy Environment​

Situation: You're in a regulated industry requiring strict access controls and audit trails.

Compliance Requirements:

  • Segregation of duties
  • Regular access reviews
  • Approval workflows for sensitive operations
  • Complete audit trails

Implementation:

  1. Segregation of Duties

    🚫 No single person can:
    - Create and approve workflows
    - Deploy and monitor production systems
    - Access billing and deploy systems

  2. Approval Workflows

    • Production Deployment: Requires approval from different team
    • Data Export: Needs data protection officer approval
    • User Role Changes: Manager approval required

  3. Regular Reviews

    • Monthly: Review all role assignments
    • Quarterly: Full permission audit
    • Annually: Role definition review

  4. Audit Features

    • Enable detailed logging for all permission checks
    • Regular reports on access patterns
    • Documentation of all role changes

Scenario 10: Security Incident Response​

Situation: A security incident requires immediate access changes and investigation.

Incident Response Plan:

  1. Immediate Actions

    ⚠️ Suspend affected user accounts
    🔒 Remove sensitive permissions from potentially compromised roles
    📋 Grant temporary investigator access to security team
    📊 Enable enhanced logging and monitoring

  2. Investigation Access

    • Create temporary "Security Investigator" role
    • Grant read access to all projects and audit logs
    • Time-limited (48-72 hours) with approval for extensions

  3. Recovery Process

    • Review and restore legitimate user access
    • Update role definitions based on lessons learned
    • Implement additional controls if necessary

  4. Post-Incident

    • Full review of access patterns before incident
    • Update security procedures and role definitions
    • Enhanced monitoring for similar patterns

Integration and Automation Scenarios​

Scenario 11: HR System Integration​

Situation: Automatically managing user access based on HR system data.

Integration Goals:

  • Automatic role assignment based on job title
  • Access updates when employees change roles
  • Automatic access removal when employees leave

Implementation:

  1. Role Mapping

    HR Job Title → Workspace Platform Roles
    "Software Engineer" → Project Developer + Team Member
    "Engineering Manager" → Project Admin + Team Lead
    "Product Manager" → Project Viewer + Export permissions

  2. Automation Rules

    • New hire: Automatically assign roles based on department/title
    • Role change: Update permissions to match new position
    • Termination: Immediate access removal with resource transfer

  3. Exception Handling

    • Manual override capability for special cases
    • Approval workflow for non-standard role assignments
    • Regular audit of automated assignments

Best Practices from These Scenarios​

1. Start Conservative​

  • Begin with minimal permissions and add as needed
  • Use time-limited access for new or temporary situations
  • Regular reviews to ensure access is still appropriate

2. Plan for Growth​

  • Design role structure that scales with your organization
  • Use team-based permissions to simplify management
  • Create templates for common scenarios

3. Document Everything​

  • Keep records of why specific permissions were granted
  • Document role definitions clearly
  • Maintain an audit trail of access changes

4. Regular Reviews​

  • Monthly reviews for active projects
  • Quarterly reviews for all user access
  • Annual reviews of role structure and policies

5. Automate Where Possible​

  • Use bulk operations for similar users
  • Implement automated expiration for temporary access
  • Integrate with HR systems for lifecycle management

Next Steps: If you're facing a situation not covered here, check our troubleshooting guide or contact support. For technical implementation of these scenarios, see the SDK documentation.