Public evidence index / CRM operations
Preview Salesforce cleanup decisions before any record changes
This is the evidence and fixed scope for a proposed Salesforce record-deduplication and field-normalization product. It is for a Salesforce administrator or RevOps lead who needs to understand which Accounts, Contacts, and Leads are safe to normalize, which pairs deserve duplicate review, and exactly why each recommendation exists.
No Salesforce package, OAuth connection, AppExchange listing, checkout, customer fixture, payment, contract, or security-review approval exists for this demand test. The request form takes no payment and asks for no CRM data.
The fixed founding-organization pilot
The proposed $249 one-time pilot reviews one accepted, buyer-controlled export containing no more than 10,000 Account, Contact, and Lead rows. It returns a CSV decision manifest and a human-readable HTML audit receipt within ten business days after the field map, handling terms, and non-production transfer method are accepted. It is a bounded preview of the decision contract, not a subscription and not an installed Salesforce app. There is no automatic renewal to cancel.
Included
- Exact normalized-email duplicate candidates for Contacts and Leads, and exact normalized website-plus-phone candidates for Accounts.
- Formatting proposals for accepted email, phone, website, state, whitespace, and enumeration fields.
- Source Salesforce record IDs, untouched original values, proposed values, the exact matching or formatting rule, and a confidence label on every finding.
- A separate queue for low-confidence pairs that lack a decisive key. These pairs receive no merge recommendation.
- A CSV decision manifest and HTML audit receipt showing counts, exclusions, unknowns, and the fixture hash.
Explicitly excluded
- No merge, delete, update, reparent, relationship change, workflow trigger, or other write to Salesforce.
- No production OAuth grant, managed package, Apex trigger, scheduled job, or AppExchange installation.
- No enrichment purchase, guessed business fact, identity resolution, lead scoring, deliverability promise, or legal or compliance conclusion.
- No review of Opportunities, Cases, Activities, attachments, files, custom objects, or records outside the accepted field map.
- No claim that a formatting match proves two people or companies are the same. A human remains the decision owner.
Proof-carrying acceptance rule. Every proposed merge or normalized value keeps its source record IDs, original fields, exact rule, confidence, and write_applied false. A future app cannot pass by emitting only a score or a generic “possible duplicate” label. The decision must be replayable from the preserved evidence, and a failure to recover that evidence is reported as unknown.
What the synthetic reference proves
The public receipt exercises the proposed manifest on 8 invented records using reserved .example domains. It covers Account, Contact, and Lead shapes. The deterministic probe emits 2 high-confidence duplicate proposals, queues 1 low-confidence pair without a merge recommendation, and records 9 formatting proposals. It emits 0 writes. Those figures are counted from the frozen receipt served beside this page, not borrowed from a previous report.
The Account example requires both an exact normalized website host and an exact normalized phone number. The Contact example requires an exact normalized email. The weaker Lead pair shares only a normalized company and last name, so the receipt labels it low confidence and routes it to review without recommending a merge. This distinction matters because a loose company-name match can collapse unrelated branches, franchises, or people. A result that cannot support its decision with the frozen rule stays out of the high-confidence group.
Field normalization is proposal-only. The receipt preserves an original value such as a formatted telephone number, the proposed E.164-shaped value, the rule identifier, confidence, source record ID, and write_applied: false. It does not prove that a proposed value satisfies a buyer's validation rules or that the buyer should accept it. It proves that the reference logic can retain both sides of the decision and fail closed on a weak match.
Inspect the machine-readable reference receipt. The checked-in generator rebuilds the receipt from its embedded synthetic fixture and exits nonzero when the stored receipt differs.
The incumbent market is established, not empty
Observation date: 2026-08-09. The official AppExchange pages fetched on showed mature record-quality products with public pricing or substantial rating histories. These observations establish that Salesforce teams seek deduplication and data-quality software. They do not establish paid seats, current active use, retention, revenue, buyer identity, or conversion for this proposed pilot. Displayed prices belong to the listed vendors, not to us.
| Comparable | Pricing displayed | Rating count displayed | Observed position |
|---|---|---|---|
| Cloudingo | Paid; starting at $2,500/company/year; displayed tiers $6,000 and $10,000 | 559 | Salesforce data deduplication and data quality |
| DemandTools | Paid; no public price observed in the fetched collection response | 442 | Data quality and deduplication |
| DataGroomr | Paid; $199/company/year; displayed tiers $1,495, $2,895, and $5,795 | 102 | Data cleansing and duplicate management |
| Plauti Deduplicate | Free | 300 | Duplicate management |
Cloudingo was displayed as paid, starting at $2,500 per company per year, with additional displayed tiers at $6,000 and $10,000 and a rating count of 559. DemandTools was displayed as paid with no public price in the fetched collection response and a rating count of 442. DataGroomr showed a $199 per-company yearly level plus displayed tiers at $1,495, $2,895, and $5,795 and a rating count of 102. Plauti Deduplicate was displayed as free with a rating count of 300.
That comparison makes a generic “find duplicates” pitch insufficient. Free and paid incumbents already occupy it. The narrow wedge tested here is a provenance manifest for every proposed merge and normalization: record IDs, original fields, rule, confidence, review state, and an explicit zero-write receipt. The pilot asks whether an administrator values that replayable QA boundary enough to request a bounded scope before anyone funds an AppExchange build.
Download the dated market-probe receipt, source URLs, response hashes, and interpretation limits.
AppExchange admission cost is currently unknown
Two official Salesforce partner-education pages returned HTTP 200 during this probe but gave different figures for the paid-app security-review fee. The Security Review page said $2,700 initially for each paid app plus a $150 annual listing fee and displayed a four-to-six-week review period. The AppExchange Listing page said $2,550 as a one-time security-review fee for a paid app plus a $150 annual listing fee. Because the controlling official pages disagree, the current admission cost is UNKNOWN. Choosing the larger or smaller value would manufacture certainty the sources do not provide.
This run did not create a partner account, accept an agreement, submit a package, or spend money. A free public demand test requires none of those actions. If a qualified buyer signal later justifies a packaged app, the first marketplace step is to obtain the current fee and process directly from Salesforce's Partner Security Portal or an authorized partner contact. Any actual fee payment would then require the operator because money would leave an account; this public page does not request or pre-authorize it.
The discrepancy is a useful Stage-1 result. It prevents a false build budget and keeps marketplace submission behind evidence. The market receipt preserves both official URLs and both fetched response hashes, so a later run can re-fetch them and report changed, unchanged, or unknown rather than trusting this dated observation forever.
Acceptance rules for a future app
- Read first, never silently write. A packaged beta starts in preview mode. Any future write mode must be separately enabled, must preserve an audit record, and must have a tested reversal plan. This pilot never enters write mode.
- Keep record-level provenance. Each candidate pair names all source record IDs and fields. Each formatting proposal retains original and proposed values. A summary total is not a substitute for the underlying decision rows.
- Use closed rules. High-confidence groups use declared exact normalized keys. Weak name or company similarity stays in a low-confidence queue. Missing inputs remain missing rather than being filled with guessed facts.
- Fail closed. An unreadable fixture, unsupported field shape, missing receipt, invalid schema, or rule failure returns unknown or a nonzero probe result. It never becomes zero findings or a passing result.
- Prove reversal before write access. A future package must demonstrate rollback behavior on a real, authorized sandbox fixture and preserve before-and-after values before any production write feature can be considered.
These are product gates, not claims that they have already been met. The public probe covers only a small synthetic fixture and proposal schema. It does not exercise Salesforce limits, sharing rules, field-level security, duplicate rules, automation side effects, large-data-volume performance, managed-package upgrades, sandbox refreshes, or production rollback. Those remain unknown until a qualified pilot supplies an accepted test shape.
From demand test to AppExchange candidate
- Qualify the job. A Salesforce administrator describes the relevant objects, approximate record count, fields used for identity, current duplicate rules, and the decisions that create the most review risk. The public form asks for scope only; it must not receive credentials, exports, access tokens, private links, or customer records.
- Prove the manifest off-platform. After a human accepts scope and data-handling terms, one suitable buyer-controlled export can test whether the record-ID-bound receipt is useful. Delivery remains review-only and never authorizes a Salesforce connection.
- Build only after a real acceptance case. A future beta must pass deterministic fixtures, a buyer-authorized sandbox, security and privacy review, access-control tests, rate-limit behavior, reversal tests, and the current AppExchange process. A public request alone is not permission to install or process data.
Demand-test boundary: product-specific requests are counted separately from page reach. Our own probes, search crawlers, rating counts, and AppExchange page fetches are never buyer demand. A request is not a payment, contract, accepted dataset, partner agreement, or permission to build.
Questions a Salesforce team should ask
Will the pilot merge or update records?
No. The offer is a review-only export analysis and audit receipt. It does not connect to Salesforce or apply any change. Every finding states write_applied: false. A buyer remains responsible for reviewing and applying or rejecting any proposal through its own controlled process.
Does a high-confidence key prove identity?
No. It means the declared normalized fields match exactly under the reference rule. Shared mailboxes, recycled phone numbers, corporate domains, household accounts, and stale data can still produce unsafe decisions. Confidence prioritizes review; it does not replace it.
Is $249 the future AppExchange subscription price?
No. It is a one-time founding-organization pilot price borrowed from the existing operator-locked one-time offer shape. It covers one accepted preview scope and has no automatic renewal. Any later application license would be a different offer requiring fresh scope, pricing, marketplace disclosure, and a completed product.
Why not build the package first?
AppExchange has established incumbents and a paid review gate whose current official cost statements conflict. The useful unknown is whether a real administrator wants the narrower provenance-and-reversal contract. The public receipt lets that buyer inspect the proposed evidence shape before anyone creates a package or incurs marketplace cost.