Data Quality Findings and Product Decisions
Findings
| id | severity | statement | affects | evidence | kind |
|---|---|---|---|---|---|
FND-CRM-DQ-001 | medium | The draft scope registration excludes important console components, test inventories and shared merge checks. Its corrected source list includes the module entry points and the recorded permission decision. | MOD-CRM-DQ | Structured evidence | inconsistency |
FND-CRM-DQ-002 | low | Journey automation flags lag the accompanying Playwright files. File presence establishes an authored test, while runnable behavior must still be checked independently. | JNY-CRM-DQ-001, JNY-CRM-DQ-002, JNY-CRM-DQ-003, JNY-CRM-DQ-004, JNY-CRM-DQ-005, JNY-CRM-DQ-006 | Structured evidence | inconsistency |
FND-CRM-DQ-003 | medium | The older acceptance inventory conflicts with current blocking, exception audit, confidence bands and transient-only retry behavior. The capabilities describe the pinned behavior and preserve the earlier inventory references. | CAP-CRM-DQ-002, CAP-CRM-DQ-003, CAP-CRM-DQ-004, CAP-CRM-DQ-016 | Structured evidence | inconsistency |
FND-CRM-DQ-004 | high | The milestone remains proposed without an approved retroactive plan, while the architecture and experience overviews record earlier approval and acceptance and subordinate chapters still carry draft labels. Recorded decisions and explicit overview approvals support confirmed intent, but Product needs to settle the inconsistent authority trail. | MOD-CRM-DQ, FEAT-CRM-DQ-01, FEAT-CRM-DQ-02, FEAT-CRM-DQ-03, FEAT-CRM-DQ-04, FEAT-CRM-DQ-05 | Structured evidence | inconsistency |
FND-CRM-DQ-005 | medium | The design restricts plan changes to the creator, whereas current read-and-merge authority permits any qualified workspace administrator to edit the plan. | CAP-CRM-DQ-012, BR-CAP-CRM-DQ-012-11, OQ-CRM-DQ-001 | Structured evidence | inconsistency |
FND-CRM-DQ-006 | medium | Expiry closes overdue plans but does not delete them. The documented seven-day cleanup after expiry or execution is absent, leaving working snapshots of personal information retained indefinitely. | CAP-CRM-DQ-012, BR-CAP-CRM-DQ-012-10 | Structured evidence | inconsistency |
FND-CRM-DQ-007 | low | The architecture describes five-minute settlement for a lost merge start, while the API description and journey describe fifteen minutes. The documents need one timing contract. | CAP-CRM-DQ-016, BR-CAP-CRM-DQ-016-05 | Structured evidence | inconsistency |
FND-CRM-DQ-008 | low | The unknown-reference blocker computes affected counts but identifies a storage column instead of the application requested by the product decision. | CAP-CRM-DQ-015, BR-CAP-CRM-DQ-015-02 | Structured evidence | debt |
FND-CRM-DQ-009 | medium | Contact merging publishes a committed business event despite an older architecture description saying it is absent. Organization merging has no equivalent event although the catalogue names one. | CAP-CRM-DQ-016, BR-CAP-CRM-DQ-016-13, OQ-CRM-DQ-005 | Structured evidence | undocumented |
FND-CRM-DQ-010 | medium | The recorded retention decision includes removing individual originals on privacy request, but no operation provides that removal and ordinary application writes cannot alter or delete merge records. | CAP-CRM-DQ-019, BR-CAP-CRM-DQ-019-06, OQ-CRM-DQ-002 | Structured evidence | debt |
FND-CRM-DQ-011 | medium | Accounting requests survivor resolution through record reads and datasets. The milestone records that request as planned, while the required query exposure remains absent. | CAP-CRM-DQ-018, BR-CAP-CRM-DQ-018-10, OQ-CRM-DQ-003 | Structured evidence | debt |
FND-CRM-DQ-012 | medium | Planned console management for re-checks, manual confirmation and unfinished plans is missing. The corresponding service operations exist, but the cited journey surfaces cannot perform those flows. | BR-CAP-CRM-DQ-005-11, BR-CAP-CRM-DQ-009-06, CAP-CRM-DQ-005, CAP-CRM-DQ-009, CAP-CRM-DQ-012, OQ-CRM-DQ-004 | Structured evidence | debt |
FND-CRM-DQ-013 | low | The duplicate API chapter retains a not-built draft label although the pinned routes expose the described operations and include end-to-end tests. | CAP-CRM-DQ-007, CAP-CRM-DQ-008 | Structured evidence | inconsistency |
FND-CRM-DQ-014 | low | The API document assumes organizations have no record history. Their ordinary history exists, but absorbed-organization history still lacks an equivalent survivor route. | CAP-CRM-DQ-018, CAP-CRM-ENT-016 | Structured evidence | inconsistency |
FND-CRM-DQ-015 | low | The architecture retains reference-count-then-age survivor ranking, while the later recorded ruling places a sole portal login and integration identity ahead of those signals. | CAP-CRM-DQ-012, BR-CAP-CRM-DQ-012-03 | Structured evidence | inconsistency |
FND-CRM-DQ-016 | medium | Import-tagged events are skipped for a promised completion pass that has no caller. Current captured changes lack the marker and receive per-record detection; connecting the marker first would suppress detection without a replacement. | CAP-CRM-DQ-001, BR-CAP-CRM-DQ-001-11 | Structured evidence | debt |
FND-CRM-DQ-017 | low | The duplicate-group attention declaration remains held because its target metadata object is unregistered, so responsibility holders currently receive no items. | CAP-CRM-DQ-011, BR-CAP-CRM-DQ-011-07 | Structured evidence | debt |
FND-CRM-DQ-018 | medium | The documents cite later permission and common-key rulings without corresponding milestone entries. The recorded read-history ruling belongs to the access milestone, so unrecorded decision references do not independently establish approval. | BR-CAP-CRM-DQ-001-05, BR-CAP-CRM-DQ-019-08, CAP-CRM-DQ-019 | Structured evidence | inconsistency |
FND-CRM-DQ-019 | low | The seeded portal flag is stored without affecting registration; portal matching does not read workspace duplicate settings. | BR-CAP-CRM-DQ-003-10, CAP-CRM-DQ-006 | Structured evidence | undocumented |
FND-CRM-DQ-020 | medium | The initial scoring weights lack recorded calibration or demonstrated per-band precision against the planned targets. The cited performance evidence covers contacts rather than the complete scoring model. | BR-CAP-CRM-DQ-002-11, CAP-CRM-DQ-002 | Structured evidence | debt |
FND-CRM-DQ-021 | low | The older exception journey declares its control missing although the current refusal dialog offers an authorized, explained exception. An earlier acceptance entry also omits the audit now required by the blocking decision. | CAP-CRM-DQ-004, JNY-CRM-DQ-005, CAP-CRM-ENT-001 | Structured evidence | inconsistency |
FND-CRM-DQ-022 | medium | Hard deletion of a survivor leaves its aliases pointing to an absent record. Older identities still report merging, so the documented live-destination guarantee fails. | BR-CAP-CRM-DQ-018-09, CAP-CRM-DQ-018, CAP-CRM-ENT-014 | Structured evidence | defect |
FND-CRM-DQ-023 | low | The console launcher admits duplicate readers alongside either merge permission, allowing a reviewer to enter before the service rejects missing type-specific planning authority. | CAP-CRM-DQ-012 | Structured evidence | inconsistency |
FND-CRM-DQ-024 | low | CRM tests establish portal-login preview behavior, while Platform owns relinking and the multiple-login refusal. The full browser flow is blocked by unavailable login fixtures, and Platform execution lies outside this read scope. | BR-CAP-CRM-DQ-015-06, CAP-CRM-DQ-015 | Structured evidence | debt |
| FND-CRM-DQ-025 | medium | The requested planning brief is absent from the starting checkout and fetched default branch, so the examination cannot check the draft against that brief. | MOD-CRM-DQ | Structured evidence | debt |
| FND-CRM-DQ-026 | medium | The organization affiliation unit test omits dependent-row identities and preserves the preview when only the move count grows; the production planner includes those identities and versions, so adding a moved affiliation changes approval. | BR-CAP-CRM-DQ-017-09, ATS-CRM-DQ-017 | Structured evidence | inconsistency |
| FND-CRM-DQ-027 | medium | The handler-failure integration test verifies error results and unchanged keys, but does not assert a successful save response or queue redelivery; the acceptance scenario overstates that binding. | ATS-CRM-DQ-001-01, BR-CAP-CRM-DQ-001-01, BR-CAP-CRM-DQ-001-10 | Structured evidence | debt |
| FND-CRM-DQ-028 | low | Reading a re-check validates the requested record type but fetches the run by identity alone; a contact path can therefore return an organization run from the same workspace. | CAP-CRM-DQ-005 | Structured evidence | undocumented |
| FND-CRM-DQ-029 | medium | Preview labels are readable when names exist, but missing-label fallbacks and stale-change descriptions can expose internal references; the original blanket claim about every sentence is too strong. | BR-CAP-CRM-DQ-013-10, ATS-CRM-DQ-013-08 | Structured evidence | debt |
| FND-CRM-DQ-030 | medium | The original stale-preview journey refreshes the stored plan before requesting execution without an earlier submitted fingerprint, which removes the mismatch it expects; the corrected sequence submits the earlier approval before refreshing. | JNY-CRM-DQ-003 | Structured evidence | inconsistency |
| FND-CRM-DQ-031 | high | Several browser specifications deliberately stop before the claimed behavior because the harness lacks portal, re-check, manual-confirmation, security or database controls; their presence does not constitute a runnable proof. Composite lock-wait and thirty-day-boundary scenarios also exceed their bindings. | ATS-CRM-DQ-005-06, ATS-CRM-DQ-011-04, ATS-CRM-DQ-016-13, ATS-CRM-DQ-017-09, JNY-CRM-DQ-004, SC-CAP-CRM-DQ-005-02, SC-CAP-CRM-DQ-006-02, SC-CAP-CRM-DQ-009-02, JNY-CRM-DQ-005 | Structured evidence | debt |
| FND-CRM-DQ-032 | medium | Previously optional proof flags include calculations and refusal or record-change behavior; these rules now require acceptance proof, and any not covered by existing scenarios remain explicit proof gaps. | BR-CAP-CRM-DQ-003-08, BR-CAP-CRM-DQ-004-11, BR-CAP-CRM-DQ-006-03, BR-CAP-CRM-DQ-008-10, BR-CAP-CRM-DQ-008-11, BR-CAP-CRM-DQ-013-11, BR-CAP-CRM-DQ-014-11, BR-CAP-CRM-DQ-016-11, BR-CAP-CRM-DQ-016-14, BR-CAP-CRM-DQ-017-08 | Structured evidence | debt |
| FND-CRM-DQ-033 | high | The pinned blocking browser journey still expects candidates hidden by a blocking rule and organization creation to bypass blocking, contradicting the current service and recorded blocking decision. It also expects the old missing exception control, so those assertions cannot prove the current behavior. | JNY-CRM-DQ-005, BR-CAP-CRM-DQ-003-02, BR-CAP-CRM-DQ-004-10 | Structured evidence | inconsistency |
| FND-CRM-DQ-034 | medium | The registered console scope includes duplicate components and the data-quality and merge pages, but excludes the configuration page and ordinary record-page mounts. Their route guards and mounted entry behavior cannot be independently established here; service authority and scoped components remain verified. | MOD-CRM-DQ, BR-CAP-CRM-DQ-003-09, CAP-CRM-DQ-010 | Structured evidence | debt |
| FND-CRM-DQ-035 | low | The design layer cites the Platform queued-work, jobs, record-history and row-level-security standards through the CRM records that apply them, because the Platform repository was not available to this design job; the standard each mechanism follows is named but was not re-read at a pinned commit. | SVC-CRM-DQ-duplicates, SVC-CRM-DQ-merges, ADR-CRM-DQ-014, ADR-CRM-DQ-008 | Structured evidence | debt |
| FND-CRM-DQ-036 | medium | The module's registered source paths omit execution pieces the design depends on: the job reconciler and its schedule, the record-merge and re-check names, the portal sign-up migration, the workspace lifecycle participants and the Entities calls that record exceptions and regroup on delete. | MOD-CRM-DQ, WF-CRM-DQ-007, WF-CRM-DQ-008, WF-CRM-DQ-009 | Structured evidence | inconsistency |
| FND-CRM-DQ-037 | low | The module performs no inference and has no inference directory, but the module charter does not yet say so in the one sentence the conventions require; this design job may not edit the charter. | MOD-CRM-DQ | Structured evidence | inconsistency |
| FND-CRM-DQ-038 | medium | Reading an open merge plan stores its recomputation and hash whenever records moved, so any qualified colleague opening the plan re-arms approval and can make another person's pending change stale; the read operation is not free of side effects. | DOM-CRM-DQ-003, WF-CRM-DQ-005, ADR-CRM-DQ-007, BR-CAP-CRM-DQ-013-12, BR-CAP-CRM-DQ-016-02, OQ-CRM-DQ-006 | Structured evidence | undocumented |
| FND-CRM-DQ-039 | medium | The re-check dispatcher re-offers a sent batch after a ten-minute claim while the queue hides a delivered message for thirty minutes, so a batch can be processed twice at once; a batch whose consumer dies on its final delivery is never marked failed and is re-sent indefinitely, leaving its run running. | WF-CRM-DQ-002, STATE-CRM-DQ-003, BR-CAP-CRM-DQ-005-07, ADR-CRM-DQ-014 | Structured evidence | defect |
| FND-CRM-DQ-040 | low | Batches of a failed re-check are still dispatched and processed and still move the run counters, so a failed run keeps loading the database and can overlap a new run of the same type; the persistence comment also claims a table uniqueness for unfinished runs that is in fact an advisory lock. | WF-CRM-DQ-002, STATE-CRM-DQ-003, BR-CAP-CRM-DQ-005-02, BR-CAP-CRM-DQ-005-07 | Structured evidence | defect |
| FND-CRM-DQ-041 | high | A merge plan's expiry instant is set seven days after it is started and no change extends it, contradicting the approved rule of seven days after the last change; the sweep also does not exclude executing plans, so a plan executed near its expiry can be marked expired while its merge runs and then cannot be reopened after a failure. | BR-CAP-CRM-DQ-012-10, STATE-CRM-DQ-004, WF-CRM-DQ-007, ADR-CRM-DQ-018, DOM-CRM-DQ-003 | Structured evidence | defect |
| FND-CRM-DQ-042 | low | The record-merge job type declares only the contact merge permission as its submit permission for both record types; routes enforce the right permission per type, but job-engine views and permission manifests show organization merges under the contact key. | SVC-CRM-DQ-merges, ADR-CRM-DQ-008 | Structured evidence | inconsistency |
| FND-CRM-DQ-043 | medium | The requested module design brief is absent from the starting checkout. Examination uses the task instructions, templates and planning corpus, leaving comparison with that brief unavailable. | MOD-CRM-DQ | Structured evidence | debt | | FND-CRM-DQ-044 | medium | The draft wrongly excludes dismissed and confirmed pairs from rescoring. Detection upserts qualifying pairs without filtering their standing, preserving the decision fields while replacing scores and reasons; a manually confirmed pair can therefore lose its full score. | STATE-CRM-DQ-001, DOM-CRM-DQ-001, BR-CAP-CRM-DQ-009-02 | Structured evidence | inconsistency | | FND-CRM-DQ-045 | medium | The detection pass writes keys before opening its pair-and-group transaction. The cited failure test throws on the first transaction and does not prove rollback after key replacement; pass-wide atomicity and comparison at commit are unsupported guarantees. | WF-CRM-DQ-001, STATE-CRM-DQ-001 | Structured evidence | debt | | FND-CRM-DQ-046 | medium | The draft reports a rolled-back merge as running and implies lock-timeout retries. The running claim is uncommitted and rolls back to queued; executor errors normally settle failure and become a task refusal, including a caught lock timeout. Planning retry language exceeds this behavior. | WF-CRM-DQ-006, STATE-CRM-DQ-005, ADR-CRM-DQ-005, BR-CAP-CRM-DQ-016-11 | Structured evidence | inconsistency | | FND-CRM-DQ-047 | medium | Several draft screens describe service response fields as visible controls and name generic or approved patterns without component evidence. The overview hides unused summary fields and its Review action needs review authority; the history adapter explicitly requests all attempt statuses although the service default is successful merges; the management details page requires merge-read even when its component can call a record-read operation. Member removal and rule reordering use separate requests, so a later failure can preserve partial changes. | SCR-CRM-DQ-001, SCR-CRM-DQ-005, SCR-CRM-DQ-006, SCR-CRM-DQ-007, SCR-CRM-DQ-009 | Structured evidence | inconsistency | | FND-CRM-DQ-048 | low | Some invariant citations prove only part of the claimed guarantee. Plan participant uniqueness is enforced by the service rather than its table check, job uniqueness means at most one rather than database-mandated existence, and expiry and workspace-isolation citations need their actual persistence and policy sources. | DOM-CRM-DQ-001, DOM-CRM-DQ-003, DOM-CRM-DQ-004 | Structured evidence | debt | | FND-CRM-DQ-049 | low | The draft makes Entities persistence the sole writer of every contact, organization and affiliation change. Merging also applies reference rewrites, moves affiliations and prepares the organization parent through merge-owned persistence; ordinary survivor save and participant deletion still call Entities. | ADR-CRM-DQ-001, RESP-CRM, ADR-CRM-DQ-012 | Structured evidence | inconsistency | | FND-CRM-DQ-050 | medium | Re-checks store record windows rather than frozen membership. Processing reads current records within each window, so later inserted identities inside it can be included and deleted records disappear; initial totals remain fixed and excess processed records can violate the progress check. | WF-CRM-DQ-002, STATE-CRM-DQ-003, BR-CAP-CRM-DQ-005-03 | Structured evidence | inconsistency | | FND-CRM-DQ-051 | medium | CRM-owned portal functions and lifecycle participants are verified, but the draft assigns unverified behavior to Platform: empty suggestions on candidate failure and automatic provisioning or purge retries. Those caller policies remain unknown without the pinned owner implementation. | WF-CRM-DQ-008, WF-CRM-DQ-009 | Structured evidence | debt | | FND-CRM-DQ-052 | medium | The service-wide internal-use classification does not identify the personal class of duplicate evidence and merge snapshots containing people’s original and resulting values. | SVC-CRM-DQ-duplicates, SVC-CRM-DQ-merges, CAP-CRM-DQ-019 | TC-DAT-001; structured control evidence | control-gap | | FND-CRM-DQ-053 | medium | Restoring a duplicate pair clears the earlier dismissal actor, time and explanation in the mutable candidate; the examined path retains only the new modification stamp rather than append-only history of both decisions. | CAP-CRM-DQ-008, WF-CRM-DQ-004, SVC-CRM-DQ-duplicates | TC-LOG-002, TC-LOG-003; structured control evidence | control-gap |
Open Questions
| id | question | why_it_matters | options | recommendation | affects |
|---|---|---|---|---|---|
OQ-CRM-DQ-001 | Should merge-plan edits be restricted to the creator or shared by qualified administrators? | Shared changes support handover but require a clear approval and attribution model. | A: creator edits and others read. B: all type-specific read-and-merge holders edit. C: creator and named delegates edit. | The product should adopt shared qualified editing and record that choice explicitly, using attributed decisions and existing plan ownership. | CAP-CRM-DQ-012, FND-CRM-DQ-005 |
OQ-CRM-DQ-002 | How should privacy requests remove individual original values from retained merge outcomes? | Absorbed originals can remain as the only personal-data copy, and the recorded retention decision promises individual removal. | A: audited removal of personal original and discarded values while retaining merge metadata. B: amend the retention commitment to preserve complete outcomes until workspace purge. | The product should supply audited individual removal to fulfill the existing commitment. | CAP-CRM-DQ-019, FND-CRM-DQ-010 |
OQ-CRM-DQ-003 | How should reports resolve records absorbed by a merge? | Historical accounting references retain absorbed identities and need a current destination for readable names. | A: publish an alias dataset. B: expose survivor fields on record datasets. C: resolve each alias through an API. | The product should publish a shared alias dataset with survivor-existence handling for reporting consumers. | CAP-CRM-DQ-018, FND-CRM-DQ-011 |
OQ-CRM-DQ-004 | Which missing duplicate-management console controls belong in the milestone? | Re-checks and manual confirmation need API use today, and unfinished plans lack a console list for resumption. | A: deliver all three. B: deliver re-checks and confirmation first, then unfinished-plan listing. C: defer the controls. | The product should prioritize re-check management and manual confirmation, then deliver unfinished-plan listing. | CAP-CRM-DQ-005, CAP-CRM-DQ-009, CAP-CRM-DQ-012, FND-CRM-DQ-012 |
OQ-CRM-DQ-005 | Should organization merges publish a committed outcome event? | Applications referencing organizations need the same opportunity to react that contact-event subscribers receive. | A: add a matching organization event. B: wait for a named subscriber request. | The product should add the organization event because current reporting requests already demonstrate downstream consequences. | CAP-CRM-DQ-016, FND-CRM-DQ-009 |
OQ-CRM-DQ-006 | Should a colleague's read of a merge plan count as the renewed review that re-arms approval? | Approval binds to the plan last shown; today any qualified reader re-arms it, so the person who confirms may not be the person who looked at the change. | A: any qualified read re-arms approval (current). B: only the confirming person's own read or validation re-arms it. C: approval re-arms only through an explicit validation. | The product should adopt B, keeping shared plans while binding approval to the confirming administrator's last view. | DOM-CRM-DQ-003, ADR-CRM-DQ-007, FND-CRM-DQ-038, CAP-CRM-DQ-016 |