The AIUNIFY Call Center Dashboard is the main operational summary page displayed after login.
It combines:
The Dashboard changes according to the signed-in user’s role:
The system prepares Dashboard statistics, recent Campaigns, recent Calls, Call-chart data, and Campaign-status data each time the Dashboard route is loaded.
The Dashboard is available at:
It normally opens automatically after a successful login.
To return to the Dashboard:
The same Dashboard route determines which view to display by checking whether the user is an:
A Customer should not see the Administrator’s system-wide statistics.
An Agent should not see Customer billing, team-management, or platform-administration information.
The authenticated header contains:
These controls remain available across authenticated pages because they are part of the main application layout.
The Sidebar control expands or collapses the main navigation.
On smaller screens, it opens the Sidebar as a mobile navigation panel.
Breadcrumbs identify the current location.
On the Dashboard, the breadcrumb normally displays:
On deeper pages it can display a path such as:
The Dashboard greeting changes according to the browser’s local clock:
Example:
The greeting uses the browser’s local time.
Dashboard statistics are calculated by the Laravel server, whose current application Time Zone is:
This can create a difference near midnight.
Example:
The greeting may still say Good evening, while the Dashboard’s Today Call count is already using the next UTC date.
The Dashboard is a snapshot of application data at the time the page is loaded.
It does not contain automatic repeating polling for:
To obtain updated statistics:
For live Campaign activity, use the Campaign or Call pages rather than relying only on the Dashboard.
A Customer sees a greeting and a message similar to:
The heading also contains:
which opens:
When KYC is enabled and the Customer is unverified, the Dashboard can display:
or:
The nonexpired warning can be dismissed for the current browser session.
The expired warning cannot be dismissed through the same close control.
As explained in Chapter 2, the displayed KYC grace period does not currently override the backend’s approved-KYC requirement on protected routes.
The Campaigns Card displays:
The total count includes all nondeleted Campaign records owned by the Customer, regardless of Campaign Status.
The current Campaign model uses:
It does not use:
as the normal running Status.
However, the Dashboard controller currently calculates Active Campaigns using:
Therefore, the Active Campaign count can display:
even when one or more Campaigns are actually:
The correct current Campaign statuses are:
The Dashboard’s use of Active is an older or inconsistent status reference.
For the authoritative Campaign Status, open:
The Contacts Card displays:
The total is based on Contact records owned by the Customer.
The active count includes Contacts whose Status is:
The Customer Dashboard correctly supplies the active Contact count, but the descriptive text reuses the translation intended for:
The Card can therefore display wording similar to:
even though 35 represents active Contacts.
The numeric value is the active Contact count; the wording is incorrect in the current interface.
The Total Calls Card displays:
The Today period is calculated using the server date.
The My Team Card counts User records whose:
matches the Customer.
The interface describes the value as active Agents, but the current query does not filter by:
Therefore, the Card is more accurately interpreted as:
rather than a guaranteed count of active Agents.
The Customer Dashboard displays:
Today counts Call records whose creation date matches the Laravel server’s current date.
This Week counts Call records between:
This Month counts Call records whose month and year match the server’s current month and year.
These Cards count Call database records.
They do not necessarily count only successful conversations.
Depending on how Calls were created, the count can include:
The Customer Dashboard filters Call records using:
Calls stored directly under an Agent User ID are not included in that Customer query.
Use the Call History and Agent reporting pages when comparing team performance.
The My Numbers Card counts Phone Number records whose:
matches the Customer account.
The Card provides:
which opens:
Pending Requests counts the Customer’s Number Request records whose Status is Pending.
The Card provides:
which opens the available-number section.
Call Trends covers:
The backend fills missing dates with zero values so all seven dates appear.
The green portion counts Calls with:
The red portion combines:
The chart’s total value includes all Calls created on the date.
However, only Completed and the three listed failure statuses receive visible green or red bars.
Statuses such as:
can contribute to the day’s total and chart scaling without appearing as a colored result bar.
Use Call Trends to identify broad patterns.
Do not use the chart alone to calculate an exact answer rate.
For exact results, review:
The Dashboard’s Campaign Status Card displays:
The current model also supports:
but these categories are not displayed separately in the Dashboard Card.
Because the Card looks for active instead of running, a running Campaign can be omitted from the visible summary.
Use:
to determine whether a Campaign is actually:
The Dashboard controller retrieves the five newest Campaigns owned by the Customer.
The Card displays:
A View All button opens the full Campaign list.
The recent Campaign list uses the Campaign’s stored:
value.
This should not automatically be interpreted as:
The Dashboard retrieves up to ten newest Customer Call records, but the visible Card displays the first five.
Each item displays:
The Customer Card does not display the Call date, even though the backend supplies it.
Duration is displayed as:
A missing or zero duration displays:
This can represent a failed or unconnected Call rather than an actual zero-second conversation.
The Dashboard assigns special Badge styles to:
Other statuses receive the default secondary Badge style.
The Agent Dashboard interface is designed to display:
The available actions are:
Opens:
Opens:
Currently points to:
No matching route exists in the installed route list.
Use:
or open:
instead.
The Dashboard controller currently sends these Agent statistics:
The Agent Dashboard interface expects:
These field names do not match.
Agent Dashboard Cards can display:
for Available Work and Call Performance.
This is a current implementation defect, not proof that the Agent has no work or no Call activity.
The backend retrieves recent Campaigns using the parent Customer’s:
This allows the Agent to see the parent Customer’s newest Campaigns.
The backend also retrieves recent Calls using the parent Customer’s User ID.
However, the Agent Dashboard labels the Card:
The Card can therefore display Customer-owned Call activity rather than only Calls made by the signed-in Agent.
Until the field and ownership mismatches are corrected, Agents should use:
instead of treating the Dashboard performance Cards as authoritative.
The Administrator Dashboard displays:
These values are system-wide.
Total Users counts every User record.
Customer and Agent counts are based on assigned roles.
The Customer and Agent quantities appear as descriptive text beneath Total Users.
The total Campaign count includes all nondeleted Campaigns system-wide.
The displayed Active Campaign count currently searches for:
and therefore has the same mismatch with the current running Status described earlier.
The Administrator Contact count includes all Contact records across the platform.
The Administrator Total Calls value counts all Call records.
The backend also calculates:
but the current System Overview Cards do not visibly display those two values.
The Administrator Dashboard displays:
Counts all Phone Number records in the system.
Counts telephone numbers with a stored Twilio SID.
This is not necessarily a count of every number obtained through SIP or another carrier.
Counts Phone Number records matching the model’s available scope.
Counts Phone Number records matching the assigned scope.
Counts all pending Customer Number Requests.
The Administrator interface attempts to display:
Phone Cost is calculated from the sum of:
for Phone Number records containing a Twilio SID.
The Card labels this as the monthly Phone cost.
The Phone Cost Card currently places a literal:
before the value.
It does not use the application’s configurable base-currency formatter.
When the system base currency is not USD, the symbol can be incorrect.
The Administrator Dashboard interface expects:
but the current Dashboard controller does not provide those fields.
The Cards can therefore display:
or otherwise lack valid values.
Use the dedicated Administrator Credit Management and Profit sections for authoritative financial reporting.
The Call Trends chart uses system-wide Calls for the latest seven days.
The Campaign Status Card uses system-wide Campaign records but has the same current status mismatch:
The backend returns the five newest Campaigns and includes the Campaign owner’s Name.
The current Dashboard Card does not display that owner.
Administrators should open the Campaign to confirm which Customer owns it.
The backend retrieves the ten newest Calls and includes owner information.
The visible Card displays only five and does not display the owner.
Global Search appears in the upper-right header.
It can be opened by:
or:
The interface visually displays the Command key shortcut, but both Command and Control are accepted.
The dialog displays:
Search begins only after at least:
have been entered.
A one-character query returns no results.
The interface waits approximately:
after the user stops typing before requesting results.
This reduces unnecessary requests while typing.
The Search dialog supports:
The interface can group results under:
The backend limits most categories to approximately:
The Global Search is therefore a quick-navigation tool rather than a complete report.
Menu search can return links such as:
Available menu results are generated according to broad role.
The Search menu generator checks whether the account is generally an Administrator or Customer.
It does not apply every:
A result can appear even when the user is not permitted to open the destination.
Administrators can search Customer accounts by:
A non-Administrator search is restricted to the signed-in Customer record.
Agent account search is available only to Administrators.
Campaigns are searched by:
Administrators can search all Campaigns.
Normal users are intended to search only Campaigns whose:
matches the signed-in user.
The Search controller scopes non-Administrator Campaigns directly to:
It does not substitute the Agent’s parent Customer ID.
An Agent can therefore receive no Campaign result even though the Agent can see the parent Customer’s Campaigns elsewhere.
Contacts are searched by:
The current Contact search query combines:
without grouping both search conditions before applying ownership.
Because of SQL condition precedence, a non-Administrator Contact Name search can potentially return a Contact belonging to another Customer.
This is a current data-isolation defect and should be corrected before Global Search is relied on in a multitenant production environment.
Users should not use Global Search to access or act upon records that do not belong to their account.
Administrators can search Phone Numbers by:
The result links to the central Administrator number inventory rather than a dedicated number detail page.
Call records can be searched by:
Results are ordered newest first.
The result can display:
or:
with a subtitle containing:
Several routes constructed by the Search controller do not match the installed application route list.
Examples include:
The Search code also references Administrator route names that are not present under those exact names.
Laravel’s route() helper resolves named routes while building the Search response.
A missing route name can cause the entire Search request to fail before results are returned.
This means Global Search can show:
or fail silently even when matching records exist.
The frontend catches request failures and replaces the result set with an empty array.
It does not display a technical error message.
A backend Search failure can therefore look identical to a valid search with no matches.
When Global Search does not work:
Select the Bell icon in the header.
The dropdown can display:
When unread Notifications exist, a red Badge appears on the Bell.
The Badge displays:
When more than nine unread Notifications exist, it displays:
The API retrieves the latest:
for the signed-in user.
The unread count is calculated across all unread Notification records, not only the latest twenty shown in the dropdown.
Notifications are ordered:
A Notification can contain:
When a Notification does not provide a Title, the dropdown uses:
When a Notification does not provide a Type, it uses:
Types are displayed using different text colors:
Recent Notifications display relative times such as:
After approximately seven days, the dropdown displays a browser-formatted date.
An unread Notification receives:
Selecting a Notification:
When no destination URL is stored, selecting the Notification only marks it as read.
The user remains on the current page.
When unread Notifications exist, select:
The backend marks all unread Notifications belonging to the signed-in user as read.
The mark-as-read operation applies both:
A user cannot normally mark another user’s Notification through this route.
A Contact import can create:
with a message such as:
This is a database Notification and does not depend on Email delivery.
A failed Contact import can create:
with the stored import error message.
When a Customer requests a telephone number, Administrators can receive an in-app Notification that a new Number Request was created.
The Customer can receive an in-app Notification after a Number Request is approved.
The Notification’s database data contains:
It does not currently provide a custom Title or destination URL, so the dropdown can show the generic Title:
The Customer can receive a Notification after rejection, including the rejection message or reason where stored.
Like the approval event, it does not provide a direct dropdown destination URL in the current Notification data.
Number Request Notifications are configured for:
The in-app Notification can be stored even when production Email delivery is not configured correctly.
As described in Chapter 2, the current runtime mail driver is log, so inbox delivery should not be assumed.
The Notifications component requests data when it first mounts.
It does not automatically:
A new Notification created while the user remains on the same loaded layout may not appear immediately.
To update it:
When Notification retrieval fails, the interface sets:
The dropdown can therefore display:
even when the actual problem is a failed API request.
When at least one Notification exists, the dropdown displays:
The link opens:
The installed route list contains the Notification API routes but does not contain a normal:
page.
The View all notifications action can therefore lead to a Not Found page.
Use the dropdown as the current Notification interface.
Users cannot delete individual Notifications through the current interface.
There is no Archive function.
The dropdown does not provide filters for:
Once marked read, a Notification cannot be returned to unread state through the interface.
The current header Notification system does not provide settings to enable or disable individual in-app Notification types.
The Credit Balance control appears only for users whose role includes:
It does not appear for:
On desktop, the control displays:
Example under a USD base currency:
On smaller screens, only the formatted amount is displayed.
The amount uses the application’s configured base currency.
The current default is:
but an Administrator can configure another supported base currency.
The Coin icon changes according to the numeric balance:
The threshold is:
For a USD-based system, the warning begins below:
A yellow Coin icon is a visual warning.
It does not itself prevent Calls or SMS.
Actual operations can be blocked when the platform’s credit checks determine that the balance is insufficient for the expected charge.
Both of these controls open:
The Credit Balance comes from the User data shared with the current Inertia page.
It does not poll continuously.
After:
the header can temporarily display the previous balance until a page request refreshes the User data.
AIUNIFY Credits are the platform’s internal billing balance.
They are not the same as:
A Customer can have AIUNIFY Credits while an external provider account is unavailable, and the reverse can also occur.
Dashboard activity is summarized through:
The Dashboard is not a complete audit log.
It does not provide a unified history of:
The backend retrieves:
The visible interface normally shows:
Recent Campaigns and Calls are ordered by database creation date, newest first.
They are not ordered by:
For detailed investigation, use:
The following Customer values are directly and consistently queried:
Use caution with:
The current Campaign model’s authoritative status sequence is:
The Dashboard’s Active category should be interpreted carefully until it is changed to use:
Check:
Refresh once and sign in again when necessary.
The Dashboard does not poll automatically.
Refresh or navigate away and return.
Open All Campaigns and look for:
The Dashboard currently checks for the outdated active Status.
The number beneath Contacts can be correct while the text says active Campaigns.
Interpret that number as active Contacts.
The Agent Dashboard frontend expects different field names from those returned by the controller.
Use Campaigns and Call History until the mapping is corrected.
Use:
or:
The main Dashboard does not currently receive valid credits_sold and credits_used values.
Enter at least two characters.
Possible causes include:
Use the module’s own page search.
The selected Search result may use an outdated destination such as:
Use the Sidebar’s current route.
Do not open, modify, or use it.
Report the issue to the platform Administrator because the current Contact search query does not properly group ownership conditions.
Refresh the page.
The component fetches Notifications only when it mounts.
The dropdown shows only the latest twenty Notifications, while the unread Badge counts all unread records.
Number Request Notifications do not currently provide a custom title field in their database payload.
The interface therefore uses:
The Notification may not contain a destination URL.
Selecting it still marks it as read.
Use the Bell dropdown.
A full /notifications page is not currently registered.
The Header credit control is Customer-only.
Confirm the account has the Customer role.
Possible causes include:
Open My Credits or Account Statement for confirmation.
Reload the page or navigate to another authenticated page.
The header balance is not a live-polling value.
The balance is below ten units in the configured base currency.
Review expected Call, SMS, and telephone-number charges before starting a large operation.
Review:
Review:
Because the current Agent Dashboard fields are mismatched, confirm activity in the operational pages.
Review:
Do not rely on the main Dashboard’s Credits Sold or Credits Used Cards until their data fields are connected.
Confirm:
Do not use Global Search to bypass:
Confirm:
Marking a Notification as read means:
It does not mean:
Confirm:
Confirm:
At the end of this chapter, the user should understand how to open and interpret the role-based Dashboard; how Customer, Agent, and Administrator statistics differ; how the greeting uses the browser’s local time while Dashboard periods use the server’s UTC Time Zone; and why Dashboard values remain a snapshot until the page is refreshed.
The user should understand the Customer Dashboard’s Campaign, Contact, Call, Team, Phone Number, Call Activity, Campaign Status, Call Trends, Recent Campaign, and Recent Call sections.
The user should also understand the current Campaign-status inconsistency:
A running Campaign may therefore be missing from the Dashboard’s Active count and status summary.
The user should recognize the current Agent Dashboard data-field mismatch and understand that its Available Work and Call Performance Cards may be blank or inaccurate. The Agent’s Recent Calls Card also uses the parent Customer’s Call scope rather than a confirmed Agent-only scope.
The Administrator should understand that system-wide User, Campaign, Contact, Call, and telephone-number statistics are calculated, but the Credits Sold and Credits Used Cards currently expect values not supplied by the Dashboard controller.
The user should understand how to open Global Search with the header or Ctrl/Command + K, enter at least two characters, navigate grouped results, and recognize that several Search destinations use outdated or missing routes. The user should also understand that Contact search currently contains an ownership-grouping defect and should not be relied on as a secure cross-account search boundary.
The user should know how to open the Notification dropdown, interpret the unread Badge, mark one or all Notifications as read, recognize Contact-import and Number Request events, and understand that the dropdown retrieves only the latest twenty records and does not poll continuously. The View all notifications link currently points to a page that is not registered.
Finally, the Customer should understand that the Header Credit Balance uses the system’s base currency, displays a yellow warning below ten units, and opens the Top Up page. It is an internal AIUNIFY account balance, not an external Twilio, SIP-carrier, or bank balance, and it may require a page refresh after new charges or payments.