Customer Merge: setup and help

Upload the ZIP through Modules > Module Manager > Upload a module and install it. The module creates its tables and adds Customers > Customer Merge. Configure opens Duplicate Customers.

Requires PrestaShop 1.6.1 or later and PHP 7.1 or later.

Open Customer Merge > Settings > System Check before merging. The merge engine requires OpenSSL AES-256-GCM for encrypted snapshots, including when the undo option is disabled. Snapshot compression initially uses gzip, so gzip support is also required. Turning off undo does not bypass these requirements.

Back up the shop database before the first real merge. A merge changes customer ownership and can retire absorbed accounts. No storefront widget is added.

Rescan customer-reference tables

Open Customers > Customer Merge > Data Sources and press Rescan the database. The registry discovers tables with an id_customer column under the shop's table prefix. It reports known core tables, known module tables, unknown tables and their write risks.

The Possibly customer-related, not touched section reports columns that resemble customer references under other names. These are informational. The module does not guess how to move them. References stored in custom formats or external systems are outside this discovery.

Save a strategy for each table

Review Risk on repoint, then choose Strategy:

Press Save strategies. Unknown tables start with the manual-decision policy. Unsafe tables cannot be made writable simply by selecting a move strategy. Views, missing primary keys, triggers, non-transactional storage and unsupported unique indexes restrict the available actions. The dry run identifies the remaining blockers.

Rescan after installing or changing a module that stores customer data, so its tables are checked again before any data is moved.

Open Customer Merge > Settings > Configuration. Review the following fields and press Save configuration.

General

The scan-scope list also offers All shops, cross-shop matches shown for information. That option still scans only the current customer-isolation domain, which can be one shop or a shop group sharing customers. Run the scan in each applicable domain and review its reported scope.

Accounts may merge only inside one customer-isolation domain: the same shop, or the same shop group when customer sharing is enabled. A match across separate domains cannot be merged.

Undo and retention

Snapshots contain customer data and are encrypted. Keep the shop's encryption material with your protected database backups if you need recoverable snapshots. Retention requires the housekeeping task to run. Erasure handling can purge a snapshot before its ordinary expiry.

Execution limits

Merges affecting more than 10000 rows also require explicit maintenance/CLI mode with the initial settings, even when they stay below the overall row ceiling. The ordinary back-office confirmation does not enable that mode.

Notifications

The screen offers Email a summary after scheduled scans and merges, off by default, and Send to, empty by default. Both values are saved, but the current version sends no summary email. Use the scan results and History and Undo to follow operations.

Review matching signals

Open Customer Merge > Settings > Detection Rules. Each rule has an enabled switch and Weight. The initial rules are enabled with these weights:

Signals of the same family do not simply add up, and conflicting signals can lower the score. A detected group is a suggestion to review, not a statement that the accounts belong to one person.

Under Thresholds, Show a group for review from starts at 55 and Treat as certain from starts at 95. Lower the review threshold to inspect weaker matches. It does not relax automatic-merge safeguards. Press Save detection settings after changing the rules.

Run the first scan

Open Duplicate Customers and press Full scan. The first scan builds the fingerprint index. Later scans can process changed customers incrementally. Scheduled scanning also periodically chooses a full scan, so detection is not limited forever to changed accounts.

Wait for the scan to finish or report a partial result. Check the scan status and scope before reviewing groups. Use Review to open a candidate group. Review confidence and the matched signals together with the accounts' actual details.

Choose the surviving account

The wizard has five steps. In Which account survives?, select the account that should retain its customer ID and registration date. Its credentials are the default source. Review registered and guest status, order counts, spending and addresses before continuing.

Resolve differing fields

Fields that differ lists conflicting values. Check the chosen first name, last name, email and other ordinary fields. Choosing Email address changes the login email, so the surviving account's original login address is not unconditionally retained.

Newsletter consent and Partner offers consent use the most restrictive value. Where the relevant PrestaShop fields exist, Risk level uses the more restrictive risk and Payment days allowed and Outstanding allowance use their lowest values. These fields are locked. The default group affects pricing; group memberships from the accounts are normally combined. Internal notes retain source markers.

Review addresses

In Addresses, inspect identical and similar addresses before collapsing them. An address referenced by an order keeps its ID and document fields. Its customer ownership can move. A duplicate referenced address is hidden rather than deleted, preserving historical document references.

Read the dry run

Press Preview the merge. Dry run reports rows moved, deduplicated, untouched and in conflict, with a per-table plan. Customer records have not been merged at this stage, although the module stores the preview job in its own tables.

