CRM Cleanup Automation Prompt

Public field comparison

CRM Cleanup Automation Prompt

CRM Cleanup Automation Prompt

Plan CRM cleanup rules for duplicates, missing fields, stale records, lifecycle stages, and safe automation.

Design an evidence-based CRM cleanup plan for duplicate records, missing or invalid fields, stale data, lifecycle errors, and controlled automation.

—

Use this prompt to turn CRM exports, governance rules, and platform constraints into reviewable cleanup rules, safe automation specifications, and measurable acceptance tests.

CRM Cleanup Automation
Requirements Clarification
Output Quality Review
Review Checklist Building
Implementation Planning

Designing duplicate detection, merge, and field-survivorship rules
Planning governed cleanup of missing, invalid, or stale CRM data
Reconciling CRM lifecycle stages across workflows and integrations
Specifying controlled CRM cleanup automation with rollback and acceptance tests

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

CRM platform and cleanup scope
Cleanup objectives and acceptance thresholds
Data dictionary and lifecycle rules
Data profile and sample records
Duplicate matching and merge policy
Retention privacy and compliance constraints
Automation capabilities and integration map
Approval owners and change window

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In ChatGPT, replace every bracketed variable with your CRM-specific information. Provide the relevant CRM exports or representative redacted samples, data dictionary, lifecycle definitions, duplicate and merge policy, retention and consent rules, integration map, platform documentation, baseline reports, and approval constraints. Remove secrets and unnecessary personal data, then run the prompt. Answer blocking questions before authorizing any merge, bulk update, archive, deletion, or production automation.

Use this when you need a production-ready crm automation result in Automation, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A company using Salesforce has duplicate contacts from web forms and an ERP sync, inconsistent lifecycle stages, missing account links, and old leads of uncertain retention status. Supply redacted exports, field definitions, synchronization rules, consent and retention policies, merge constraints, and acceptance thresholds. ChatGPT will produce a duplicate-matching and survivorship specification, stale-record decision rules, lifecycle reconciliation logic, an automation catalog, approval gates, rollback controls, and a verification matrix without claiming that changes were executed.

Expert

Expert

ChatGPT

ChatGPT

crm automation

crm automation

chatgpt
automation
crm
data hygiene

chatgpt
automation
crm
data hygiene
deduplication
data-governance

CRM Cleanup Automation Prompt | AMO.ng

CRM Cleanup Automation Prompt | AMO.ng

Plan CRM cleanup rules for duplicates, missing fields, stale records, lifecycle stages, and safe automation.

Design safe CRM cleanup rules for duplicates, missing fields, stale records, lifecycle stages, rollout controls, and measurable verification.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Automation specialist using ChatGPT. Your task is: [Goal or task].
+Develop a production-ready CRM cleanup and automation specification using the following inputs.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Required inputs:
+- CRM platform and cleanup scope: [CRM platform and cleanup scope]
+- Cleanup objectives and acceptance thresholds: [Cleanup objectives and acceptance thresholds]
+- Data dictionary and lifecycle rules: [Data dictionary and lifecycle rules]
+- Data profile, exports, or representative sample records: [Data profile and sample records]
+- Duplicate matching and merge policy: [Duplicate matching and merge policy]
+- Retention, privacy, and compliance constraints: [Retention privacy and compliance constraints]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "CRM Cleanup Automation Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Useful operational context:
+- Automation capabilities, integrations, and synchronization paths: [Automation capabilities and integration map]
+- Approval owners, maintenance window, and rollback authority: [Approval owners and change window]
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Input handling:
+1. Confirm the CRM objects in scope, record volumes, immutable identifiers, source systems, systems of record, synchronization direction, and applicable business units.
+2. Treat the data dictionary, approved lifecycle definitions, retention policy, consent records, and supplied CRM evidence as authoritative only within their stated scope. Separate supplied facts, observed data patterns, assumptions, hypotheses, conflicts, and unknowns.
+3. Ask concise clarification questions if a missing input prevents safe decisions about merging, deletion, consent, retention, lifecycle changes, or rollback. Otherwise, continue with a bounded draft, identify the missing evidence, and mark affected recommendations as unverified or blocked.
+4. Never invent field values, platform capabilities, record counts, test results, approvals, or execution evidence. If samples are incomplete or nonrepresentative, state that limitation before estimating impact.
 
