Article summary
AppShai Zalo checking is a file-based TXT-to-Excel workflow, not a claimed one-click webhook integration. Learn how to export from CRM, normalize numbers, select fields, test the import, handle conflicts, and preserve an audit trail.
Zalo checking results can be used in CRM, but the current AppShai process should be described accurately as a file-based handoff: create TXT from an existing business list, run the selected task, export Excel, map the fields, and validate the import. It should not be advertised as an existing webhook, API connector, or one-click automation.
Direct answer: Preserve the CRM internal ID and raw phone number, normalize a working copy, and create TXT with one number per line. Join the Excel result back to the internal ID by phone, test row counts, blanks, duplicates, and conflicts in a staging area, and only then import into production CRM.
The complete file-based data chain
| Stage | File or system | Control |
|---|---|---|
| Source | CRM master table | Internal ID, provenance, permission, raw phone |
| Preparation | Normalization worksheet | Preserve raw value, country code, deduplication |
| Upload | UTF-8 TXT | One phone number per line |
| Result | AppShai Excel export | Selected task fields and check date |
| Write-back | CRM staging, then production | Mapping, conflicts, and audit |
The internal ID does not go into TXT, but it must remain in the protected source table so every result row can return to the correct business record.
Map the three Zalo tasks to real fields
| Task | Currently confirmed fields | Question supported |
|---|---|---|
| Zalo Registration Check | Phone and registration status | Was a Zalo registration signal returned? |
| Zalo Activity Check | Phone, User ID, activity time, nickname, active days | How should activity-related records be grouped? |
| Zalo Age and Gender | Phone, User ID, activity, nickname, age, gender, picture and image fields | Are these specific governed fields genuinely required? |
Use the selected task’s actual Excel export. Do not import a WhatsApp mapped-phone field, Telegram username, or an unsupported bot-detection claim into the Zalo schema.
Columns to preserve when exporting from CRM
The master table should retain the internal ID, raw phone number, country, provenance, permission state, and last business update. TXT contains only the normalized phone number, but the join key and evidence remain in the source system.
When one normalized phone maps to several customer records, define merge, primary-record, and conflict rules before the task. An operator should not improvise this decision after the Excel result arrives.
Normalize numbers and build TXT
- Add the correct international code from a confirmed country field.
- Remove visual separators and apply the country-specific domestic-prefix rule.
- Keep raw and normalized phone columns separately.
- Deduplicate normalized values and export an exception table.
- Create UTF-8 TXT with one number per line and no header.
- Reopen the file and inspect it for lost plus signs or scientific notation damage.
Map Excel fields into a controlled CRM schema
| CRM field | Excel source | Import rule |
|---|---|---|
| zalo_registration_status | Registration status | Updated only by the Registration task |
| zalo_user_id | User ID | Platform field; never overwrites internal ID |
| zalo_activity_time | Activity time | Stored with the check date |
| zalo_active_days | Active days | Preserve the task definition |
| zalo_nickname | Nickname | Not treated as verified legal name |
| zalo_profile_checked_at | Task completion time | Supports freshness decisions |
Age, gender, or image-related fields should not enter CRM by default when purpose, access, and retention have not been approved.
Why the import needs a staging area
Staging exposes unmatched phones, one-to-many records, blank values that would overwrite valid data, date-format errors, and unsupported enumerations. Produce four outputs—create, update, skip, and conflict—before approving the production write.
Safe defaults are: a blank does not overwrite a known value, a platform User ID never replaces the CRM internal ID, and the untouched Excel export remains the evidence file.
Where automation should begin
Run the file workflow successfully before automating it. Without a field dictionary, exception queue, idempotency key, access rules, rollback, and audit log, a webhook only distributes errors faster.
Internal automation can generate TXT, validate format, and prepare the staging import while the external service remains accurately described as TXT input and Excel output. Select the actual task on the AppShai Zalo Number Checker page.
Acceptance and rollback after import
- Does the unique input count equal valid TXT lines?
- Can every Excel row return to an internal ID?
- Did every field come from the correct Zalo task?
- Are blanks, duplicates, and conflicts reported separately?
- Are the raw TXT, Excel, and import log retained?
- Can the batch be rolled back if mapping was wrong?
A reliable Zalo-to-CRM workflow is built on a clear field contract and a recoverable data chain, not on an unsupported “one-click integration” label.
