Permissions
Permissions are granular privileges that control what actions users can perform on specific modules. Each permission follows a "module_action" format (e.g., "contacts_view", "campaigns_create") and determines whether a user can view, create, edit, delete, or export data within a module. Permissions are assigned to roles, and users inherit permissions through their assigned roles.
Understanding Permissions
Permissions are the building blocks of access control. They define specific actions that can be performed on modules.
Permission Format
Permissions follow the format "module_action" (e.g., "contacts_view", "campaigns_create"). The module name comes first, followed by an underscore and the action name.
Permission Types
Common permission types include view, create, edit, delete, and export. Each module can have different permission types based on its functionality.
Permission Types
Each module typically has five standard permission types that control different levels of access:
View
Purpose: Read-only access to module data
Example: "contacts_view" allows users to see contacts but not modify them. This is typically the minimum permission required to access a module.
Create
Purpose: Ability to create new records
Example: "campaigns_create" allows users to create new campaigns. Typically requires view permission as well.
Edit
Purpose: Ability to modify existing records
Example: "contacts_edit" allows users to update contact information. Usually requires view permission.
Delete
Purpose: Ability to remove records
Example: "campaigns_delete" allows users to delete campaigns. Use with caution - restrict to senior roles.
Export
Purpose: Ability to export data
Example: "contacts_export" allows users to download contact lists. May contain sensitive information - restrict appropriately.
Typical Permission Matrix
Different roles typically need different permission combinations. Here are common examples:
Common Permission Patterns
Sales Team
- Contacts: view, edit, create, export (full access to manage contacts)
- Campaigns: view, create, edit (can run campaigns but not delete)
- Calls: view (can see call history)
- Templates: view (can use templates but not modify)
Support Team
- Contacts: view, edit (can update contact information)
- Calls: view, edit (can review and update call records)
- Appointments: view, create, edit (can manage appointments)
- Templates: view (can use templates)
Billing Team
- Billing: view, edit (can manage billing settings)
- Wallet: view, refill (can view and refill wallet)
- Subscriptions: view (can view subscription information)
- Payment Methods: view, edit (can manage payment methods)
Analyst/Reporting
- Dashboard: view (can access analytics)
- Calls: view, export (can analyze and export call data)
- Campaigns: view (can review campaign performance)
- Contacts: view, export (can analyze and export contact data)
Read-Only Client
- Dashboard: view (can see analytics)
- Calls: view (can review call history)
- Campaigns: view (can see campaign status)
- Contacts: view (can see contact information)
- No create/edit/delete: Cannot modify anything
How Permissions Work
Understanding the permission flow helps you configure access control effectively.
Permission Flow
- Modules Define Features: Each module (Contacts, Campaigns, Billing, etc.) represents a feature area with associated permissions.
- Permissions Control Actions: Each module has permissions for actions (view, create, edit, delete, export).
- Roles Group Permissions: Roles are created and assigned specific permissions from various modules.
- Users Get Roles: Users are assigned roles, which grant them all permissions contained in those roles.
- Access is Checked: When a user tries to perform an action, the system checks if they have the required permission through their assigned roles.
Example: When a user tries to create a campaign, the system checks if they have "campaigns_create" permission through any of their assigned roles. If they do, the action is allowed. If not, access is denied.
Best Practices
Permission Assignment
- Use Roles, Not Direct Permissions: Always assign permissions to roles, not directly to users. This simplifies management and ensures consistency.
- Start with View: Most roles only need view permissions initially. Add create/edit permissions only when necessary.
- Least Privilege: Grant the minimum permissions necessary for a role to function. It's easier to add permissions than to remove them.
- Document Powerful Permissions: When granting delete or export permissions, document why they're needed. This helps with audits and future reviews.
Security Considerations
- Restrict Destructive Actions: Delete and export permissions should be limited to senior roles. These actions can have significant consequences.
- Review Regularly: Periodically review permission assignments to ensure they still match current needs. Remove unnecessary permissions.
- Monitor Usage: Track which permissions are actually being used. Remove unused permissions to reduce attack surface.
- Separate Concerns: Don't grant billing permissions to sales teams, or campaign delete permissions to analysts. Keep permissions aligned with job functions.
Permission Management
- Group by Function: Organize permissions by job function rather than by individual needs. This makes role creation easier.
- Use Consistent Patterns: Follow consistent permission patterns across modules. If a role needs to edit contacts, it probably needs to edit campaigns too.
- Test Before Deploying: Test permission changes in a test environment before applying to production. Verify that users can still perform necessary actions.
- Document Changes: When modifying permissions, document why changes were made for future reference and audits.
Troubleshooting
Permission appears assigned but not working
Checklist:
- Verify role assignment: Confirm the user actually has the role assigned. Check the Users management interface.
- Check permission name: Ensure the permission name matches exactly (e.g., "contacts_view" not "contact_view"). Permission names are case-sensitive.
- Workspace context: If using workspaces, verify the role is assigned in the correct workspace. Permissions are workspace-scoped.
- Cache refresh: Permission changes may require a cache refresh. Try logging out and back in, or clear the application cache.
- Check for conflicts: Ensure there are no conflicting permissions or role restrictions that might override the expected behavior.