This chapter explains how users access and secure their AIUNIFY Call Center accounts, update their profile information, change or recover a Password, configure Two-Factor Authentication, and complete Customer identity verification.
The account-access sequence is:
The Settings area currently contains:
The KYC items are hidden when KYC has been disabled globally.
Open:
The root address redirects to:
The Login page displays:
The form contains:
The Password field includes a visibility control that switches between hidden and visible characters.
To sign in:
A successful login redirects to:
AIUNIFY Call Center uses Email Address as the login username.
Fortify is configured to lowercase usernames during authentication.
Recommended format:
Avoid copying leading or trailing spaces.
Selecting:
asks the authentication system to preserve the browser login beyond the normal session.
Do not use it on:
The Eye icon changes the field between:
The browser does not submit a different Password when visibility is changed.
Use this control only where another person cannot see the screen.
The Login screen can display a status message above the form.
Examples can include:
Read the message before submitting the form again.
When Cloudflare Turnstile is enabled in the platform configuration, the backend requires a valid:
before attempting Email and Password authentication.
Failure can occur when:
When the challenge does not appear:
The Forgot Password page also displays the Turnstile component.
However, the reviewed custom Fortify authentication pipeline explicitly validates Turnstile for Login, while equivalent custom backend validation was not found for the Password-reset-link request.
The visible challenge should still be completed when shown, but its server-side enforcement on this specific form is not confirmed in the current build.
The Login endpoint permits approximately:
for each combination of:
After repeated failures, the user may receive a throttling response and must wait before trying again.
After one or two failed attempts:
Do not continue guessing rapidly.
Laravel Fortify registration is enabled in the backend.
A new account created through that process would receive the:
role by default.
The backend registration validation requires:
The current visible Registration page does not display a form.
It immediately redirects the browser to:
Therefore, users should not rely on public self-registration in the current deployment.
New Customer and Agent accounts should be created through the approved Administrator or Customer team-management process.
The application contains routes and interface pages for:
The verification page can display:
and a confirmation when a new link has been sent.
Although many application routes use the:
middleware and Fortify’s Email Verification feature is enabled, the current User model does not implement Laravel’s MustVerifyEmail contract.
The Profile controller also checks whether the User implements that contract before showing its unverified-email warning.
As a result, the current build does not reliably enforce Email verification for ordinary browser users. The verification interface exists, but the operational requirement is incomplete.
Chapter 1 described verified Email as a requirement for most authenticated routes.
The deeper source review completed for this chapter shows the more precise current behavior:
This should be corrected before Email verification is represented as a mandatory production security control.
When a user changes the Email Address through Profile Settings, the backend sets:
The Email Address therefore becomes unverified in the database.
However, because Email verification is not fully enforced in the current User model, the user may not be prompted to verify the replacement Email.
The current production runtime reports:
This means Laravel-generated messages such as Password resets and Email verification messages can be written to application logs rather than delivered to the recipient’s mailbox.
The platform mail configuration must be changed to a functioning production mail provider before users can depend on inbox delivery.
From Login:
The form contains:
When mail delivery is correctly configured, the system sends a Password-reset link to the registered Email Address.
The link contains:
Do not forward the link to another person.
Because the current runtime uses the log mail driver, a user may receive a success response but no Email in the inbox.
When this happens:
The reset page displays:
The Email comes from the reset request and cannot be edited in the form.
The new Password must match:
A mismatch prevents the reset.
The application uses Laravel’s configured default Password rule and requires confirmation.
Because the source bundle’s secret-protection process redacted the detailed Password rule values, users should follow the validation message shown by the live form rather than rely on an undocumented complexity formula.
A secure Password should still contain:
After a successful reset:
A reset can fail when:
Request one new link and use only the newest message.
Certain sensitive Settings pages require the user to re-enter the current Password before continuing.
The confirmation screen contains:
This is separate from changing the Password.
The current Two-Factor Settings controller applies:
middleware before showing the page.
Opening Two-Factor Auth can therefore redirect the user to the Password confirmation screen first.
To open Profile:
The page heading is:
with a description explaining that the user can update account Profile information.
The current Profile form contains:
It does not contain fields for:
Those values are managed elsewhere or are not exposed in the current Profile form.
Full Name is:
Use the person’s proper operational name so call activity and team records remain understandable.
The Email Address must be:
The user may retain the current Email because the uniqueness check ignores the current User record.
To update the Profile:
The page preserves its scroll position during the request.
Changing the Profile Email changes the Email used to log in.
After saving:
Confirm the new address before signing out.
The Profile page contains interface logic capable of displaying:
However, that section appears only when the User implements MustVerifyEmail.
It will not normally appear with the current User model.
At the bottom of Profile Settings, the interface displays:
and a warning:
Selecting Delete account opens a dialog:
The user must enter the current Password and select Delete account again.
After successful Password validation, the backend:
The action should be treated as permanent.
The delete route permits:
roles.
It does not permit the Agent role.
The Profile interface itself is shared, so an Agent may still see the Delete Account component even though submitting it can be rejected by the role middleware.
This is a current interface and authorization mismatch.
Review:
Account deletion should not be used as an ordinary method of leaving a team.
From Settings, select:
The form contains:
The correct current Password is required.
An incorrect value produces a validation error and returns focus to the Current Password field.
Enter a Password not used for:
The confirmation must exactly match the new Password.
Select Save Changes once.
On success:
appears and the Password fields are cleared.
The Password update route is limited to:
Do not repeatedly submit after a validation failure.
The current Password-update controller changes the stored Password but does not show an operation that logs out every other browser session.
After a suspected compromise:
Two-Factor Authentication requires:
This protects the account when the Password is exposed.
From Settings:
The Card displays either:
or:
When disabled, the page displays:
The intended process is:
A standard time-based authenticator can be used, including applications such as:
The code normally changes approximately every 30 seconds.
The confirmation field expects:
Do not include spaces or hyphens.
The current Two-Factor page expects optional:
properties.
However, its controller currently sends only:
The source also contains more complete QR-code and recovery-code helper components, but the current Settings page does not import or use them.
Consequently, selecting Enable Two-Factor Authentication may create the backend Two-Factor secret without displaying the QR code and confirmation interface required to complete setup. This feature should be tested carefully before requiring it for production users.
Do not assume Two-Factor Authentication is complete merely because the Enable request succeeded.
Confirm all of the following:
When enabled, the page displays:
Selecting it opens a browser confirmation:
Confirm only when authorized.
Recovery codes allow login when the user loses access to the authenticator application.
Each code should be treated like a one-time Password.
The underlying Fortify system supports:
The included recovery-code component states that each code can be used once.
The visible Two-Factor page displays a Show Recovery Codes button only when recovery codes have been passed to the page as properties.
The controller does not currently pass them.
The more complete component capable of fetching and regenerating codes exists in the source but is not connected to the current page.
Users should not enable Two-Factor Authentication until they can verify that recovery codes are actually available.
Store codes in:
Do not store them in:
After entering Email and Password, a Two-Factor-enabled user is sent to the challenge page.
The normal mode displays six separate code positions.
Enter the current Authenticator code and select:
The challenge screen includes a link allowing the user to switch to a Recovery Code.
Enter one unused code and select Continue.
The user can switch back to the Authenticator code mode.
Two-Factor challenges are limited to approximately:
for the current login session.
After several failures, wait before trying again.
Check:
When both are unavailable:
Do not send identity documents or Passwords through ordinary Email unless specifically required through a secure process.
The KYC Verification Settings item appears only for the Customer role and only when KYC is globally enabled.
Administrators receive a separate KYC configuration item.
Agents do not receive the Customer KYC Verification menu.
The system defines:
A KYC record can have:
Document-level statuses can be:
Unverified means the Customer has no approved KYC record.
Protected features can redirect the user to the KYC Status page.
Pending indicates that:
The Status page displays:
Approved indicates that the relevant verification has been accepted.
For Basic KYC, approval occurs automatically after successful Phone verification.
For Business KYC, an Administrator approves the submission.
Rejected displays the Administrator’s rejection reason where available.
The Status page provides:
Expired indicates that verification must be renewed.
The Status page can display:
when an approved record is within the renewal window.
The system’s shared page data calculates a seven-day KYC grace period from the User’s account creation date.
The Dashboard can display:
The KYC access middleware does not check or honor the calculated grace period.
For Customer accounts, it requires:
before allowing a KYC-protected route.
Therefore, the current seven-day grace period is primarily a Dashboard display concept and does not reliably grant temporary access to Campaigns, Contacts, Calls, or other protected functions.
The grace-period-expired banner does not itself change the main User status to inactive.
It represents KYC feature restriction rather than a confirmed full authentication suspension.
The user may still be able to sign in and access the Dashboard or Settings.
Basic KYC verifies the Customer’s Phone Number.
The Tier description is:
From Settings:
The number must use E.164 format:
Example:
The backend permits up to 15 digits after the plus sign.
A Phone Number cannot be used by another KYC record whose status is:
The current User’s own record is ignored during the uniqueness check.
Possible error:
The system creates a six-digit verification code and sets:
The SMS is dispatched synchronously through the configured Twilio service.
Possible errors include:
When the SMS cannot be sent, the database transaction is rolled back.
The screen displays:
The code field accepts numeric characters only and has a maximum length of six.
When the timer reaches zero, the screen displays:
An invalid code increments the attempt count.
When two or fewer attempts remain, the interface displays a warning.
After five failures:
Selecting Resend Code:
The browser displays a 60-second resend cooldown.
The reviewed route does not show equivalent server-side rate-limit middleware, so the visible cooldown should not be treated as complete abuse prevention.
When a Twilio Verify Service SID is configured, the backend validates the submitted code through Twilio Verify.
Otherwise, it compares the code with the locally stored verification code.
After successful verification, the backend records:
The user is redirected to KYC Status with:
The current User access model grants approved Basic Customers access to:
The KYC enum also lists Audio Files, but the User helper used elsewhere does not include Audio Files in its Basic feature list.
This is a current internal inconsistency.
The current model contains Basic KYC limits of:
Actual enforcement can also depend on pricing, Credits, provider limits, and Administrator configuration.
The Basic Verification page states that Phone verification will unlock:
That wording is not accurate.
Conversational AI and other advanced features require Business KYC in the current access model.
Business KYC is intended to unlock:
It requires Business information and identity documents.
The user must first have:
Attempting to open Business verification without Basic approval redirects to KYC Status with:
The Business form contains three stages:
Step 1 contains:
The available selections are:
The visible Country selector currently contains:
The backend accepts a two-letter country code, but the current interface limits ordinary selection to these five values.
The user can select:
The ID document can be:
Maximum size:
Accepted business evidence can include:
Supported formats are JPG, JPEG, PNG, and PDF, with a maximum size of 5 MB.
The default KYC configuration migration contains an Administrator setting of:
for the maximum document size.
However, the active Business KYC request validation is hard-coded to:
Users must follow the stricter 5 MB limit until the implementation is aligned.
The final stage requires:
Accepted formats:
Maximum size:
The interface instructs the user to ensure:
After completing all three steps:
The backend stores:
on the Laravel:
storage disk.
The interface states that documents are encrypted. The reviewed source confirms private storage and controlled download routes, but it does not independently confirm application-level file encryption.
The interface states:
for Compliance review.
This is an expected review window, not a source-confirmed service-level guarantee.
Submission changes the record to:
The user cannot reopen the normal Business form while the record remains Pending.
An Administrator can approve a Pending KYC submission.
The current approval route changes:
and dispatches an approval Email job.
The current Administrator approval route does not set:
when approving a Business submission.
As a result, the Customer’s Status page may show Approved without displaying a verification date or expiration date.
Basic KYC does not have this issue because its Phone-verification controller sets those timestamps directly.
Although the KYC configuration contains a two-year expiry concept, Business approval does not currently assign an expiration date.
Business KYC may therefore remain Approved indefinitely unless an Administrator updates or expires it through another process.
An Administrator can reject a Pending Business submission and provide:
The Customer Status page displays the rejection reason.
An Administrator can mark any of these as Rejected:
The KYC Status page displays uploaded status and review status for each document.
The Rejected Status page links the Customer to:
That form changes the KYC tier back to Basic and starts Phone verification.
For a Customer whose Phone is already verified, the Phone verification page immediately redirects back to KYC Status.
This can leave the record in an inconsistent Pending Basic state instead of reopening the Business document form.
A rejected Business applicant may require Administrator or developer assistance to resubmit correctly.
The KYC Status page can display:
Each User has one KYC verification record.
The page does not display a history of previous submissions or approvals.
The normal Customer interface does not provide:
once the Business submission has been sent.
The backend contains an authenticated document-download route that selects:
from the signed-in User’s own KYC record.
The normal Customer Status page does not clearly provide direct download buttons.
Approved KYC is required for many operations, including:
Routes can be labeled:
but the current middleware does not use the minimum-tier parameter to distinguish Basic from Business.
It only checks:
Business-only enforcement therefore depends on separate feature checks and navigation logic rather than the kyc:basic parameter itself.
The KYC middleware bypasses:
roles.
They are treated as having full KYC access.
When an Administrator disables KYC:
Existing KYC records remain in the database.
Check:
Wait at least one minute and then submit one corrected attempt.
The limit is based on both Email and IP Address.
Refresh the page, complete the challenge again, and verify browser extensions are not blocking it.
Possible causes include:
The current log mail driver is the most likely deployment-level cause.
Also check:
Follow the live validation response and confirm both new Password fields match.
Request one new link and use the newest token.
Another User already owns that Email Address.
Use a different unique address or contact an Administrator.
This is consistent with the incomplete Email-verification implementation.
The User model must implement MustVerifyEmail, and production mail must be configured, before the expected verification workflow operates.
The Delete route is restricted to Administrator and Customer roles.
An Agent should be deactivated or removed through team management.
This matches the current source mismatch between the page’s expected properties and the controller’s supplied properties.
Do not continue until the setup screen is corrected or an Administrator confirms the backend state.
The current page is not connected to the existing recovery-code fetch component.
Do not assume the codes are unavailable at the backend, but do not rely on them until they can be retrieved and stored.
Confirm:
Possible causes:
Confirm E.164 format:
Also confirm the number is not already attached to another Pending or Approved KYC record.
Check:
Select Resend Code to create a new code and reset the attempt counter.
Basic Phone verification must be Approved first.
Confirm:
This can occur with Business KYC because the current Administrator approval route does not set approval and expiration timestamps.
The current Resubmit Documents link can route through Basic verification and become stuck when the Phone was already verified.
Contact an Administrator before repeatedly changing the KYC record.
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Before deletion, confirm:
At the end of this chapter, the user should understand how to log in with Email and Password, use Remember Me safely, complete Turnstile, respond to login throttling, request a Password-reset link, create a new Password, confirm the Password for sensitive Settings, and update Full Name and Email Address.
The user should understand that Email-verification routes and pages exist, but the current User model does not implement Laravel’s required Email-verification contract. The verified route middleware is therefore not reliably enforcing Email verification, and the current production log mail driver prevents ordinary inbox delivery of Laravel-generated reset and verification Emails.
The user should understand how to change the Password, delete a Customer or Administrator account, and recognize that the Agent role can see the shared deletion component even though the deletion route does not authorize Agents.
The user should understand the intended Two-Factor Authentication process, including the six-digit authenticator challenge and one-time recovery codes. The user should also recognize the current implementation gap in which the Two-Factor page expects QR and recovery-code properties that its controller does not provide.
The user should understand the difference between:
and the statuses:
The user should know how to complete Basic Phone verification using an E.164 Phone Number, a six-digit SMS code, a ten-minute expiration period, and up to five attempts.
The user should also know how to submit Business information, an ID document, a Business registration document, and a Selfie with ID; why each uploaded file is currently limited to 5 MB; and why Business approval can appear without an approval or expiration date in the current build.
Most importantly, the user should understand the current KYC access rule:
The displayed seven-day grace period does not currently override that middleware requirement.