Sam asked whether Drew's team or Joe's follow-up email changed or conflicted with the Codex GCLID fix completed earlier on June 3, 2026.
62671, Attribution Capture - Google Ads GCLID and UTMs.wp-content/mu-plugins/sal-custom-contact-intake-v2.php on Cloudways.2026-06-03 11:11:04, revision 70833, author ID 8 (Craig Aguiar / display Sam Aguiar). No later revisions from Joe, Drew, claude-editor, or another WP user were present.if (!store[fieldName]) is absent, and the overwrite pattern store[fieldName] = value is present.2026-06-03 15:10:41 UTC, and the only GCLID Litify update key in the mapping section is GCLID_Custom__c.GCLID__c and GCLID_Custom__c exist on litify_pm__Intake__c, but Drew's email is correct that the intended current field is GCLID_Custom__c.104, the Codex VERIFY789 test, remains the proof row with gclid=VERIFY789 and Litify/email sent. Teams status remains failed because of the already-known suspended Power Automate workflow, not because of the GCLID fix.Drew's team's message does not conflict with what Codex did. Their Step 1 / Step 2 split is directionally right: the website needs to capture and send the raw GCLID into Litify, and the later offline conversion workflow should use Litify/Salesforce data to send conversion events back to Google Ads. Codex already implemented the exact server-side field they named, GCLID_Custom__c, and preserved the website payload field name gclid.
The main caution is wording: the website form payload does not need to rename its browser field to GCLID_Custom__c. The WordPress handler maps browser gclid into Salesforce GCLID_Custom__c. That separation is correct and should stay.
They did not mess with the live fix. Their email confirms the field name we already changed to. Nothing in their message requires undoing Codex's repair.
The Teams alert webhook remains unresolved from the earlier alert-webhook session. It should be handled separately by re-enabling the Power Automate flow or replacing the relay with a Teams-capable endpoint.