Roles and permissions control what each person can see and do inside AIUNIFY Call Center.
A role represents a person’s overall position within the platform. Permissions represent the individual actions that the person is authorized to perform.
For example, the Agent role may allow a user to view contacts and make calls but prevent that user from deleting contacts, changing billing settings, or managing other users.
AIUNIFY Call Center uses a structured role hierarchy to protect customer information, administrative settings, billing records, telephone configurations, and other sensitive areas of the platform.
The three primary roles are:
Each user should be assigned the role that most closely matches their responsibilities.
Every user account is connected to a role.
The assigned role contains a collection of permissions. When the user attempts to open a page or perform an action, AIUNIFY Call Center checks whether the user’s role contains the required permission.
For example:
A user may be able to view a section without being able to change its information. Viewing, creating, editing, deleting, executing, exporting, and managing are separate permissions.
The system uses the following hierarchy:
The Admin role has the highest level of authority.
Administrators manage the overall AIUNIFY Call Center platform, including customers, system settings, pricing, telephone numbers, verification records, reports, and platform-wide operations.
The Customer role represents a business, organization, or account owner using AIUNIFY Call Center.
Customers manage their own operational data, campaigns, contacts, agents, telephone settings, credits, and account information.
The Agent role represents a staff member who works under a Customer account.
Agents receive limited operational access based on the permissions assigned to the Agent role. Their access is intended primarily for calling, campaign execution, contact review, and related daily call center activities.
The hierarchy can be represented as:
Admin → Customer → Agent
An Admin oversees the platform. A Customer owns and manages a business account. An Agent works under that Customer.
To review the system’s roles:
Access to this section depends on the role and permissions of the signed-in user.
Administrators normally have the broadest access to role information. Customers and Agents may have limited access or may not see this menu option.
The Roles and Permissions page displays the roles currently configured in the system.
The default roles are:
Each role may display information such as:
The role description explains the intended purpose of the role.
The hierarchy level indicates the role’s position in the account structure.
The permissions count indicates how many individual actions are connected to the role.
The users count indicates how many accounts currently use that role.
The Admin role provides complete platform-level authority.
An administrator may be able to manage:
The Admin role receives all system permissions by default.
Because this role controls highly sensitive platform functions, administrator access should be assigned only to trusted platform operators.
A Customer or Agent should not be promoted to Admin simply to resolve a missing menu option. The correct permission or configuration issue should be identified instead.
The Customer role is intended for a business owner or organization using AIUNIFY Call Center.
A Customer owns the business data stored within their account and may manage the Agents working under that account.
The default Customer role includes broad access to the customer’s own operational resources.
Customers may generally:
Customers may generally:
Customers may generally:
Customers may generally:
Customers may generally:
Customers may generally:
Customers may generally:
Customers may generally:
Customers may generally:
The Customer role does not provide full platform administration. Customers cannot manage unrelated customer accounts, global pricing rules, platform-wide profit reports, or protected administrator settings.
The Agent role is intended for team members performing daily call center work under a Customer account.
Agents receive more limited access than Customers.
The default Agent role may allow the user to:
Agents are not normally permitted to:
The Agent role is designed to provide the tools necessary for operational work without exposing sensitive business or platform controls.
A permission authorizes one specific action.
Permission names usually contain two parts:
Module.Action
For example:
The first part identifies the system module.
The second part identifies the authorized action.
Common actions include:
Allows the user to open a section and review its information.
Allows the user to add a new record.
Allows the user to change an existing record.
Allows the user to remove a record.
Allows the user to perform an operational action, such as launching a campaign.
Allows the user to bring records into the system from a file.
Allows the user to download data or reports.
Provides broader control over a module or group of settings.
Limits the user to records connected directly to their account or activity.
Provides access to a broader collection of records within the authorized account scope.
Permission names are primarily system identifiers. The interface may display a more readable name and description.
Campaign permissions control access to outbound calling campaigns.
Common Campaign permissions include:
Allows the user to open the campaign list and review campaign details.
Allows the user to create a new campaign.
Allows the user to change campaign settings, messages, schedules, contacts, and related configuration.
Allows the user to permanently remove a campaign.
Allows the user to launch, pause, resume, or stop campaign execution.
Allows the user to review campaign statistics and performance reports.
An Agent may need View Campaigns and Execute Campaign permissions without needing Create, Edit, or Delete permissions.
Contact permissions control access to customer and prospect records.
Common Contact permissions include:
Allows the user to review contact records.
Allows the user to add contacts manually.
Allows the user to change contact information.
Allows the user to remove contact records.
Allows the user to upload contacts from a supported file.
Allows the user to download contact data.
Allows the user to organize contacts into lists.
Allows the user to apply and manage contact tags.
Agents commonly receive View Contacts permission but not full contact-management authority.
Call permissions control the ability to place calls and review calling activity.
Common Call permissions include:
Allows the user to open the Calls section.
Allows the user to place calls through the system.
Limits the user to calls connected to their own activity.
Provides broader call-record access within the authorized account.
Allows the user to listen to eligible call recordings.
Allows the user to download eligible call data or recordings when supported.
Call permissions do not replace telephone-number assignment. A user may have permission to make calls but still require an active and properly assigned telephone number.
Analytics permissions control access to dashboards, reports, campaign results, and call statistics.
Common Analytics permissions include:
Allows the user to access analytics pages.
Limits analytics to the user’s own activity.
Provides broader analytics access within the account.
Allows the user to download eligible reports.
Agents should normally receive only the analytics necessary to understand their own work.
Customers may require broader access to evaluate campaigns and team performance.
Administrators may access platform-wide reporting and financial analytics.
Agent-management permissions control how Customers and Administrators manage human call center representatives.
Common Agent permissions include:
Allows the user to open the Agents section.
Allows the user to add a new Agent account.
Allows the user to change an Agent’s information, password, status, or eligible settings.
Allows the user to remove an Agent account.
Allows the user to review or assign eligible access controls connected to Agents.
The current system primarily applies access through the main Agent role. Individual permission selections may appear during Agent creation or editing, but role-level permissions remain the primary source of authority.
User permissions are different from Agent permissions.
Agent permissions normally apply to team members working under a Customer.
User-management permissions may provide access to broader platform accounts, including Customers and other account types.
These permissions should normally remain restricted to Administrators.
Examples may include:
User impersonation allows an authorized administrator to enter another user’s account view for support or troubleshooting.
Impersonation should be used only for legitimate administrative purposes.
Settings permissions determine which configuration pages a user may access.
Common Settings permissions include:
Allows the user to review eligible settings.
Allows the user to update eligible settings.
Allows the user to configure telephone-provider credentials, webhook settings, geographical permissions, and calling configuration.
Agents generally receive only basic profile-view access.
Customers may manage their own account and telephone settings.
Administrators manage platform-wide configuration.
Billing permissions control access to balances, payments, credit history, and financial settings.
Common Billing permissions include:
Allows the user to review account billing information and transactions.
Allows the user to perform eligible billing actions, such as adding credits or managing payment-related settings.
Billing access should not be assigned to Agents unless their job specifically requires it.
Customer account owners should regularly review who has access to financial information.
Telephone-number permissions control access to available, requested, assigned, and active numbers.
Common Number permissions include:
Allows the user to review eligible telephone numbers.
Allows a Customer to submit a request for an available telephone number.
May allow an Administrator to configure, assign, revoke, release, price, or synchronize numbers.
Agents with View Numbers permission normally see only numbers assigned or made available to them.
KYC permissions control access to identity and business verification.
Common KYC permissions include:
Allows a user to review their verification status.
Allows a Customer to provide personal verification information.
Allows a Customer to provide business-verification information.
Allows an Administrator to review documents, approve submissions, reject submissions, and manage verification settings.
Agents generally receive only permission to view their own status.
To review a role:
The Role Details page is designed to display:
Each assigned permission may display its name and description.
Reviewing a role is useful when a user can access some features but not others.
AIUNIFY Call Center can group permissions according to their module.
The permission directory helps an administrator understand how available permissions are organized.
Permissions may be grouped under modules such as:
The modules displayed can vary as additional platform features are introduced.
A permission’s description explains what action it authorizes.
Admin, Customer, and Agent are built-in system roles.
The current source marks all three roles as protected system roles.
Protected roles are important because the application depends on them for:
Changing or deleting one of these roles could prevent users from accessing required features or could expose protected information.
For this reason, the standard role-update process prevents system roles from being modified.
The interface contains pages and controls for reviewing permissions and selecting permission checkboxes.
However, the current application logic applies two important restrictions:
Because Admin, Customer, and Agent are all protected system roles, an attempt to save changes to one of these roles may produce a message similar to:
This is an intentional protection in the current release.
The standard user interface also does not provide a complete create-and-delete workflow for custom roles.
Therefore, the Roles and Permissions section should currently be treated primarily as a role-review and access-reference area.
Roles are normally assigned during account creation.
Administrator accounts are created or promoted through protected administrative processes.
A new business account is normally assigned the Customer role.
An Agent created by an Administrator or Customer is assigned the Agent role.
Agents are also connected to a parent Customer account.
The role determines general access. The parent Customer relationship determines which business records the Agent is authorized to use.
A role should not be changed directly in the database unless the person performing the change fully understands the account relationships and authorization rules.
A permission does not automatically provide access to every record in the platform.
AIUNIFY Call Center also applies ownership and account-separation rules.
For example:
Effective access is therefore determined by:
Role + Permission + Record Ownership + Account Relationship
All four controls may affect whether a page or action is available.
The navigation menu may change according to the signed-in user’s role and permissions.
A missing menu option may indicate that:
A visible menu option does not always guarantee that every action inside the page is available.
For example, a user may be able to open Campaigns but may not be able to delete a campaign.
AIUNIFY Call Center also provides API functions.
API access does not automatically bypass role and permission requirements.
An authenticated API user may still be restricted according to:
API keys and tokens should be created only for authorized integrations.
Removing a permission or deactivating a user may affect both interface and API access.
Use the principle of least privilege.
This means assigning only the access a person needs to complete their work.
Administrators should remain limited to trusted platform operators.
Customer accounts should be used by business owners or authorized account managers.
Agent accounts should be created separately for each staff member.
Users should never share one account.
Do not assign billing or system-setting permissions to Agents unless absolutely necessary.
Deactivate accounts immediately when a staff member leaves the organization.
Review Agent access whenever responsibilities change.
Review administrator accounts regularly.
Require strong passwords and two-factor authentication where available.
Test access using a non-administrator account before deploying a new team workflow.
Document who is responsible for approving access changes.
Recommended role: Customer
Typical access:
Current recommended role: Customer or a carefully managed account structure
A supervisor may need broader operational access than an Agent but should not receive platform-wide Admin access.
Because the current release does not provide a complete custom-role workflow, the business should carefully evaluate the required access before choosing a role.
Recommended role: Agent
Typical access:
Recommended role: Admin
Typical access:
Confirm the user’s assigned role.
Review the permissions connected to that role.
Confirm that the account is Active.
Ask the user to sign out and sign back in.
Confirm that the feature is available to that role.
Viewing and editing are separate permissions.
Confirm that the role contains the required create, edit, delete, execute, or manage permission.
Confirm that both Agents are connected to the correct parent Customer.
Review the account relationship and Agent authorization rules.
Report unexpected cross-customer visibility immediately.
Confirm that the Agent belongs to the Customer.
Confirm that the Customer role has Agent-management permissions.
Confirm that the Agent account was not created under another Customer.
Confirm that the signed-in user is an Administrator.
Confirm whether the role is a protected system role.
Admin, Customer, and Agent are protected system roles in the current release and cannot be modified through the standard save process.
The interface and route configuration may not provide a complete editing workflow for protected roles in the current release.
Use the role details and permission directory for review.
Do not attempt direct database changes without a tested backup and developer review.
Confirm that the Agent has an assigned telephone number.
Confirm that the number supports voice calling.
Confirm that telephone-provider credentials are active.
Confirm that browser microphone permission is enabled.
Confirm that the Customer account has sufficient credits.
Ask the user to log out and log back in.
Clear the browser cache when necessary.
Role and permission information may be loaded when the user session begins.
Incorrect role or permission changes can expose:
Do not make direct database changes to roles, permissions, or user-role relationships without:
Protected system roles should not be deleted or renamed.
AIUNIFY Call Center uses roles and permissions to control platform access.
The role hierarchy consists of Admin, Customer, and Agent.
Administrators have platform-wide authority.
Customers manage their own business operations, campaigns, contacts, Agents, numbers, billing, and settings.
Agents receive limited access for daily calling and campaign work.
Permissions control individual actions such as viewing, creating, editing, deleting, executing, importing, exporting, and managing.
Access is also affected by record ownership and Customer-to-Agent relationships.
The three built-in roles are protected system roles. The current release allows their permissions to be reviewed, but the standard update process prevents those roles from being modified.
Careful role assignment protects customer information, financial records, call activity, telephone settings, and platform administration.