Session Overview

Ran the approved live Dialpad migration sample in LITIFY_ORG, avoided the bad oldest-first test-call sample, applied five representative Matter-linked call summaries into Litify notes, then fixed two idempotency problems before declaring the sample stable.

What Was Accomplished

• Ran a fresh live dry-run and confirmed the original oldest-first sample was a bad pilot because it would have created obvious testing calls on a live Matter.
• Added a repeatable --source-id control to scripts/migrate-dialpad-call-summaries-to-litify-notes.mjs so sample and batch runs can target chosen Dialpad__Call_Log__c records instead of relying on chronological order.
• Selected five representative Matter-linked Dialpad records and ran a live apply that created five litify_pm__lit_Note__c records with topic Call and stable External_Id__c mappings.
• Found and fixed two rerun bugs: generatedAtUtc was causing every rerun to look like an update, and Salesforce rich-text normalization of <br> versus <br /> was causing a false update on one note.
• Normalized the five sample notes after the idempotency fix and proved the same targeted rerun now returns five noops.
• Updated docs/litify-environment-diary.md and OPS_LEDGER.md with the live sample, note IDs, rollback paths, and the targeting/idempotency hardening details.

What Was Tried and Did Not Work

• The initial approved idea of using the script with plain --limit 5 was not safe because the earliest candidate set contained obvious testing and library-call records.
• After the first live create run, a follow-up dry-run showed five updates instead of noops. Root cause was the dynamic migration timestamp embedded in the note body.
• After removing the timestamp, one note still showed as an update because Salesforce stored one rich-text break tag as <br> while the generator emitted <br />.

Decisions Made and Reasoning

• Controlled targeting was safer than trusting oldest-first order, so the script was hardened instead of pushing a questionable pilot into production data.
• The migration body now keeps a stable legacy-migration banner but no dynamic timestamp, because rerunnable historical preservation matters more than logging the exact execution minute inside each note.
• HTML equivalence is normalized at compare time so Salesforce storage quirks do not create fake diffs and unnecessary rewrites.
• The sample was kept in place after stabilization because these are the intended preservation records, not disposable test rows.

Files and Locations

• Script: /Users/samaguiar/Documents/Projects/Repos/sail-litify/Litify_AI_Integration_Project/scripts/migrate-dialpad-call-summaries-to-litify-notes.mjs