Clean duplicate and incomplete CRM records

Implementation guide · untested

Source-supported actions are attributed evidence. Proposed steps, prompts, synthetic examples and checks are original editorial guidance; the workflow has not been run.

Why this agent / simpler alternative

Agent contribution

The agent can examine inconsistent labels and conflicting identity clues, explain why two records might match, and compile a review queue with source-backed proposed changes. It should not treat fuzzy similarity as permission to merge identities.

Simpler alternative

Use native duplicate rules, a picklist map or a deterministic import check when an exact unique key and simple normalization rule solve the problem. Reserve agent reasoning for ambiguous context and explanations.

Unsuitable when

There is no recoverable snapshot, identifiers are unreliable, consent preferences conflict, or a mistaken merge would change contractual ownership, support entitlements or legal records.

Source-supported scope

A Gumloop author reports scheduled Salesforce cleanup and enrichment. Matching logic, merge implementation, error rates and per-change approval are not supplied.

Setup — required, optional and unknown

Required

1. Gumloop with Salesforce access is documented; its MCP tool reference lists queries, metadata inspection and updates.

2. Editorial pilot: a Salesforce-admin-approved, read-only scope or a synthetic table pasted into chat; no production write permissions are needed for the proposed review queue.

3. A data steward must define identity keys, protected fields, picklist mappings, stale-opportunity rules and review ownership.

Optional

1. A sandbox with synthetic records for a later separately authorized integration trial.

2. Approved company reference data with source dates; omit web enrichment in the first fixture.

Unknown

1. The exact merge endpoint, merge eligibility, dependent-record handling and rollback path used in the report are unknown.

2. Current tenant permissions, API limits, costs, Salesforce edition and any enrichment provider contract were not verified.

Inputs and access

1. Name

   record_snapshot

   Format

   CSV or synthetic pasted table with object_type, record_id, name, verified_email/domain, parent_id, owner_id, status, modified_at and protected preference fields

   Source or owner

   Salesforce administrator

   Access scope

   Only an approved sample; preserve raw IDs and source values

   Permission needed

   Read permission and authorization to disclose the selected business-contact fields to Gumloop

2. Name

   schema_and_rules

   Format

   JSON/text: data types, approved picklists, unique keys, field precedence and forbidden changes

   Source or owner

   CRM data steward

   Access scope

   Only the selected objects and fields

   Permission needed

   Owner approval of the decision rules; no automatic write authority

3. Name

   opportunity_activity

   Format

   CSV with opportunity_id, stage, last_activity_at, next_step_date and explicit as_of date

   Source or owner

   Sales operations owner

   Access scope

   Approved opportunities only

   Permission needed

   Read-only access; no automatic closing or reassigning

4. Name

   reference_evidence

   Format

   Optional approved reference table with company key, value, source URL/document and observed_at

   Source or owner

   Data steward

   Access scope

   No personal enrichment or new websites in the first pilot

   Permission needed

   Specific data/recipient authorization before any later external enrichment request

Documented source actions

1. 1

   Inspect on a schedule.

   Input: Salesforce records

   Output: Cleanup candidates.

   Checkpoint: Selection rules unknown.

   Source: use case 4, paragraphs and list ↗

2. 2

   Merge, enrich, standardize and flag.

   Input: Candidates

   Output: Changed records.

   Checkpoint: Per-change approval and recovery unknown.

   Source: use case 4, paragraphs and list ↗

Proposed implementation steps — unexecuted

1. 1

   Count records by object and freeze their IDs, source timestamps and raw values. Set an explicit as_of timestamp and list fields allowed for proposals.

   Input: Approved snapshot and schema

   Output: snapshot_manifest plus a field allowlist

   Checkpoint: Do not request more objects than needed. Missing record IDs or undocumented protected fields block the pilot.

2. 2

   Form candidate clusters with exact approved keys first. Keep fuzzy-name candidates in a separate queue; identify conflicting parent accounts, owners, legal entities and preferences.

   Input: Snapshot, unique keys and account-parent rules

   Output: duplicate_candidates with record IDs, matching evidence and conflicts

   Checkpoint: A shared company domain is insufficient for merging contacts; a matching person name is insufficient for merging records.