Resolve every blocking conflict before proceeding. A missing primary key, trigger, non-transactional table, unresolved strategy or changed schema can block execution. Do not bypass those warnings by assuming the rows are unimportant.

Confirm and verify

In Confirm the merge, read the resulting-account sentence, row counts, absorbed-account action and undo deadline. Press Merge these accounts when the plan is correct.

The engine validates the plan again, locks the relevant rows and performs the business-data changes in one database transaction. If transactional work fails, it rolls back. Job and failure records can still remain for investigation.

Open History and Undo after completion. Check the surviving account's orders and addresses. Compare a sample historical invoice, payment, credit slip and order total with your pre-merge records. All affected customer sessions are revoked rather than transferred; users must log in again.

The module changes customer ownership on supported orders, returns, credit slips and messages. In particular, a credit slip's id_customer can change. It does not rewrite issued invoice or credit-slip amounts and document content.

Payments, order totals, order details, carriers, order history, stock movements and shipment records are outside the ordinary order-ownership change. An order-linked address retains its ID and document fields. Review custom modules and external systems separately through the data-source assessment.

Open Customer Merge > History and Undo to inspect the merge and its result. Undo is available only when the merge has retained, usable snapshots within its undo period.

Undo verifies that the affected data and schemas still match the state after the merge. It refuses when records changed, restoration would collide, a customer ID was reused, the snapshot expired or an erasure request purged required data. It does not overwrite later work to force restoration.

Customer sessions are an exception to snapshot restoration. Revoked sessions are never restored by undo. Disabling undo makes completed merges unavailable for reversal through this screen, even though the merge engine still requires encrypted snapshot processing during execution.

The audit log stores event type, outcome, UTC time, actor and employee information, linked customer IDs and supplied row counts or context. Entries include a previous hash and event hash, and the merge and undo paths verify the chain. Customer identifiers are recorded in this log.

Use Export CSV in History and Undo for the job summary: job ID, completion time, status, surviving customer ID, affected rows, conflicts and actor. This export reads up to 5,000 finished jobs; it is not an export of every hash-chained audit entry.

Automatic controls

In Detection Rules > Automatic merging, the visible controls are:

The certainty threshold initially uses 95. Safety checks still exclude unresolved conflicts, unknown tables, triggers and non-transactional tables from unattended processing.

In the current version these controls do not merge candidates automatically. The visible switch does not enable scheduled merging, and scans only list candidates without creating merge jobs. Merge candidates through the manual review workflow.

Scheduling and cleanup

Settings > Cron exposes the shared scheduling tools. The module registers Scan for duplicate customer accounts at 02:00, Process the auto-merge queue (disabled by default) at 02:30 and Purge expired snapshots and stale detection data at 04:00. Actual execution depends on the configured shared scheduler.

Connect a working scheduler entry point for your installation, then inspect scan and housekeeping results. The module does not include a root cron.php, so verify that a displayed CLI command points to an existing entry point before scheduling it. Keep housekeeping running if you depend on automatic expiry of snapshots or detection data.

• A group is blocked: read its Dry run table plan. Check strategies, primary keys, triggers, storage engines, unique-key conflicts and isolation domains.
• The scan finds nothing: check enabled detection rules and the review threshold. Run Full scan when an incomplete or incremental scan may have missed the expected accounts.
• All-shop scanning appears unchanged: the scan worker does not recognize the saved all-shops value and scans only the current customer-isolation domain. Run the scan in each applicable domain.
• A merge fails on encryption or compression: check System Check, AES-256-GCM and gzip support. Turning off undo does not remove the snapshot requirement.
• The preview expires or changes: regenerate Dry run, review the new counts and confirm again.
• Undo is unavailable: read its reason in History and Undo. Later data changes, expiry, restoration conflicts and erasure can all prevent it.
• No summary email arrives: no summary emails are sent. Use the scan and history screens.
• Automatic merging does nothing: the visible switch does not enable the separate cron worker gate or turn scan candidates into jobs. Continue with manual review.

Export or back up the records you need before uninstalling through Module Manager. Completed customer merges remain applied. Uninstall does not undo them.

The schema removes detection records, temporary plans and merge snapshots. Completed merges can no longer be undone through the module after their snapshots are removed. The schema marks merge jobs, job members, absorbed-to-surviving identity mappings and audit records as persistent, so those tables are retained.

Uninstall removes the menu and the module's working tables. Settings and scheduled-task entries can stay behind, so check the shared scheduler afterwards and remove any leftover entries. An audit record kept after uninstall cannot be used to undo a merge.