Understand workspace roles and permissions

Role model in the product

Settings displays three workspace roles:

Member is the customer-facing access role in WRKZY. “Operator” describes day-to-day customer work, not a separate permission level. Organization membership is a separate scope: a person may belong to the organization but still require membership in a particular workspace.

Important boundaries verified in WRKZY

• An Owner can invite Members or Admins and transfer ownership to another active member.
• An Admin can invite and manage Members, but cannot promote someone to Admin, manage another Admin, or change the Owner.
• A user cannot change their own workspace membership through member administration.
• Only the Owner can open full-IP authentication Session logs.
• Owners and Admins manage channel connections, shared workspace templates, AI controls, business defaults, and other administrative domains.
• Team-inbox roles—Manager, Member, and Viewer—are separate from workspace roles and control queue-level visibility and responsibility.
• Automation approval and lifecycle controls have their own release rules; Member editors request approval when required.

Choose a role from tasks

1. List the recurring tasks the person must perform.
2. Grant Member if the tasks are customer/CRM work inside assigned boundaries.
3. Grant Admin only if they must change workspace settings or manage Members.
4. Keep Owner singular and accountable; transfer it only through a planned handover.
5. Configure restricted team-inbox membership after the workspace role.
6. Test access with the person and remove unnecessary elevation.

A missing button can result from the wrong workspace, restricted inbox, unavailable feature state, or owner-only control. Do not promote someone to Admin until the actual boundary is identified.

Access-review questions

Can each Admin name the settings they own? Does every restricted inbox have current members? Are disabled users still owners of active work? Does the Owner use MFA and review sessions? Is a service process depending on one person's private mailbox? Are automation approvers still appropriate?

Open full size

Offboarding and role changes

Before disabling or demoting a user, reassign conversations, deals, tasks, follow-ups, inbox roles, automation ownership, approval requests, and channel responsibility. Transfer ownership before the current Owner leaves. Then review sessions and administrative change history.

Recovery

If access is too broad, reduce it only after preserving business ownership. If access is too narrow, identify the exact task and grant the narrow workspace or inbox permission. For suspected unauthorized elevation, preserve actor, target, old/new role, time, and change-history evidence; the Owner can review authentication audit. Never share passwords or session tokens.