Skip to main content
Bizzy uses a role-based access control system to manage what team members can see and do within your organization. This guide explains the permission model and how to configure access for your team.

​
Role Types

Every organization member has one of three roles:
Each organization must have at least one Owner. Ownership can be transferred but not removed entirely.

​
Permission Model

Bizzy’s permission system is built on three core concepts:

​
1. Actions

Every permission check evaluates one of three actions:

​
2. Resources

Resources are organized hierarchically using dot notation. For example:

​
3. Inheritance

Permissions flow from parent to child resources. If you grant read access to contacts, that permission automatically applies to contacts.emails, contacts.phones, and all other child resources—unless explicitly overridden.

​
Role Permissions

​
Owner Permissions

Owners have unrestricted access to all resources:

​
Admin Permissions

Admins have full data access with limited administrative capabilities:

​
User Permissions

Users have read-only access to organization data with full control over their own resources:

​
Resource Categories

The permission system covers these top-level resources:

​
Contact and customer data

  • contacts — Contact records (children: emails, phones, addresses)
  • customers — Customer relationships (children: transactions)
  • businesses — Business entities (children: offerings, onlinePresences, physicalPresences, profiles)
  • domains — Verified and registered domains (children: domainContacts, domainRegistrations)

​
Communication

  • messages — Conversation threads (children: attachments, contacts)
  • incomingMessages — Inbound message records (children: attachments, contacts)
  • outgoingMessages — Outbound message records (children: attachments, contacts)
  • emailTemplates — Reusable email templates

​
Tasks and automations

  • tasks — Tasks (children: assignees, activity)
  • automations — Plain-English automations

​
Files and knowledge

  • files, folders — Uploaded files and the folder tree
  • resources, embeddings — RAG-indexed assets used by agents

​
Organization administration

  • organization — Org-level settings, with children:
    • members — Team membership
    • invites — Pending invitations
    • connections — Integration connections (Stripe, etc.)
    • subscriptions — Billing and subscription
    • workflows — Internal workflow registry
    • apiKeys — Owner-only API key management

​
User-level resources

  • userNotifications — Personal notification preferences and history
  • userProfiles — Personal profile (name, avatar, timezone, language)

​
API Key Permissions

API keys have their own independent permission system — they do not inherit the permissions of the user that created them. When you create a key, you grant it specific resource access and restrict it to specific actions. This means a User-role team member can still create an API key with broader permissions than they themselves have, provided their role allows key creation in the first place (currently Owner-only). See API Key Management for details.

​
Best Practices

​
Principle of Least Privilege

Assign the minimum role needed for each team member:
  • Use User role for team members who only need to view data
  • Use Admin role for managers who need to edit data and invite members
  • Reserve Owner role for account administrators

​
Regular Access Reviews

Periodically review your organization’s members:
  • Remove inactive members promptly
  • Verify role assignments match current responsibilities
  • Check for any unused API keys

​
Separation of Duties

For sensitive operations, consider:
  • Limiting Owner role to 1-2 trusted administrators
  • Using separate API keys for different integrations
  • Enabling audit logging to track changes

​
Next Steps

User Management

Learn how to invite and manage team members

API Keys

Create API keys with custom permissions
Last modified on May 30, 2026