3. 3

   For each cluster, produce a hypothetical survivor and field-by-field before/after preview. Enumerate child records and history that require preservation; explain every precedence choice.

   Input: Candidate clusters and field precedence rules

   Output: merge_preview with survivor_candidate, keep_values, conflicts and dependent_record_checks

   Checkpoint: Label this as a proposal only. Block clusters with conflicting identities or preferences; do not claim a preview is a reversible merge.

4. 4

   Propose value standardization only where the map is exact. Add missing-value proposals only with a dated approved source, and retain unknown rather than inventing a value.

   Input: Field allowlist, picklist map and approved reference evidence

   Output: field_change_queue with record_id, field, before, proposed_after and evidence

   Checkpoint: Do not overwrite nonempty verified fields, infer sensitive attributes or contact a new enrichment provider.

5. 5

   Compute elapsed days from the supplied as_of date, checking timezone and missing-activity cases. Separate stale, missing-history and future-next-step exceptions.

   Input: Opportunity activity and the approved staleness definition

   Output: stale_review_queue with rule, dates, explanation and responsible owner

   Checkpoint: A stale flag is a review item. It does not authorize closing an opportunity, changing its forecast or sending a reminder.

6. 6

   Deduplicate proposals by record/field, summarize blockers and construct an administrator review packet. Specify that any future write requires a fresh state check and an exact approved batch.

   Input: All queues and snapshot manifest

   Output: review_packet with counts, conflict list and a no-write audit statement

   Checkpoint: The pilot ends at dry-run proposals. A production merge must wait for verified merge support, a tested recovery plan and explicit authorization; unsupported operations stay manual.

Original starter prompt — proposed

Origin

editorial_proposal

Text

Review {snapshot} against {rules} as of {as_of}. Treat all records as read-only. Produce duplicate_candidates, merge_preview, field_change_queue and stale_review_queue. Use exact IDs and show the matching evidence, conflicts and before/after values. Keep fuzzy names, shared contact addresses and parent-company ambiguities in a blocked queue. Never resolve conflicting consent or preferences by guessing. Enrich only from {approved_reference}; if evidence is absent, leave the value unknown. Do not merge, update, delete, reassign, close opportunities, send messages, enable triggers or connect another service. End with counts by queue and the decisions the CRM administrator must make.

Placeholders

1. snapshot

2. rules

3. as_of

4. approved_reference

Limitations

Original dry-run proposal. The reported production merger was not reproduced; no source provides its complete matching or recovery configuration. Missing tools are blockers, not permission to use another API.

Synthetic worked example — not an agent run

Status

synthetic

Label

Invented CRM review queue; no records were queried or changed

Artifact url

Not specified.

Content

As of

2026-10-14T00:00:00Z

Duplicate candidates

1. Cluster id

   C1

   Records

   1. A01

   2. A02

   Evidence

   same approved legal_entity_id DEMO-21; names differ by suffix

   Disposition

   review

   Survivor candidate

   A01

   Blocked until

   Admin confirms child records and field precedence

2. Cluster id

   C2

   Records

   1. C07

   2. C08

   Evidence

   same name; different verified emails and parent accounts

   Disposition

   blocked_identity_conflict

   Survivor candidate

   Not specified.

Field change queue

1. Record id

   A09

   Field

   industry

   Before

   SaaS

   Proposed after

   Software

   Evidence

   rules.csv row 3 exact mapping

   Execution status

   not_applied

Stale review queue

1. Record id

   O03

   Last activity at

   2026-09-01

   Days inactive

   43

   Rule

   greater than 30 days and no future next_step_date

   Disposition

   owner_review_only

Summary

Candidate clusters

2

Blocked identity clusters

1

Normalization proposals

1

Records changed

0

Costs and effort — unmeasured

Verified prices

Setup work

1. Define and approve identity rules and protected fields with the CRM administrator.