−Do not give generic advice. Optimize for a production-quality crm automation outcome.
+Analysis and design workflow:
+1. Establish a baseline inventory by object and field. Report record counts when supplied; null and invalid-value rates; malformed dates, emails, phone numbers, and identifiers; orphaned relationships; conflicting source values; impossible lifecycle combinations; stale-record candidates; and duplicate candidates. Show the query, filter, export column, report, or sample evidence behind each finding when available.
+2. Define normalization rules before duplicate matching. Cover casing, whitespace, punctuation, phone country codes, email normalization, company suffixes, addresses, Unicode, aliases, and intentionally shared contact details. Preserve raw values or an auditable before-state where required.
+3. Design duplicate detection separately for each object. Specify candidate-generation keys, exact and fuzzy comparisons, field weights, thresholds, exclusions, confidence bands, and manual-review zones. Address false-positive and false-negative trade-offs, parent-child records, cross-business-unit collisions, person-versus-company ambiguity, and records created by integrations.
+4. Define merge and survivorship behavior. Identify the winning record and field-level source precedence; preserve immutable and external IDs, ownership, consent and lawful-basis data, activities, notes, attachments, campaign membership, opportunities, cases, relationships, and audit history. If the CRM cannot safely merge an artifact, specify quarantine, relinking, or manual handling instead.
+5. Define missing-field and invalid-value treatment by field. Distinguish values that may be standardized, values that may be backfilled from an approved source, values requiring owner review, and values that must remain unknown. Do not infer or fabricate personal, consent, financial, or contractual data merely to satisfy completeness rules.
+6. Define stale-record policy using explicit inactivity signals and time windows. Exclude or separately review records subject to legal hold, retention requirements, active opportunities, open support cases, active subscriptions, recent engagement, unresolved consent status, or downstream dependencies. Compare suppression, archive, quarantine, and deletion; recommend deletion only when policy, authority, recovery, and dependency checks support it.
+7. Reconcile lifecycle stages and statuses against approved entry, exit, regression, and terminal-state rules. Detect contradictory stages, skipped prerequisites, reopened records, stale timestamps, and automation-created loops. Define the evidence required for each correction and how synchronized systems could overwrite it.
+8. Convert approved cleanup logic into an automation design. For every rule, specify trigger, scope filter, exclusions, precedence, action, idempotency key or rerun behavior, batch size, rate-limit handling, retry policy, error queue, audit fields, notifications, and integration side effects. Identify race conditions, recursion, workflow conflicts, and ordering dependencies.
+9. Create a controlled rollout: read-only profiling, versioned rule review, snapshot or recoverable backup, sandbox test, dry run, reviewer sampling, canary batch, reconciliation, staged production batches, monitoring, and rollback. Include stop conditions for unexpected match rates, relationship loss, consent changes, excessive errors, sync divergence, or metrics outside approved thresholds.
+10. Require named human authorization before enabling workflows, merging records, bulk updating lifecycle stages, archiving, deleting, or changing retention and consent data. ChatGPT may analyze supplied material and draft rules, queries, pseudocode, test cases, and implementation instructions; it cannot access the CRM, execute changes, verify live results, or grant approval unless independently supplied evidence demonstrates those events.
+
+Required deliverable:
+A. Scope and evidence ledger
+- CRM objects, systems, volumes, sources of truth, assumptions, unknowns, conflicts, and blocking gaps.
+- For each material assertion: evidence source, observation, confidence, and limitation.
+
+B. Data-quality baseline
+- Table with object, issue class, detection rule, affected count or unavailable status, denominator, rate, severity, sample evidence, and business impact.
+
+C. Cleanup rule catalog
+- Table with rule ID, object, issue, eligibility condition, exclusions, action, source precedence, confidence threshold, review requirement, downstream effects, reversibility, and owner.
+- Include dedicated subsections for duplicates and survivorship, missing or invalid values, stale records, and lifecycle-stage reconciliation.
+
+D. Automation specification
+- Table with rule ID, platform mechanism, trigger or schedule, dependencies, processing order, idempotency behavior, batch and rate limits, retry handling, exception queue, audit logging, alerts, and disable control.
+- Use platform-neutral pseudocode when platform syntax or capabilities are not evidenced. Label any platform-specific configuration as proposed until confirmed.
+
+E. Safety, approval, and recovery plan
+- Data minimization and access controls; redaction of secrets and unnecessary personal data; backup or snapshot requirement; sandbox and dry-run controls; protected-record exclusions; approval gates; stop conditions; rollback steps; and post-rollback reconciliation.
+
+F. Verification matrix
+- For every cleanup rule, provide test case, representative input, expected observation, actual observation or not executed, evidence location, pass threshold, and status.
+- Include tests for duplicate precision and recall using a reviewed sample, false merges, missed duplicates, survivorship, relationship preservation, required-field validity, lifecycle transition validity, stale-record exclusions, consent preservation, automation reruns, retries, rollback, integration reconciliation, and audit-log completeness.
+- Quantify acceptance criteria from the supplied thresholds. If no threshold is authorized, propose one with rationale and mark it pending approval.
+
+G. Rollout and handoff
+- Ordered implementation batches, responsible owner, required approval, monitoring metric, decision checkpoint, rollback trigger, unresolved issues, and the smallest safe next action.
+
+Status and claim rules:
+- Label each item as proposed, awaiting evidence, blocked, approved based on supplied evidence, executed based on supplied evidence, verified based on supplied evidence, or unresolved.
+- Do not claim that records were cleaned, merged, deleted, tested, approved, deployed, or verified unless the corresponding action occurred and supporting evidence was provided. Keep recommendations and expected outcomes distinct from observed results.