Customer Discovery Plan: Teams need role-based access controls to safely manage workflows and billing

Problem Statement

Team and enterprise users currently have no way to restrict access to workflows or billing settings, meaning every team member has full admin rights by default. This has led to documented incidents including junior members accidentally deleting workflows and unauthorized billing plan changes. The absence of role-based access controls is explicitly called out as a table-stakes enterprise requirement and a dealbreaker for some accounts considering adoption.

Evidence Summary

18 evidence items span Enterprise (10 HIGH, 2 MEDIUM), Mid-market (5 HIGH, 2 MEDIUM), and Team (2 HIGH, 1 MEDIUM) segments. Recurring pain points include: (1) inability to grant read-only access to workflows, cited by both Enterprise and Team users at HIGH and MEDIUM severity; (2) no admin-only workflow locking, flagged by Enterprise and Mid-market at HIGH and MEDIUM severity; (3) billing settings exposed to all team members, with one Mid-market HIGH report of an unauthorized billing plan change and Enterprise and Mid-market users flagging it as risky; (4) accidental workflow deletion by junior members, reported twice at HIGH severity by Mid-market; (5) blanket framing as 'table stakes' and an enterprise adoption blocker, cited directly in HIGH and MEDIUM Enterprise feedback. The concentration of HIGH-severity signals across multiple enterprise and mid-market accounts indicates this is not an edge case.

Priority Rationale

The signal scores 88/100 with high confidence, reflecting consistent, multi-segment evidence across 18 items. Enterprise and mid-market accounts, typically higher-value and higher-scrutiny customers, represent the majority of evidence and are explicitly naming this as a dealbreaker or adoption blocker. Billing exposure and accidental deletion are not hypothetical risks; they are documented incidents. Addressing this is prerequisite to unlocking enterprise deals and reducing churn risk in existing mid-market accounts.

Acceptance Criteria

• An admin can assign at least three distinct roles (e.g., Admin, Editor, Viewer) to individual team members, with each role having clearly scoped permissions over workflows and billing.
• A user with Viewer/read-only role can view workflow configurations and automation results but cannot edit, delete, or trigger changes to any workflow.
• Billing settings are accessible only to users with the Admin role; Editor and Viewer roles receive no access to billing plan modification or payment details.
• An admin can designate specific workflows as admin-only, preventing non-admin users from editing or deleting those workflows.
• When a non-admin user attempts an action outside their permission scope, they receive a clear, actionable error message explaining why access is denied and who to contact.

Hypothesis

If we introduce role-based access controls with at minimum a read-only viewer role, an editor role, and an admin-only billing and workflow lock, enterprise and mid-market teams will unblock adoption, reduce incidents of accidental workflow deletion and unauthorized billing changes, and convert or retain accounts that have flagged this as a dealbreaker.

Target Accounts

• ·Enterprise accounts that have explicitly flagged RBAC as a blocker or dealbreaker in feedback, particularly those citing billing exposure or full admin rights for all members
• ·Mid-market teams of 10–50 users who have experienced documented incidents of accidental workflow deletion or unauthorized billing changes
• ·Enterprise or mid-market accounts currently in a trial or evaluation phase who have not yet committed, where permissions may be the deciding factor
• ·Team-tier accounts with 15+ members who have requested granular permissions, as they represent a potential upgrade path to mid-market or enterprise tiers once controls are available

Discovery Questions

1. Can you walk me through the last time a team member took an action on a workflow or billing setting that they shouldn't have, what happened and what was the impact?
2. When you think about which people on your team need access to your automation workflows, what are the different types of access you would want to grant and to whom?
3. How are you currently working around the lack of permission controls, if at all, and how much time or risk does that workaround introduce?
4. If you could lock down billing access to only specific people, who in your organization would need that access and how would you decide?
5. Have you evaluated or switched to a competing tool specifically because it offered role-based access controls? What did that product's permission model look like?
6. When you say 'read-only access,' what exactly does that mean for your team, should a read-only user be able to see workflow logic, run history, outputs, or some combination?
7. What would need to be true about a permissions system for you to feel confident rolling this product out to your full team or recommending it to procurement?

Open Questions

1. Should permissions be configurable at the individual workflow level, the workspace/project level, or both, and do enterprise accounts require nested or inherited permission structures?
2. Is a three-tier role model (Admin, Editor, Viewer) sufficient for current enterprise needs, or do accounts require fully custom role definitions with granular permission toggles?
3. How should existing team members be migrated to roles at launch, defaulted to full admin rights to avoid disruption, or prompted to configure roles explicitly during onboarding?