Velvet's multi-creator workspace puts your entire roster behind one login with role-based access per creator. Owners, managers and closers each get exactly the scope their role requires, enforced by the platform on every request.
Access to a creator is a set of named grants: profile, content, wishlist, vault, messaging, CRM, PPV, analytics, team and settings. Somebody who maintains a wishlist gets the wishlist grant and nothing adjacent to it.
Each access relationship stores an immutable record of the permissions it was created with, and every lifecycle change is appended to an audit trail. What somebody could do last March is a fact you can read rather than an inference from what they can do now.
Staff move between the creators they are assigned to inside their own session, under their own identity. Nothing about the workspace requires a shared password, which is what makes attribution and accountability possible at all.
Access is granted per role and per creator: a manager may run two profiles and see nothing of the rest; a closer sees only the chats assigned to them within one profile.
Sensitive surfaces (account settings, payout configuration, channel connections) remain with the creator and the workspace roles explicitly trusted with them.
Staff move between the creators they are assigned to inside one session. No shared credentials, no password spreadsheets, no logging out and back in per profile.
Every action is performed by an identified team member under their own role, which is what makes attribution, commissions and accountability possible.
Being in the workspace and being able to act on a particular creator are stored separately on purpose. Membership answers who is inside the tenant and at what role; the access relationship answers which profiles they may touch and with which permissions.
That separation is what makes onboarding cheap and offboarding total. Adding a creator does not widen anybody automatically, and removing a person ends every relationship they held without anyone auditing a dozen creator accounts by hand.
An access relationship moves through pending approval, active, suspended and terminated, with the creator’s decision recorded as its own status. Invitations move through pending, accepted, expired and revoked alongside it.
Every one of those transitions is appended to an audit log rather than overwriting the previous state. When a dispute arrives, the question is which row says what, not whose recollection to believe.
Adding a creator adds a scoped section of the workspace; adding a team member is a role plus a set of assignments. Both are effective immediately.
When someone leaves, removing their access is a single change across every creator they touched: no password rotations across a dozen accounts.
No. The relationship starts pending the creator’s approval, carries only the permissions it was granted, and can be suspended or terminated. Ownership of the profile is a separate record that the access relationship hangs off rather than replaces.
Tenant resolution ignores suspended tenants, inactive agencies, pending members and revoked members. A relationship that is not active is not a slower path to the same data; it is no path.
Velvet refuses to resolve a tenant when more than one would qualify, rather than picking one. An ambiguous membership fails loudly instead of quietly acting against the wrong roster.
Yes. Creators remain the owners of their profiles. The workspace grants your team scoped operational access; settings, connections and payout details stay under the creator's control unless explicitly shared.
Yes. Access is assigned per creator, so someone can manage one profile while only chatting on another. Their effective permissions are always the ones scoped to the profile they are working in.
You remove the creator from the workspace and all team access to that profile ends at once. The creator keeps their account, their content and their fan relationships.
Ten named ones: profile, content, wishlist, vault, messaging, CRM, PPV, analytics, team and settings. Each is independent, so a grant can be as narrow as one task.
Yes. Access is per creator relationship, so somebody can manage one profile fully and only handle messaging on another. What applies is always the grant on the profile they are working in.
Seven days for a team invitation and fourteen for a creator access invitation. Both expire rather than sitting open indefinitely, so a forgotten invite is not a standing offer of access.
Yes. Permissions are snapshotted when a relationship is created and every lifecycle change is appended to an audit trail, so historical access is a record rather than a reconstruction.