GTM Engineer.

GTM Control Tower: which leads can safely enter the CRM?

Messy exports can contain duplicate people, invalid emails, missing owners, and conflicting lifecycle stages. Control Tower applies explicit rules and keeps unresolved records out of the destination-ready set.

Try it: run the 64-row cleanup and inspect its decisions. The batch becomes 57 contacts after seven duplicate rows merge: 46 are ready and 11 remain held. Compare original values, changes, and remaining hold reasons, then download the same results.

Resolve a hold: the self-hosted correction walkthrough shows three fictional records, a recorded correction reason, and before/after history. Changing an email rechecks duplicates across the batch; a partial correction leaves unresolved problems held.

Compare with CRM: the self-hosted comparison uses exact email matches and CRM IDs for updates. Before creating a record, it also checks name, email, phone, state, and company against a recent complete CRM snapshot. Possible matches stay held for review, even when Salesforce would accept them. The match review shows supporting evidence and scores from 0–100, not probabilities; it never merges or links people automatically. Follow a real development-CRM import: fictional attendees, verified duplicate holds, creates and updates, a repeat without new writes, and update rollback in HubSpot and Salesforce. Actual screenshots and dated results distinguish the original run from the later hold check.

Design decision: an unresolved record stays visible for review. The browser example uses a fixed routing rule and a supplied expected stage; it does not infer historical truth or write to a CRM.

Separate Salesforce development-org evidence · Source and setup

Pomade: turn account data into inspectable research

Research results need context before they become sales inputs. Pomade combines a data grid, reusable recipes, source-linked answers, and deliberate export or CRM actions.

Try it locally: follow the credential-free, three-row workflow. Nine formula actions produce two passing rows and one that needs review. Clear a person's name and rerun: the failed formulas keep that row in Review. Edit a checked input and export before rerunning: its status is Draft, even while earlier outputs remain visible.

Design decision: an old result must not look freshly checked after its input changes. Keep raw responses, sources, and uncertainty available for review; successful execution and a citation do not establish factual accuracy. This local example uses synthetic records and no external writes. Hosted access remains private.

Separate September 7 provider benchmark and its limits · Source and current limits

Hot Potato: explain who receives an inbound lead

Routing should account for an eligible existing owner, rep availability, and assignment weights. The engine makes those rules inspectable and reuses the decision for a repeated request ID.

Inspect it: the routing and retry walkthrough links to source and passing checks. Follow the failure case: an older owner update fails, a newer assignment succeeds, and the old retry is skipped. PostgreSQL checks also verify that concurrent owner writes finish in order, using synthetic provider callbacks.

Design decision: a delayed retry must not undo a newer queued assignment. The guard orders this application's writes; it does not detect independent edits inside the CRM. The website animation plays preset fictional results without calendar checks or bookings. Historical rule snapshots are not implemented.

Public application and setup