The Settings section controls the account’s operational preferences, service credentials, notification options, subscription information, and transaction history.
The page is described as:
The available Settings tabs are:
This chapter focuses on:
API Keys, provider integrations, Google Sheets, and Webhooks are covered in Chapter 15. Plan, purchase, payment, usage, and transaction functions are covered in Chapter 16.
To open Settings:
Settings can also be opened through the account menu:
The account menu retrieves the current User from /users/me and displays the User’s Name and Email Address.
When the page opens, AIUNIFY Assistant retrieves several types of information, including:
This allows the same page to combine preferences, integrations, subscription information, and telephone-engine status.
When the Settings request fails for a reason other than an expired session, the page can display:
Possible causes include:
When the Settings request returns an unauthorized response, the page removes the stored authentication token and redirects the browser to:
Sign in again before attempting to change Settings.
Each User has a separate Settings record connected through:
The Settings model enforces one Settings record per User.
This means one User’s:
does not automatically apply to another User.
New accounts are generally initialized with:
Although individual notification-event switches default to enabled, no email or Webhook is delivered until its overall integration is enabled and properly configured.
An Administrator can manage a User’s account and Plan, but each User still has an independent Settings record.
Creating a new User does not copy another User’s:
The header account menu displays:
The initials are generated from the User’s Name.
For example:
The reviewed User model does not contain a normal profile-picture field, and the header does not use an uploaded User image as part of the current profile workflow.
The application retrieves the signed-in User through:
The returned information can include:
The /users/me route is a read operation. It does not provide a self-service profile-update function.
The current Settings page does not provide editable profile fields for:
Users can review their Name and Email in the header, but they cannot change them from the current normal Settings interface.
The current AIUNIFY Assistant Settings page does not provide:
fields.
A signed-in User cannot change the password through the current Settings interface.
There is no normal User form for changing the account’s login Email Address.
Changing the Recipient Email under Email Notifications does not change the login Email Address.
These are separate values:
The account menu uses initials derived from the User’s Name.
The current Settings page does not provide:
controls.
The existing Administrator User-update route accepts fields such as:
It does not provide a general profile-edit operation for Name, Email, Password, or avatar through that route.
When Name, Email, or login credentials require correction, the current build may require assistance from an authorized platform Administrator or developer.
Do not change database records manually without:
The header includes an Appearance control that switches between:
The control changes the visual interface immediately.
The application’s root Theme Provider uses:
Therefore, the interface does not automatically follow the device’s light or dark preference in the reviewed build.
Light or Dark Mode is a frontend appearance preference.
It is not stored in the User’s operational Settings model with:
It does not require selecting Apply Preferences.
Changing Light or Dark Mode does not alter:
The default Settings tab contains a Card titled:
with the description:
The available controls are:
The tab also displays the current Asterisk/SIP Engine status.
The Time Format control provides:
The description states:
Selecting:
uses times such as:
The stored value is:
Selecting:
uses times such as:
The stored value is:
The backend accepts only 12 or 24 for this field.
Time Format can affect parts of the application that use the common Settings Provider, including certain:
Some pages use the browser’s own date-and-time formatting rather than the account’s Time Format preference.
For example, certain Appointment and scheduling displays may still follow the browser’s locale.
Do not assume that changing Time Format will immediately convert every date and time in every page.
Changing from 12 Hour to 24 Hour changes presentation.
It does not change:
The Time Zone control is described as:
The default is:
The current interface offers common geographic IANA values such as:
A previously stored Time Zone can also be displayed even when it is not in the standard visible list.
Use:
rather than a manually calculated offset such as:
when daylight-saving changes matter.
A geographic IANA Time Zone allows supported date libraries to adjust between standard and daylight time.
The account Time Zone determines how AI Appointment tools interpret:
It also controls how the Agent formats available-slot and Appointment confirmations.
Weekly Availability does not store a separate zone for each slot.
A slot such as:
is interpreted in the account Time Zone.
An incorrect Time Zone can cause the Agent to interpret:
incorrectly, particularly near midnight.
The account Time Zone and browser Time Zone are not always the same.
In the current build:
This can cause one Appointment to appear with different clock times on devices in different regions.
Assume:
A browser-local display can show:
The Appointment has not changed. It is the same moment displayed in another Time Zone.
Before changing the Time Zone:
Changing the Time Zone does not rewrite stored Call Logs or previously stored Appointment timestamps.
It changes how supported operations interpret and present those timestamps.
After saving:
The Preferences tab contains:
with the description:
The default value is enabled.
When enabled, qualifying Twilio calls can be recorded and the recording can later appear in Call Logs.
Recording availability still depends on:
Although the Settings interface specifically mentions Twilio, the reviewed SIP voice-processing source also checks recordingEnabled.
When SIP recording is enabled, the system can store a SIP recording reference for the Call Log.
Disabling Call Recording affects future recording behavior.
It does not automatically:
Changing the Recording switch during an active call should not be treated as a reliable way to alter that already-running call.
Apply recording changes before starting Campaigns or accepting production inbound calls.
A Transcript can be created by speech processing even when no playable Recording is available.
Likewise, a Recording may exist while a Transcript is incomplete.
Before enabling call recording, the organization should review applicable requirements concerning:
The technical Recording switch does not establish legal permission to record.
The Preferences tab contains:
with the description:
The default is disabled.
When analysis succeeds, a Call Log can receive:
Automatic analysis generally requires:
Enabling the switch without configuring OpenRouter does not make analysis operational.
When a SIP call completes, the SIP voice stream checks:
and can send the completed Call Log to the analyzer.
Completed Twilio and custom-voice call workflows can also trigger analysis when enabled and when a Transcript exists.
Automatic analysis occurs after the conversation.
It is separate from the live AI Agent that spoke to the Lead.
The live Agent and the post-call analyzer can use different models and instructions.
Disabling Automatic Call Analysis:
but does not:
Eligible completed Call Logs can still provide:
when automatic analysis is disabled or did not run successfully.
The current analyzer is instructed to evaluate a sales call and qualify the Lead.
Its results may be less suitable for:
Review the Transcript and Recording before relying on an AI qualification.
The Preferences tab contains:
with the description:
The default is disabled.
When enabled, two fields appear:
Both values are measured in minutes.
Incoming Timeout controls the configured maximum duration for inbound calls.
Default:
Outgoing Timeout controls the configured maximum duration for outbound calls.
Default:
The interface converts the entered value to an integer.
Use whole numbers such as:
rather than decimal values.
The backend accepts:
for both limits.
A zero value is not the same as disabling Auto Hangup.
When Auto Hangup is enabled and either timeout is zero, the interface displays a warning such as:
or:
A zero-minute timeout can cause affected calls to terminate immediately.
To disable automatic duration termination:
Do not leave it enabled with zero-minute limits.
The reviewed calling logic can provide a one-minute warning for qualifying inbound calls when the configured limit is greater than one minute.
The warning is not confirmed for every provider and every outbound call mode.
Auto Hangup should be treated as a call-control limit, not a guaranteed billing stopwatch accurate to the exact second.
Termination can be affected by:
Before launching a Campaign, verify that Outgoing Timeout allows enough time for the Agent to:
Incoming Timeout should account for the likely complexity of inbound conversations.
A support or Appointment call may require more time than a simple Lead-qualification call.
The Preferences tab also displays:
with a status such as:
and the number of active SIP calls.
The Card allows the User to verify whether the SIP calling engine is connected.
It does not replace the detailed SIP Trunk management process.
The status area provides:
which opens the SIP Trunks section.
SIP setup and troubleshooting are covered in Chapter 6.
After changing Time Format, Time Zone, Recording, Analysis, or Auto Hangup, select:
A successful save displays:
A failed request can display the server’s returned error or:
Changing a field does not immediately save it to the backend.
Leaving Settings before selecting the appropriate Save button can discard unsaved changes.
The current Settings page uses one common save operation for its Settings tabs.
When a Save button is selected, the page submits the current in-memory values for:
not only the visibly open tab.
Example:
The common save operation can submit both the Time Zone and Email changes.
Review changes across all visited tabs before selecting a Save button.
The message:
confirms that AIUNIFY Assistant stored the configuration.
It does not prove that:
Use the relevant verification or test function.
Select:
from the Settings tabs.
The Card is titled:
with the description:
The Email tab contains:
The first control is:
with the description:
Email delivery requires both:
An enabled event does not send email while the master switch is off.
The master Email Notifications switch defaults to:
Individual event values can default to enabled, but they remain inactive until the master switch and Brevo configuration are completed.
AIUNIFY Assistant uses Brevo transactional email services for Email Notifications.
The field is labeled:
The key is entered into a password-style field.
The placeholder resembles:
The interface directs Users to obtain the key through Brevo’s SMTP and API settings.
Email delivery cannot proceed without a stored Brevo API Key.
The service can report:
Treat the Brevo API Key as a credential.
Do not:
The key should belong to the approved organizational Brevo account and have the access required to send transactional email.
The field is labeled:
with the description:
Example:
The current Email Settings model contains one Recipient Email value.
The normal interface does not provide:
A managed distribution address can be used when organizational policy permits.
Changing Recipient Email does not change the User’s login Email Address.
The notification recipient can be different from the account owner.
When no Recipient Email is configured, the email service can report:
Sender Name controls the display name shown to the recipient.
Example:
When Sender Name is blank, the email service uses the configured platform application name as a fallback.
Use a recognizable organizational identity.
Recommended:
Avoid vague names such as:
Sender Email controls the email address shown as the sender.
Example:
When Sender Email is blank, the service contains a default fallback address.
A fallback address does not guarantee that the User’s Brevo account is authorized to send from it.
Use a Sender Email or domain that is verified and authorized in the connected Brevo account.
An unverified sender can cause:
The Email tab visibly provides these event switches:
Description:
This event is source-confirmed for Appointments created through:
Description:
This event is source-confirmed for cancellation through:
Description:
The Email Settings interface exposes this event and supports a test email.
However, the reviewed operational source does not show the normal Lead-creation routes automatically calling the Email Service for leadCreated.
Description:
The Email interface exposes the setting and test event.
The reviewed analyzer automatically triggers a Webhook for a Qualified Lead, but the reviewed production analyzer source does not show a corresponding automatic Email Service call.
Description:
The setting and test email exist.
The reviewed inbound calling source confirms Webhook triggering, but an automatic production Email Service call for inbound calls was not found in the reviewed build.
Description:
The setting and test event exist.
The reviewed Twilio and SIP call-completion source shows Webhook activity and Call Log updates, but does not show an automatic production Email Service trigger for callCompleted.
The backend Email Settings structure also stores:
The current Email tab does not expose a visible Outbound Call switch or test-email choice.
The backend also stores:
The current Email tab does not expose a visible Campaign Completed switch or test-email choice.
The Settings model supports eight email-event values:
The current Email interface visibly manages six of those events.
In the reviewed build, automatic production calls to the Email Service were found for:
They occur through the Appointment routes and AI Appointment tool service.
Automatic production Email Service calls were not found for:
Their Settings values and test-email samples exist, but this does not confirm that the production event routes send those emails.
The current interface can create the impression that all visible event switches are active production notification integrations.
In the reviewed build:
A successful Lead Created or Call Completed test proves that:
It does not prove that a real Lead creation or completed call will invoke the Email Service automatically.
After entering the Email fields and selecting events, choose:
The test-email endpoint reads the stored backend Settings.
Therefore:
Testing before saving can use older stored values.
The backend validates Sender Email and Recipient Email as Email Address fields when values are supplied.
Invalid formatting can prevent Settings from saving.
Sender Name and Sender Email can be left blank, but operational delivery is more reliable when an approved Sender Name and verified Sender Email are entered.
Select:
and choose one of the visible events:
The test route requires at least:
When the master switch is off or the Brevo key is missing, the backend can return:
Test emails use sample information rather than actual customer records.
Examples include:
The interface can display a message such as:
The backend response indicates that a test message was dispatched to the configured Recipient Email.
A successful API request means Brevo accepted or processed the send request.
It does not guarantee:
Check the recipient mailbox and Brevo delivery logs.
The email service skips an event when its event switch is disabled.
The current manual test route can still return a general success response after the service skips a disabled event.
For a reliable test:
Test:
individually when validating templates and sender configuration.
The Email Service generates HTML transactional messages using:
The Appointment Booked notification can include:
The Appointment Canceled notification can include:
The test template can include:
The test template can include:
A call-related test can include:
depending on the selected event.
The reviewed Email Service formats Appointment Date and Time directly from the stored timestamp on the server.
It does not clearly apply the User’s account Time Zone before generating the email.
An Appointment can therefore be:
Verify the Appointment against the dashboard and account Time Zone before relying on the email’s clock display.
Before production Appointment emails:
The reviewed application does not provide a persistent in-app notification center containing:
The application displays temporary confirmation and error messages such as:
These are not stored as a permanent notification history.
The Email tab does not provide:
Email Notifications are designed as event-based messages.
The normal Settings page does not expose an SMS notification service for internal account alerts.
Telephone calling and SMS notifications are separate functions.
All enabled Email events use the same configured Recipient Email.
The current interface does not route:
Normal Users cannot edit:
through the Email Settings tab.
The current normal User interface does not display:
Use the connected Brevo account for delivery investigation.
Appointment Booked and Appointment Canceled emails are immediate event notifications.
They are not confirmed reminder messages scheduled:
To sign out:
The interface displays:
Logout removes browser-stored values including:
and redirects to /login.
Appearance behavior is controlled separately from the operational User Settings.
Logging out should not be treated as a method for resetting Time Zone, Recording, Email, or integration configuration.
The Settings page can contain:
Treat the page as a credential-management area.
Before sharing a screen:
Do not include real credentials in:
Mask secrets before sharing.
Each User should configure the integrations authorized for that account.
Do not reuse one employee’s personal Brevo or provider credentials across unrelated accounts without organizational approval.
Rotate a Brevo key when:
After rotation, save the replacement key and send a controlled test email.
Email notifications can contain:
Use an authorized Recipient Email.
Check:
The page may use browser formatting instead of the shared account formatter.
Confirm the setting saved, then test it in Call Logs or another supported page.
Compare:
Check:
Disable Auto Hangup or enter an appropriate positive limit.
Provider and timer processing can introduce a brief delay.
Review:
Check:
Disabling Call Recording does not delete historical recordings.
Historical deletion or retention must follow the organization’s approved process.
Check:
Automatic analysis can occur after the Call Log reaches completed status.
Wait briefly, select Refresh, and use Analyze Now when available.
Check:
This can occur when the account has no usable Email Settings record.
Reload Settings and save the Email configuration.
Enter the correct key, save the configuration, and retest.
Do not enter the Brevo login password in the API Key field.
Enter a valid Recipient Email and select Save Email Configuration.
Check:
This is consistent with the reviewed source.
Appointment Booked and Appointment Canceled have confirmed automatic Email Service triggers.
Other visible events have configuration and testing support, but their automatic production Email triggers were not found in the reviewed build.
The test route directly invokes the Email Service with sample Lead data.
The ordinary Lead creation route does not appear to invoke the Email Service in the reviewed build.
The test route directly invokes the Email Service.
The reviewed call-completion workflows trigger Webhooks and update Call Logs, but do not show an automatic callCompleted Email Service invocation.
Confirm the Sender Email is verified in Brevo and belongs to an authorized sending domain.
Review:
The Email Service may be using server-side formatting rather than the account Time Zone.
Verify the actual Appointment through the Appointments page and the Agent’s booking confirmation.
For a new account:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Before relying on:
confirm through a real controlled event that an email is delivered.
A successful sample test alone does not confirm that the production event route is connected to the Email Service.
Confirm:
At the end of this chapter, the user should understand how to open Settings from the Sidebar or account menu; how the User’s Name, Email Address, and initials are displayed; and that the current build does not provide normal self-service controls for changing the profile Name, login Email, Password, or avatar.
The user should understand how Light and Dark Mode operate separately from saved account Settings; how Time Format changes supported time displays; how Time Zone controls Appointment and Availability calculations; and why the account Time Zone, browser Time Zone, and server-formatted Email time can produce different visual clock values.
The user should understand how to enable or disable Call Recording, that SIP processing also respects the recording preference despite the interface’s Twilio wording, and that disabling future recording does not delete historical recordings. The user should also understand how Automatic Call Analysis depends on a completed call, Transcript, and OpenRouter configuration.
The user should understand how Auto Hangup applies separate incoming and outgoing limits, why a zero-minute value can cause an immediate hangup, and why the correct way to disable the feature is to turn off the master Auto Hangup switch.
The user should also understand how to configure Brevo Email Notifications, including the API Key, Recipient Email, Sender Name, Sender Email, event switches, Save function, and test-email process. Most importantly, the user should recognize the current implementation difference between notification settings and confirmed production event wiring: