The Contacts section stores the people and organizations that may be called, messaged, enrolled in Campaigns, added to follow-up Sequences, or reviewed through Analytics.
The Contact-management workflow includes:
The recommended Contact-data process is:
The current application provides standard browser routes for Contacts, Lists, Tags, imports, exports, Phone validation, and calling sessions, along with API routes for bulk operations and data-quality analysis.
A Contact is the reusable master record for a person or organization.
A master Contact can be connected to:
A Campaign Contact represents a Contact’s participation in one specific Campaign.
Campaign-specific status, Notes, attempts, and results can differ from the master Contact.
A Contact List is a reusable group of Contacts.
Examples:
A Contact can belong to more than one List.
A Contact Tag is a reusable label.
Examples:
Tags provide flexible classification, while Lists are generally used as structured groups.
A Contact contains both:
These values are separate.
Supported Contact Status values are:
The Contact can also contain:
A Contact should not be called merely because its Status says Active when it has separately opted out.
The Contact model can store:
The model also supports:
Additional fields include:
The system can track:
The model can also store:
Not every stored field is displayed by the current Contact interface.
When neither First Name nor Last Name is present, the model’s full-name helper returns:
The normal browser create form currently requires both First Name and Last Name, even though the backend model permits blank names.
To open Contacts:
The page address is:
Normal Contact-management routes are inside the Basic KYC-protected area.
A Customer generally requires:
when KYC is globally enabled.
Common Contact permissions include:
A user may be able to view Contacts without being permitted to create, edit, delete, import, or export them.
Administrators can generally view Contacts across the platform.
A Customer normally sees Contacts whose:
An Agent’s normal Contact list uses:
This allows the Agent to view the parent Customer’s Contact records.
The Contact policy currently prevents an Agent from:
even when the Agent can view and call the parent Customer’s Contacts.
The ordinary Contact create action stores a Contact under the parent Customer when the signed-in user is an Agent.
This keeps manually created Agent Contacts visible in the shared Customer workspace.
The CSV import process currently behaves differently and is discussed later in this chapter.
The Contacts page contains controls for:
The Help action explains basic Contact-management concepts within the interface.
It does not modify Contact data.
Start Calling opens the Contact Calling Session.
The session provides a guided one-at-a-time Contact workflow.
Check Valid Numbers examines every Contact Phone Number in the current owner’s Contact collection.
It does not validate only the rows visible on the current page.
The Import action opens the Contact Import dialog.
The separate /contacts-import page currently redirects back to Contacts and instructs the user to use the integrated import feature.
Add Contact opens:
The Contacts search can match:
To search:
Search uses partial matching.
Examples:
A search can be affected by:
When an exact Phone Number does not match, search by a shorter numeric portion.
When Contact Lists exist, the page displays filters such as:
All Contacts removes the List-specific filter.
The number displayed on the chip is based on the currently returned Contact pagination total.
When another search is active, the value can represent the searched result rather than the complete Contact database.
Selecting a List displays Contacts connected to that List.
Selecting:
returns Contacts that currently have no Contact List assignment.
The current pagination action preserves the Search value but does not consistently preserve the selected Contact List filter.
After selecting another page, the view can return to All Contacts.
Confirm the active List chip after pagination.
The Contact controller supports query filters for:
The current main browser page visibly exposes only:
The current page does not provide a normal dropdown for:
There is no visible main-page filter for:
Existing Tags are not displayed as a main Contact filter in the current browser interface.
Although the backend can filter by a minimum Engagement Score, the main page does not expose that control.
The current Contacts table displays:
The Name column combines:
The Phone column displays the saved Phone Number.
Telephone numbers should be stored in E.164 format whenever possible.
A blank Email Address is displayed as an empty or unavailable value.
Email is optional in the normal create form.
Company is optional.
It can be used in Search and Campaign personalization.
The Website value can open as an external link.
Confirm that the saved URL belongs to the intended organization before opening it.
The Lists column displays the Contact Lists assigned to the Contact.
A Contact can display more than one List.
The Status column displays the stored Contact Status.
The table does not separately show the opted_out value.
A Contact can therefore appear Active in the table while having a separate opt-out flag.
The Phone icon starts a Contact-aware calling workflow.
It is available only when the browser Softphone Device is registered.
Selecting the icon:
The user must still select Call in the Softphone.
The Eye icon opens the Contact Details page.
The current main table does not display direct:
buttons in each row.
Open the Contact Details page to reach Edit.
A normal Delete control is not clearly exposed in the current browser workflow.
The current main Contacts table does not display selection checkboxes.
Bulk backend routes exist, but the main browser table does not connect them to a visible bulk-action toolbar.
The main table does not display:
The Contacts page returns approximately:
by default.
The interface displays page numbers near the current page.
Use the controls to move through the Contact collection.
The controller accepts a page-size parameter, but the current page does not provide a visible per-page selector.
From Contacts, select:
The form opens at:
The current create form contains:
The browser form requires both:
The backend technically permits them to be blank, creating a current frontend-and-backend validation difference.
Phone Number is required.
The recommended format is:
The backend accepts an optional plus sign followed by up to 15 digits, with the first digit after the plus sign not equal to zero.
The database currently makes phone_number unique across the entire platform rather than unique within each Customer account.
This means two separate Customer accounts cannot normally create Contacts using the same Phone Number.
Possible error:
This is a significant current multitenant limitation.
Email is optional but must be valid when entered.
Website and social fields must contain valid URLs when provided.
Recommended:
rather than:
Notes can contain information required for approved sales, service, or follow-up activity.
Do not store:
Select one or more existing Contact Lists.
The Contact is attached to those Lists after creation.
The backend create action can accept Tag IDs, but the current create page does not display a Tag selector.
The current form does not provide controls for:
To create a Contact:
On success, the application displays:
and opens the Contact Details page.
A Contact created through the browser is assigned a source similar to:
The standard create process can dispatch a Contact-added event for configured CRM integrations.
CSV imports currently follow a different processing path and may not dispatch the same event.
The backend confirms that submitted List and Tag IDs exist.
It does not consistently verify that every submitted List or Tag belongs to the same Customer as the Contact.
Normal users should select only the Lists and Tags shown through their own interface and should never manipulate submitted IDs.
This ownership validation should be corrected for production multitenant security.
Select the Eye icon on the Contacts table.
The address is:
The page displays:
Call Contact loads the Contact into the global Softphone.
It is enabled when the Softphone Device is registered.
The Details page can display:
The current Details interface does not clearly display:
although some of these are loaded or stored.
The backend loads the Contact’s Lists and Tags for the Details request.
The current page does not render them in the primary visible Contact-information sections.
The Contact page includes a Recent Calls table with:
The controller retrieves up to:
linked directly through the Call’s contact_id.
Older Campaign Call records that lack a direct contact_id may not appear even when they represent the same person.
The backend selects:
while the page expects a property named:
The displayed Recent Call duration can therefore be blank or undefined in the current build.
The controller also prepares Campaign and activity information.
The current page does not visibly render the complete Campaign participation or activity timeline.
From Contact Details, select:
The page opens:
The current Edit page contains the same primary fields as Create:
The current Edit page does not display Contact List assignments.
Existing List membership remains unchanged because the backend synchronizes Lists only when List IDs are submitted.
Use Contact Lists or an approved bulk process to change List membership.
The current Edit page does not display Tag assignments.
The current Edit page does not expose:
The form also does not expose:
This means the normal browser Edit page cannot fully manage Do-Not-Call suppression.
An approved Administrator or API-based process is currently required to update these fields reliably.
Chapter 4 explained that a Do Not Call Disposition must be followed by a separate Contact-status update.
The deeper Contact review shows that the current standard Edit form does not provide that Status or Opt-Out control.
Therefore, the present safe procedure is:
After reviewing the Contact, select Save Changes.
On success:
appears and the Contact Details page opens.
The standard Edit process compares changed fields and can dispatch a Contact-updated event to configured CRM integrations.
The Contact model uses soft deletion.
Deleting a Contact generally:
The current primary Contact pages do not clearly expose a standard Delete button.
The backend delete route exists and can be used by authorized workflows.
Because the Phone Number remains in a soft-deleted row and the database Phone Number constraint is globally unique, deleting a Contact can continue to prevent recreation of that Phone Number.
An Administrator may need to restore or permanently resolve the original record.
Agents cannot delete the parent Customer’s Contacts under the current Contact policy.
Before deleting a Contact, review:
Select:
The page address is:
The Calling Session includes Contacts whose:
Blocked, Inactive, and Opted-Out Contacts are excluded from this particular workflow.
The Contact model’s general canBeContacted() helper considers a Contact contactable when it is:
That helper does not explicitly exclude Inactive Contacts.
The guided Calling Session is stricter because it requires Status Active.
Other workflows must be reviewed carefully so Inactive Contacts are not called unintentionally.
Contacts are ordered by:
Contacts that have never been contacted can appear early in the session.
The Calling Session can be limited to a Contact List.
Selecting another List reloads the session with Contacts belonging to that group.
The session can display:
The user can move with:
Select Call to load the current Contact into the Softphone.
The Softphone must be registered.
After the linked Post-Call Disposition workflow completes, the Calling Session can move to the next Contact.
The current Contact index and progress are maintained in the page state.
A refresh or reopening the session can reset the user to the beginning of the ordered Contact collection.
The Calling Session retrieves the entire matching Contact set rather than using normal pagination.
Very large Contact collections can make the page slower.
Use a focused Contact List for controlled calling sessions.
The Contact query remains owner-scoped, but the selected List record itself is loaded by ID without a complete ownership restriction.
Do not alter List IDs in the URL.
From the Sidebar:
The page address is:
Contact Lists are intended to organize Contacts for:
A List contains:
The List page displays:
Select:
or open:
Enter:
Name is required and can contain up to 255 characters.
The current database rules do not require List names to be unique.
Two Lists can therefore have the same Name.
Use descriptive unique names operationally.
Description is optional.
Example:
Select View to open the List Details page.
The page shows the List’s Contacts and controls for adding or removing members.
The List Details page supports adding selected Contacts that belong to the owner’s Contact collection.
The backend uses a nonduplicating attachment process, so adding an existing member again should not create another identical List relationship.
Removing a Contact from a List removes only the List relationship.
It does not delete the master Contact.
Removing a Contact from one List does not remove it from other Lists.
An Edit route exists at:
The main List table does not prominently display Edit in every current view, but it can be reached through the List workflow.
Deleting a List removes the List record and its relationships.
The master Contact records remain.
Contact Lists do not use the Contact model’s soft-deletion behavior.
Treat List deletion as permanent through the normal user interface.
Customers see their own Lists.
Agents use the parent Customer’s List collection.
The add and remove operations validate that submitted Contact IDs exist, but they do not consistently verify that every submitted Contact belongs to the List owner.
Use only Contacts displayed by the normal interface.
This server-side ownership validation should be strengthened.
List Details can load all current members and all available Contacts.
Large Contact collections can make the page slower because the List workflow is not fully paginated.
The Tag page exists at:
It is not currently displayed as a primary Sidebar item.
A Tag contains:
When no color is provided, the backend uses:
A Tag Name must be unique within the same owner’s Tag collection.
The same Tag Name can exist for a different Customer account.
The Tag index can display:
The Tag interface contains links for creating and editing Tags.
The installed route list contains:
It does not contain normal GET routes for:
The Create and Edit links can therefore open a Not Found page in the current build.
The backend can create a Tag when an authorized interface submits:
but the standard create form route is incomplete.
The Tag index provides a Delete action.
Review affected Contact classification before deleting a Tag.
The current Create and Edit Contact pages do not display Tag selectors.
Existing Tags can be selected in the Contact Import dialog.
This is currently one of the main visible methods for assigning Tags to multiple Contacts.
The backend provides:
It adds Tags without removing existing Tags.
The current Contacts table does not expose the row selection needed to use this feature through the normal page.
From Contacts, select:
The integrated Import Contacts dialog opens.
The dialog progresses through:
The visible browser file selector is designed for:
The backend also permits text-delimited input, but CSV is the supported user workflow.
The current import permits files up to approximately:
The interface describes support for up to:
Large imports require additional caution because the current deployment processes queued work synchronously.
The Import dialog provides a sample template.
The template filename is:
The template contains:
The included sample rows use international Phone Numbers beginning with +.
Mapping tells AIUNIFY which CSV column corresponds to each Contact field.
The current dialog supports:
A CSV column must be mapped to:
before the import can proceed.
The dialog attempts to recognize headers containing terms such as:
Review every mapping before import.
The CSV parser reads a small sample for mapping.
The dialog generally displays the first sample value under each source column.
It does not provide a complete row-by-row validation preview.
Select:
for any source column that should not be imported.
The dialog displays:
and enables it by default.
The current Import dialog does not include the skipDuplicates state in the submitted form data.
The checkbox therefore has no effect on the actual import.
When the import finds an existing Contact with the same owner and Phone Number, it updates that Contact instead of skipping it.
This occurs regardless of the visible duplicate checkbox.
The success count combines:
The completion screen does not separately show how many were created versus updated.
Select one or more existing Tags to attach to imported Contacts.
Select one or more Contact Lists to attach to imported Contacts.
Submitted Tag and List IDs are not fully validated against the Contact owner.
Use only options displayed by the current account’s interface.
A ten-digit number without a plus sign is converted to a U.S. number:
Other digit lengths are generally prefixed with:
This does not guarantee that the result is a valid international number.
Store international Phone Numbers in complete E.164 format before importing.
Example:
Do not rely on automatic country inference.
A row without a usable Phone Number does not create a Contact.
The processed-row counter can still advance even though the row is not counted as a successful or failed Contact.
The displayed totals can therefore appear inconsistent.
The import normalizes characters but does not run the full Contact Phone Validation workflow on every imported row.
Run Check Valid Numbers after import.
The uploaded file is stored in an imports directory and connected to a Contact Import tracking record.
The import processes Contacts in batches of approximately:
Progress is updated periodically, approximately every 100 processed rows.
The production runtime currently reports:
Although the Import dialog describes background processing, the import job currently runs during the web request.
Large files can therefore:
After receiving an Import ID, the dialog checks import status approximately every two seconds.
Under the synchronous queue mode, much of the import can already be complete before the browser receives that ID.
The dialog states that the user can close it and will be notified when processing completes.
The actual import job used by this route does not create the same in-app completion Notification implemented by another unused import job.
Do not rely on an automatic Notification.
The current user interface does not provide a durable Contact Import history page.
Closing the modal stops its local polling and resets the dialog.
Record the result before closing it.
The current processing job does not explicitly store:
Imported Contacts can have a blank or default source value.
The current import processor creates or updates Contacts directly.
It does not clearly dispatch the same Contact-added or Contact-updated CRM events used by the standard browser forms.
A CSV import may therefore not synchronize to an external CRM automatically.
The Contact Import record uses the signed-in User ID.
For an Agent, this is the Agent’s own ID rather than the parent Customer ID.
The processing job creates new Contacts using the Contact Import’s User ID.
An Agent’s imported Contacts can therefore be stored under the Agent instead of the parent Customer.
The Agent’s normal Contact index searches the parent Customer’s Contact ownership.
An Agent-created CSV import can succeed and then appear to vanish because the new Contacts belong to the Agent User ID.
Agents should not perform production imports until this ownership mismatch is corrected.
The import job checks for an existing Phone Number under the import owner.
The database Phone Number constraint is global.
When another Customer already owns that Phone Number, the owner-scoped check finds nothing, but the database can still reject creation.
The row is then recorded as failed.
The completion screen can report:
The import tracking process keeps a limited set of row errors rather than displaying every error from an extremely large file.
After completion:
The Contact export is available at:
The current main Contacts page does not display a normal Export button.
The export route exists but may require:
Export scope follows:
The export can apply:
The main index backend supports a minimum Engagement Score filter.
The export does not apply that same minimum-score parameter.
The Contact index specially recognizes:
The export does not implement the same special handling.
Attempting to export the Not in any list view can produce an incorrect result or error.
The filename follows a pattern similar to:
The CSV includes:
The standard export does not include:
The export retrieves the complete matching Contact collection and builds the CSV in memory.
Very large exports can consume significant server memory.
Use narrower filters for large Contact databases.
Contact exports can contain personally identifiable information.
Store them only in:
From Contacts, select:
The system validates the owner’s complete Contact collection.
The result displays:
Invalid results can show:
The current process checks all Contacts for the owner.
There is no visible option to validate only:
The current Phone Validation service primarily checks:
It does not confirm that the telephone number:
After cleaning, a number is generally considered structurally acceptable when it contains approximately:
When a number lacks a plus sign, the service commonly assumes:
This can incorrectly reformat non-U.S. numbers.
Examples include:
The interface and controller comments describe the suggestions as AI-powered.
The reviewed implementation generates these Phone fixes using deterministic formatting rules rather than an OpenRouter AI request.
The validation result does not save the suggested Phone Number.
The user must:
After corrections, select Re-Validate to scan the Contact collection again.
Phone validation results are not stored as a lasting Contact-validation status.
The next validation run recalculates the results.
The validation request processes every Contact synchronously.
Large Contact databases can take longer and risk request timeouts.
The normal Contact index allows Administrators to view all Contacts.
Phone validation determines the owner ID as the signed-in Administrator’s ID rather than using the Administrator’s global scope.
An Administrator can therefore validate only Contacts directly owned by the Administrator account through this action, not all platform Contacts.
Open a Contact Details page.
The page displays:
Select:
The Data Quality service uses OpenRouter.
A valid OpenRouter configuration is required.
The analysis can include:
The score is measured from:
General display categories are:
Running a quality check can store:
even before the user applies suggested changes.
The quality card can display:
Duplicate Risk is part of the AI analysis response.
It is separate from the backend’s exact duplicate-finding endpoint.
The interface allows the user to visually select individual suggestions.
The frontend passes a list of approved fields when applying suggestions.
The backend apply endpoint does not use that list.
It applies all stored AI suggestions.
Therefore:
Do not select Apply unless every displayed suggestion is acceptable.
After AI suggestions are applied, the backend marks:
even though the values were generated and applied through AI.
The flag should not be interpreted as proof that a human independently verified every field.
The quality workflow does not provide:
Record important original values before applying suggestions.
The Contact Details policy allows an Agent to view a parent Customer Contact.
The Data Quality API requires the Contact’s User ID to equal the signed-in User ID, except for Administrators.
An Agent can see the Data Quality Card but receive:
when checking a parent-owned Contact.
The API also contains a duplicate-finding endpoint that compares Contacts belonging to the same owner.
Possible matching signals include:
The standard Contact Quality Card displays the AI-provided Duplicate Risk.
It does not clearly run or display the complete duplicate-finder endpoint results.
The API supports batch cleaning for up to approximately:
per request.
The current main Contacts table does not provide a connected batch-quality selection interface.
The source includes a Contact Import Quality Preview component.
The active Import dialog does not use it.
CSV imports proceed without the user seeing that quality-review step.
The separate quality-preview API expects response fields that do not fully match the Data Quality service’s current result structure.
Its high-confidence auto-apply logic also passes inconsistent function arguments.
It should not be considered production-ready until tested and corrected.
Engagement Score estimates how actively and successfully the Contact has interacted with Campaigns and Calls.
The current calculation uses:
When Total Calls equals zero:
Successful Call rate contributes up to approximately:
Recent activity can contribute:
Campaign participation contributes up to approximately:
based on the number of Campaigns.
The Engagement Score is stored and can be exported.
The current main Contacts table and Contact Details page do not display it.
Engagement Score is not:
Use it only as an operational prioritization signal.
Contacts can store:
The API provides operations for:
The main Contact Details page does not display or edit the optimal-time fields.
Smart Scheduling is primarily accessed through Analytics and Campaign workflows.
The browser backend provides:
The API also supports bulk create, update, and delete.
The current Contacts table has no checkboxes or connected bulk toolbar.
These operations are not normally accessible from the visible Contacts page.
Bulk Tag:
Bulk Add to List adds selected Contacts to one List.
It does not remove them from other Lists.
Bulk Delete soft-deletes the selected Contacts.
Because Agents cannot update or delete parent-owned Contacts, normal Agent bulk Tag, List, or delete requests are rejected by Contact policy.
The selected Contact collection is owner-scoped, but the submitted Tag or List ID is not consistently verified against that same owner.
Do not manipulate request IDs.
Contact records can contain:
Treat Contact data as protected business information.
Store only the information required for an approved business purpose.
Do not place in Notes:
Confirm that social URLs belong to the Contact or business before saving them.
Contact CSV files should be deleted from local Downloads folders after they have been transferred to approved storage.
A structurally valid Phone Number does not prove permission to call it.
Confirm:
The current Contact pages do not provide a complete normal-user suppression control.
Use an authorized documented process and confirm the result before launching a Campaign.
A Tag such as:
does not technically block the Contact unless the calling workflow explicitly excludes that Tag.
A List named:
also does not automatically prevent inclusion elsewhere.
Use the actual Status and opt-out fields through an approved process.
Check:
The Contact policy intentionally prevents Agents from editing parent-owned Contacts.
Contact the Customer manager.
Do not call or modify it.
Report the ownership issue to an Administrator.
The current unique constraint applies platform-wide.
Search for an existing Contact under the authorized account and contact an Administrator when another Customer appears to own the same number.
Use:
with no extension or text.
Enter the complete URL beginning with:
Confirm that the List belongs to the current Customer and still exists.
The page expects duration, while the backend returns duration_seconds.
Review Call History for the accurate duration.
The backend loads them, but the current Details page does not render them.
Open Contact Lists or the Tag page.
The current Contact page does not display the complete Campaign activity data prepared by the controller.
Review Campaign Details and Call History.
List names are not required to be unique.
Rename them with a clear date, purpose, or region.
Pagination does not consistently retain the selected List.
Select the List again.
Confirm:
Deleting a List removes the grouping, not the master Contacts.
Search All Contacts to confirm the Contacts remain.
The current build does not register the GET Create route.
Tag creation requires a corrected interface or approved backend process.
The normal GET Edit route is also absent.
Tag names must be unique for the same Customer.
Use a different Name or update the existing Tag.
The current queue driver is synchronous.
Large imports can keep the web request open.
Do not upload the same file repeatedly.
The checkbox is not submitted to the backend.
Existing same-owner Contacts are updated.
Rows without usable Phone Numbers can increase processed progress without being recorded as success or failure.
For an Agent, the Contact may have been stored under the Agent User ID and excluded from the parent-owned Contact list.
Matching Phone Numbers update existing same-owner records.
Review before importing a CSV that contains blank or outdated values.
The active import job does not create the promised in-app Notification.
Keep the modal open where practical and record the result.
The platform-wide Phone Number uniqueness rule can reject a number already stored by another Customer.
The current CSV processor does not clearly dispatch the normal Contact CRM events.
Use the CRM integration logs and approved synchronization process.
The current page does not display one.
The backend route remains /contacts-export.
The export does not understand the special unassigned List filter used by the Contact index.
The server loads the full matching Contact set into memory.
Use narrower filters.
Those fields are not part of the current Contact CSV export.
The validator checks format, not reachability or provider permissions.
The current rules assume U.S. formatting when country information is missing.
Correct it manually using the true E.164 country code.
Do not apply it.
Verify the original source or contact the person through an approved channel.
The process scans all Contacts synchronously.
Use smaller Contact collections or an off-hours maintenance window.
Confirm OpenRouter configuration and service availability.
Agents can view parent Contacts but cannot currently use the quality endpoint on those parent-owned records.
The backend ignores the selected-field list and applies all stored suggestions.
Review every Contact field immediately.
The current backend sets that flag after applying AI suggestions.
It does not prove independent human verification.
The displayed Duplicate Risk comes from AI analysis and is not the same as the deterministic duplicate endpoint.
Search manually by Phone and Email.
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Because the backend applies all stored suggestions, do not proceed when even one suggestion is questionable.
The reviewed Contact implementation currently includes these important limitations:
At the end of this chapter, the user should understand the difference among:
The user should understand how to open the Contacts page, search by Name, Phone Number, Email, or Company, filter by Contact List, interpret the Contact table, open Contact Details, prepare click-to-call, create a Contact, and edit the visible Contact fields.
The user should understand that the Contact model supports more information than the present forms expose, including:
The user should recognize that the current Contact Edit page does not provide a normal control for Status or Opt-Out. A Do Not Call Disposition alone is therefore not a complete suppression process.
The user should know how to create and manage Contact Lists, add or remove List members, and recognize that deleting a List does not delete its master Contacts.
The user should understand that Contact Tags exist but that their Create and Edit links are incomplete in the current build because the required GET routes are not registered.
The user should understand the full Contact Import workflow:
The user should recognize that the visible duplicate-skipping option currently has no effect and that matching same-owner Contacts are updated. The user should also recognize the Agent import ownership defect and the risks created by the current synchronous queue mode.
The user should know how Contact exports are structured, which fields they include, which fields they omit, and why large exports and exported personally identifiable information require careful handling.
The user should understand that Check Valid Numbers performs structural formatting checks rather than confirming whether a Phone Number is real, reachable, consenting, or assigned.
The user should understand how the AI Data Quality Card stores a score, issues, and suggestions. Most importantly, the user should know that selecting only certain suggestions does not limit the backend—the current apply action uses all stored suggestions.