Having recently undertaken a comprehensive evaluation of HeyGen for our revenue operations team, I've encountered a significant and, frankly, predictable challenge in the platform's workspace and permission architecture. Our initial goal was to segment access by function—sales enablement, marketing production, and corporate communications—each with distinct needs for template libraries, brand assets, and approval workflows. The implementation has resulted in a convoluted permission matrix that is hindering productivity and creating governance risks.
The core issue stems from the interplay between **Workspaces**, **Projects**, and **Team Roles**. While granular control is theoretically possible, the lack of a clear organizational principle leads to ad-hoc decisions. For example:
* We have individuals who require "Edit" access to a project's videos but should not have "Admin" capabilities on the workspace itself, yet they need to invite external stakeholders to specific folders.
* The inheritance rules between workspace-level permissions and project-level permissions are not intuitive, causing scenarios where users granted view-only at a high level still retain edit permissions in legacy projects.
* Managing a centralized brand asset library (logos, fonts, approved avatars) that is accessible across multiple workspaces, but with strict controls over who can modify these master assets, has proven cumbersome.
My primary question for the community revolves around structural best practices. Is it more sustainable to organize by **business function** (e.g., a "Sales Enablement" workspace, a "Demand Gen" workspace) or by **project lifecycle** (e.g., "Production," "Approval," "Archive")? The former aligns with budget ownership and team autonomy, while the latter may streamline permission sets but could cross operational boundaries.
Furthermore, I am keen to understand how others are handling:
* The delegation of administrative responsibilities without granting full super-admin privileges.
* The audit of permission sprawl, especially after several months of use and team member turnover.
* The integration of HeyGen's permission model with existing identity providers (e.g., Azure AD, Google Workspace) for consistent onboarding/offboarding.
The total cost of ownership for a tool like this is heavily influenced by administrative overhead and the risk of non-compliance with brand or data governance policies. I believe a strategic discussion on permission frameworks will benefit teams looking to scale their use beyond a single power user or small group.
1. I run revops for a mid-sized SaaS company, we have about 80 employees and our team uses HeyGen for all customer-facing video content. I manage our account and permissions directly.
2. - **Workspace Logic:** The structure is essentially flat. You can't have sub-teams or nested groups, which forces you to create separate workspaces for true segmentation. This gets expensive fast as you scale beyond the included seats.
- **Cost for Segmentation:** The per-seat pricing forces a trade-off. To properly segment Sales, Marketing, and Comms, you'd need three workspaces. At $30/user/month on the Business plan, that's $90/month for one person who legitimately needs access to all three, or you deal with the permission mess in one workspace.
- **Permission Inheritance:** It's not true inheritance. A workspace Admin can be set to "Viewer" on a specific project, but they can just change their own role back. The only way to lock it down is to not make them an Admin at all, which then limits their ability to manage the workspace settings you might want them to handle.
- **External Sharing:** The "Invite to folder/project" feature is the main tool for your use case, but it's clunky. You can't pre-define a role for external users; you have to set it each time. In practice, we just created a single "External Collaborator" team role and accept the over-permissioning.
3. I'd stick with HeyGen if your primary need is the AI video quality and speed, and you have a budget for separate workspaces. If granular, scalable permissions are the top priority, you should tell us your budget per seat and whether you use SSO, because that's where other platforms start to differentiate.
You've precisely identified the architectural flaw. The lack of intuitive inheritance between workspace and project roles creates a permanent state of exception handling. Your example about needing "Edit" at the project level without "Admin" at the workspace, yet requiring the ability to invite externally, is a classic case of a system that confuses a permission with a capability.
This is a design pattern problem. The "invite" function should be a discrete capability, separate from a monolithic "Admin" role, that can be attached at either the workspace or project level. Since it's not, you're forced to over-permission users at the workspace level to grant a single project-level action, which then breaks your intended containment.
I've modeled similar scenarios in Terraform, and the only stable approach becomes creating a separate "Collaboration" workspace purely for cross-functional projects requiring external users. It's a workaround that acknowledges the platform's rigid hierarchy.