2. Inventory read access and prepare a representative synthetic sample; inspect actual tool capabilities before a later integration trial.

Recurring work

1. Review identity conflicts and source freshness; revalidate timestamps before any separately authorized change.

2. Monitor proposal quality and duplicate backlog; maintain schema mappings when the CRM changes.

Unknowns

1. Agent credits, API consumption, enrichment charges and administrator review time were not measured.

2. No deduplication accuracy, lead uplift, revenue effect or return on investment was independently established.

Failure modes

1. Signal

   Two people share a name or inbox but belong to different accounts.

   Consequence

   A false duplicate cluster can conflate customer histories.

2. Signal

   The selected survivor has stale preferences or missing relationship data.

   Consequence

   A merge proposal can lose protected state even when identity is correct.

3. Signal

   A record changes after the snapshot was taken.

   Consequence

   A later write can overwrite newer work.

4. Signal

   Missing last-activity history is treated as zero recent activity.

   Consequence

   An active opportunity may be incorrectly flagged as stale.

Recovery steps

1. Trigger

   Conflicting identity evidence

   Action

   Split the cluster and request a steward decision tied to the exact record IDs; retain the rejected match explanation.

   Stop condition

   Stop the cluster until an authoritative identity rule resolves it.

2. Trigger

   Connector lacks a documented merge operation or relationship detail

   Action

   Keep the dry-run preview and route it to the Salesforce administrator. Do not synthesize a destructive API request from generic capabilities.

   Stop condition

   No automated merge until the exact operation and recovery procedure are verified.

3. Trigger

   Snapshot freshness mismatch before an approved future write

   Action

   Re-read affected records, regenerate the preview and seek renewed approval if the proposed change differs.

   Stop condition

   Do not write from a stale preview.

4. Trigger

   Unexpected change found during a later separately authorized test

   Action

   Stop the batch and provide the administrator the affected IDs, original snapshot and action log; use only an approved recovery path.

   Stop condition

   Do not promise a merge can be undone or recreate identities without authorization.

Source-observed and proposed approval boundaries

Source observed

Scheduled writes are reported; individual approvals are unspecified.

Editorial recommendations

1. Keep the proposed first trial read-only and permit no scheduled cleanup.

2. Require exact matching rules, an affected-record preview and explicit merge/write authorization for a later production batch.

3. New external enrichment recipients, shared reports, persistent connector access and messages require separate permission.

Unexecuted validation plan

Fixture

Proposed synthetic fixture: 12 records including one exact legal-entity duplicate, two unrelated namesakes, two contacts sharing a role inbox, one industry alias, a protected-preference conflict, a stale opportunity and one missing activity date. Rules fix the as_of date and define a greater-than-30-day threshold. No run performed.

Acceptance checks

1. Exactly the intended legal-entity pair is eligible for review; namesakes and shared inboxes are blocked rather than merged.

2. Every proposal cites record IDs, raw before values, approved rule and evidence; conflicting preferences remain unchanged.

3. The stale example computes 43 days for 2026-09-01 to 2026-10-14; missing activity is an unknown-history queue item.

4. Counts reconcile to the fixture, there are no duplicate record/field proposals, and a future execution log shows zero writes.

Stop conditions

1. The agent calls any mutation or enrichment service.

2. An ambiguous identity is treated as a confirmed duplicate.

3. The exact source record or recovery dependency cannot be established.

Executed

No

Limits

1. The vendor report is firsthand marketing evidence, not an independently tested cleanup.

2. The inspected MCP page advertises cleanup, but its visible tool list does not specify a dedicated merge tool; the safe proposed workflow stops at previews.

3. One older Gumloop node-documentation link returned 404, so it was not used to assert current API compatibility.

4. Canadian contact-data requirements and tenant-specific security were not assessed.

Guide source links

https://www.gumloop.com/blog/salesforce-ai-agents ↗
Original recipe or report; see documented_steps locators.

https://gusto.gumloop.com/mcp/salesforce ↗
Gumloop/Salesforce setup and visible query, metadata and update tool definitions; no verified merge implementation.