Thanks mate! Really appreciate that.
On the state sync + guardrails side, we’ve tried to be pretty deliberate:
Condition-based triggers only – stage changes only fire when a deal enters specific Won or Terminated stages, and everything is pipeline-aware. Nothing runs off generic property updates.
Contract grouping logic – all expansions and upsells are tied back to a contract_group_id, so renewal and termination cascades are scoped strictly to that contract family.
Active-only updates – we only move child deals where active_deal_ = true, so historical or already-closed records don’t get touched.
Dealtype guardrails – renewal/termination logic explicitly excludes child deals and only runs for main deal types (New, Atlas, Renewal). The card also blocks expansion creation unless you’re on an active main deal.
Termination override logic – if a main deal is terminated, active expansions/upsells are automatically terminated too, pipeline-aware.
Renewal cascade logic – when a renewal closes, the previous main deal is moved to Renewed and all active child deals in that contract group follow.
We’re also returning structured output fields in the custom code (counts of deals found, updated, skipped, errored), so we’ve effectively got lightweight audit logging at the workflow level.
Edge-case-wise, the biggest protections are:
It won’t run on the wrong dealtype.
It won’t run outside the correct pipeline stage.
It won’t touch inactive child deals.
It won’t create expansions from renewed/terminated deals.
So we’ve tried to balance automation with very tight scoping.
If you’ve seen any specific failure modes in other orgs around any other edge cases, I’d love to compare notes, always keen to harden this further!
