# Workflow change list: <company> (<CRM>)

- Based on: <audit file and as-of time | design spec version>
- Prepared by: <agent run or person>. Applied by: <CRM admin>. Verified by: <role>.
- Status: draft, not applied. Nothing in this list has been changed in the CRM.

## Rules for the list

- One change request per hypothesis. A writer fix and the cohort repair it needs are one request; unrelated hygiene is a separate request.
- Order: wrong customer state or owner first, then lost or unmeasured requests, then reporting, then hygiene.
- Stop or narrow the writer before repairing records, or the repair is undone.
- Historical corrections change reports and can trigger automation. Name the cohort, take a before-export, and name an approver.
- Tell the reporting owner before release when a number will move (MQL counts fall when loops stop).

## CR-<n> <short title> (<rule IDs>)

- Entity: <system, object, field, workflow name or ID, rule ID, integration mapping>
- Current setting, as read on <date>: <quote the setting or mapping>
- Change: <exact edit, step by step>
- Findings it fixes: <rule, count, example IDs>
- Risk: <what else reads or writes this; what could break>
- Test (the rehearsal plan): <acceptance cases from acceptance-test-cases.csv, expected results, test recipients; run by the CRM admin after approval, in a sandbox or on flagged test records with explicit approval>
- Approvals: <roles>
- Rollback: <steps>
- Rollback does not undo: <notifications sent, tasks created, owner changes, reports restated>
- Cohort repair: <ID list source, before-export, method (correction workflow with reason | manual by revops_admin), expected count>

## Example: CR-01 Stop the billing integration writing lifecycle stage (T06 FAIL, M2)

- Entity: HubSpot, billing integration field mapping, subscription status to contact lifecyclestage.
- Current setting, as read on 2026-10-01: the mapping sends Stripe subscription status "active" as lifecyclestage customer on the contact.
- Change: remove the lifecyclestage mapping. Map subscription status to the contact property subscription_status (create it first: dropdown with trialing, active, incomplete, incomplete_expired, past_due, canceled, unpaid, paused). Map collection method and latest invoice status to their own properties.
- Findings it fixes: T06 FAIL INTEGRATION:billing-sync set customer (1 of 29 lifecycle changes, c-1004); M2 Customer set while a send_invoice subscription's first invoice was open.
- Risk: workflows or lists that use lifecyclestage = customer as a proxy for "paying" must move to latest_invoice_status = paid, because subscription_status active is not payment (send_invoice and ACH cases); check the workflow and list inventory first.
- Test: AT15 (send_invoice subscription with an open first invoice: subscription_status active, latest invoice open, lifecycle unchanged), AT16 (subscription canceled: subscription_status canceled, lifecycle stays customer, no win-back enrollment without the separate rule) and AT22 (ACH payment processing then fails: invoice void, subscription active, lifecycle unchanged). Run by revops_admin in billing test mode after approval.
- Approvals: finance (billing state), RevOps lead (lifecycle), revops_admin (applies).
- Rollback: re-add the mapping exactly as quoted under current setting.
- Rollback does not undo: lifecycle values already written, customer emails or tasks triggered by Customer.
- Cohort repair: contacts whose lifecyclestage history shows customer from INTEGRATION:billing-sync (T06 IDs: c-1004). Before-export of lifecyclestage history; correct through WORKFLOW:lifecycle-correction with correction_reason "billing sync set customer before payment"; expected 1 record.

## Example: CR-04 Move rotation to lead records, with a fallback (T05 FAIL, S05 WARN, S07 FAIL, M3, M8)

- Entity: HubSpot. Lead object setting "Sync lead owner with contact or company owner"; the lead pipeline's "Create a lead" automation; the contact-based workflow "Demo request rotation" (rotate action and enrollment triggers); a new lead-based workflow "Inbound lead rotation"; a saved lead view "Unowned inbound leads".
- Current setting, as read on 2026-10-01: "Demo request rotation" is contact-based, enrolls on demo form submission or when company size changes, re-enrollment on, Rotate record to owner writes the contact owner (hubspot_owner_id) with "Overwrite if contact has an existing owner" on and "Assign to available users only" on, and has no branch for a record left without an owner. "Sync lead owner with contact or company owner" is on.
- Change, in this order:
  1. Turn off "Sync lead owner with contact or company owner" (lead rotation needs it off, and the lead owner stops mirroring the contact owner).
  2. Confirm the lead pipeline's "Create a lead" automation is off (Automate tab of the lead pipeline). WORKFLOW:demo-intake and WORKFLOW:mql-scoring create every lead (spec section 2), so the automation would add a second lead for a demo request that also triggers the MQL.
  3. Create the lead-based workflow "Inbound lead rotation": enroll on lead creation, filtered to leads WORKFLOW:demo-intake or WORKFLOW:mql-scoring creates (request_class = hand_raise or mql); re-enrollment off. Action: Rotate record to owner for leads, Round Robin among the SDR team, "Assign to available users only" on, "Overwrite any existing lead owner" off, so a lead that intake already gave to the open-opportunity or account owner, or that scoring gave to the contact owner, keeps that owner.
  4. After the rotate action, add a branch: if the lead owner is unknown, set the lead owner to the SDR team lead (fallback) and send an internal notification to the SDR team lead.
  5. Create the saved lead view "Unowned inbound leads" (lead owner unknown, created in the last 7 days), checked hourly during coverage by the SDR team lead.
  6. Turn off the contact-based "Demo request rotation", so no rotation writes hubspot_owner_id; the relationship owner stays with the account owner rule and people.
- Findings it fixes: T05 FAIL hubspot_owner_id c-1009 (rotation and rep fighting over an accepted request, 1 of 2 records); S05 WARN r-04 (2 owner changes); S07 FAIL r-06 (no owner for 14,520 business minutes while every SDR was Away).
- Risk: reports, views and workflows that read the contact owner as "who works this request" must move to the lead owner; with the sync off, contact owner and lead owner can differ by design. Company size changes no longer reassign anything. The fallback owner gets every all-Away request and needs a backup during leave. Score-path mql leads now enter the same rotation, so SDR volume rises by that count. Lead rotation is in beta: re-read the rotate action options before building.
- Test: AT01 (new hand-raise in hours gets exactly one lead and a lead owner by rotation), AT03 (open-opportunity owner kept, overwrite off), AT04 (all reps Away goes to the fallback), AT08 (a second request gets its own lead and rotation), AT18 (an integration update must not reassign), AT20 (reassignment before first response keeps received_at), AT23 (a score-path MQL lead gets an owner within 60 business minutes). Expected values as in the cases; run by revops_admin after approval.
- Approvals: sales lead (fallback role), RevOps lead, revops_admin (applies).
- Rollback: turn the contact-based "Demo request rotation" back on with the triggers and settings quoted under current setting (screenshot them before the change; check in the live docs whether the account can restore an earlier workflow revision), turn off "Inbound lead rotation", and turn "Sync lead owner with contact or company owner" back on.
- Rollback does not undo: lead owners already set, contact owners the old workflow already changed, leads already created, and notifications already sent.
- Cohort repair: none for owners; r-06 and r-09 go to the fallback owner today through the normal UI.
