Carve territories without breaking the existing book

Write a ranked policy that a regional director can explain to a seller. A workable starting order is unresolved ownership conflict, protected customer or opportunity relationship, approved named-account exception, approved hierarchy rule, regional coverage rule, and ordinary distribution. This is an editorial policy template, not a vendor default. Require managers to choose the actual precedence. Any account that matches conflicting rules at the same rank goes to an exception queue rather than the first row in a spreadsheet.

Distinguish primary commercial owner, supporting regional seller, account team member, and temporary coverage owner. The primary owner remains singular in the assignment contract. A local support role does not silently acquire the account or its opportunity credit. Define which accounts the carve may change and which remain outside scope. Exclude records pending a merger decision, a disputed customer relationship, or an unresolved contracting entity until the accountable manager makes that decision visible.

Store account_id, crm_record_id, legal_entity_name, primary_domain, parent_account_id, ultimate_parent_account_id, hierarchy_state, buying_entity_region, current_owner_id, proposed_owner_id, support_owner_ids, protection_reason, matched_rule_id, exception_id, carve_version, source_snapshot_at, effective_at, and assignment_state. Keep assignment_state values proposed, approved, active, superseded, and blocked. A blocked row needs blocker_reason and decision_owner_id. Do not encode an unresolved owner as an empty string that downstream routing interprets as available inventory.

Add migration_id, expected_current_owner_id, expected_active_version, approved_by, approved_at, applied_at, crm_acknowledged_at, consumer_acknowledgments, and rollback_state to the change manifest. Use stable account IDs as keys. HubSpot's company API supports retrieval by record ID or a custom unique identifier property, selected property history, and updates by company ID. Its batch company read does not include associations. Retrieve the hierarchy relationships separately rather than assuming a batch property export contains the complete account graph.[1]

Build the account hierarchy from reviewed relationships, not a shared email suffix alone. Identify legal entities, branches, purchasing subsidiaries, and the ultimate parent. Check for cycles, missing parents, duplicate records, and subsidiaries that inherit a parent's region without evidence. Keep a hierarchy_state of verified, partial, or disputed. A hypothetical equipment group headquartered in Germany may buy through a US subsidiary. Record the subsidiary's buying entity and the global account relationship separately before deciding its territory.

Take a protection snapshot of customer accounts, active opportunities, committed named accounts, and explicit manager exceptions. Define the expiration or release condition for every protection rule. An active opportunity might protect its current commercial owner through a specified review event, while an expired named-account exception returns to policy evaluation. Acceptance means every protected row retains its current owner in the proposal or carries an explicitly approved transfer decision. A parent correction must not cascade into silent reassignment of protected children.

Keep hierarchy repair out of the migration write batch unless managers approved that repair separately. If two CRM records describe the same buying entity, pause both assignments and let the data steward resolve the canonical record. Preserving two conflicting owners is not a safe solution. Merging records during cutover also changes the evidence on which the carve was approved. Generate a new proposal after that repair so reviewers see the actual account set they are authorizing.

Define region using the approved buying-entity policy, not a guessed headquarters address. Record why the region applies and which evidence supports it. For each seller, collect manager-approved region eligibility, language coverage, availability dates, and any product specialization required by the account. A hypothetical Japanese subsidiary with a global US owner might need a Japan-based supporting seller. Preserve the primary owner and add the support responsibility only after both managers agree on the customer-facing division of work.

Do not invent capacity scores, equalize estimated revenue without evidence, or assume identical account counts imply equal workloads. If reliable activity, opportunity complexity, or service requirements exist, expose their provenance and limitations to managers. Otherwise, show raw eligible-account counts, protected counts, open opportunities, and known availability. Mark unknown workload as unknown. Acceptance means a manager can identify the real inputs behind an assignment and can distinguish a seller who lacks coverage eligibility from one whose availability has not been supplied.

Evaluate the policy against a fixed account snapshot and seller roster. Store policy_version, roster_version, and snapshot_id alongside carve_version. Use a stable tie-break rule approved by sales leadership for accounts that remain eligible for ordinary distribution. Keep the same inputs and rule ordering capable of producing the same proposal. Present an account-level diff with old owner, proposed owner, protection status, matching rule, supporting role changes, and every reason an account remains blocked.

Review newly assigned accounts separately from moved accounts. In a hypothetical regional launch, genuinely unowned eligible accounts can enter a new regional book while established strategic accounts retain their global owners. This prevents a favorable aggregate chart from hiding relationship transfers. Acceptance means the proposal includes every in-scope account exactly once, accounts outside scope stay untouched, and every proposed owner appears on the eligible roster for the effective date. Keep the previous active version available for comparison.

Use required assignment fields and a unique key on carve_version plus account_id in the proposal store. PostgreSQL documents unique constraints across groups of columns and NOT NULL constraints for mandatory fields. For a separate current-assignment table, key account_id so it cannot contain two primary current rows. Do not try to enforce cross-row ownership with a CHECK expression that looks up other rows. PostgreSQL explicitly warns that CHECK constraints cannot guarantee those cross-row restrictions.[2]

Create an exception record with account_id, requested_owner_id, competing_owner_id, reason, evidence, effective_from, expires_at, approver_id, and decision. A named-account list is a policy input, not a private seller veto. When two regional directors name the same account, block activation for that account and route the decision to the designated commercial authority. Record which seller leads the next customer interaction while the dispute remains open. Do not send duplicate outreach as a compromise.

Ask reviewers to approve the exact carve version and manifest, not a screenshot of totals. Reopen approval if protected accounts change, hierarchy evidence changes, or the roster loses an assigned seller. If an AI-assisted workflow invokes a migration tool, n8n can pause a specific tool and show its parameters for approval or denial. That review capability does not replace the business policy. The approval payload must identify the manifest and version that the operations service will actually apply.[4]

Name one activation authority and enumerate every process that can change ownership, including imports, routing jobs, manual admin edits, and integrations. Freeze those writers for the migration window or make them submit through the same version-aware service. Before each account update, compare the actual CRM owner with expected_current_owner_id. A mismatch becomes a conflict, not a forced overwrite. HubSpot company updates and PostgreSQL transactions do not share an atomic read-and-write boundary, so the controlled write window is part of this proposed design.[1][3]

Keep one pre-created activation-control row for the ownership scope. Lock that row in a short transaction, check expected_active_version, and reject another migration while one is applying, reconciling, or rolling back. Persist migration_id and its in-flight state before committing. PostgreSQL FOR UPDATE locks end with the transaction and protect only database rows, not the separate CRM worker. The worker must operate on the persistent reservation. Clear it only after completion or reconciled withdrawal. Acquire multiple locks in consistent order and never wait for manager approval inside a transaction. Acceptance requires M2 to remain queued after M1 reserves the scope and commits, until M1 finishes reconciliation.[3]

Key each account operation by migration_id and account_id. Persist its expected owner, desired owner, and attempt state before dispatch. After a timeout or restart, retain the writer freeze and read the CRM before retrying. If its owner still matches the expected owner, retry the approved update. If it matches the desired owner and reservation history proves no intervening decision, acknowledge the completed operation without rewriting. Every other result becomes a manual conflict. Keep partial batches reconciling and stop dependent routing until required acknowledgments arrive. Test a successful CRM write followed by a worker crash before acknowledgment. Recovery must recognize that write rather than overwrite it or report a false conflict.[1][3]

Give each seller a book-change view with retained accounts, incoming accounts, outgoing accounts, effective time, rule reason, and unresolved exceptions. For incoming accounts, attach the approved handoff package and the previous owner's relationship context through revenue-team-handoffs. Require acknowledgment from the receiving owner and show who owns the next meeting. An assignment row without a seller-visible CRM owner and a usable handoff is an incomplete transfer, even when the central manifest says approved.

Compare what sellers see with the version that routing and reporting use. Inspect an account record, its open opportunity ownership policy, the inbound assignment destination, and the regional reporting label. These may have different legitimate owners, but they must agree with the approved policy. Document those distinctions in the book-change view. Do not automatically change opportunity credit, customer success ownership, or compensation records as a side effect of an account-owner carve unless those changes are explicitly in the approved manifest.

Name the negative cases. Hierarchy dispute blocks policy evaluation. Protected-book violation blocks approval. Named-owner conflict blocks the affected assignment. Ineligible regional coverage blocks delivery to that seller. Concurrent owner change blocks the update. Missing consumer acknowledgment blocks migration completion. An expired exception requires reevaluation rather than indefinite carryover. Put each case in the manager queue with its account, responsible decision maker, and next review date. Do not hide blocked rows by filtering them out of the territory totals.

Handle seller departures and roster changes as new approved decisions, not edits to a historical carve. A departed owner may require temporary coverage before the next full version. Record the temporary owner's scope and expiration. If a regional boundary changes during approval, regenerate the candidate against the new policy. Preserve the rejected version so reviewers can explain why an account moved. Avoid a live spreadsheet that mutates after approval while keeping the same version label.

Report assignment completeness as eligible in-scope accounts with one approved primary owner divided by all eligible in-scope accounts in the fixed snapshot. Report protected-book violation rate as protected accounts moved without an approved transfer divided by all protected in-scope accounts. Report conflict rate as accounts blocked by competing primary-owner decisions divided by all in-scope accounts. Publish the raw counts, snapshot date, and exclusions beside each percentage. Show regional support coverage separately from primary ownership so support gaps do not look like unowned accounts.

Report migration reconciliation as changed accounts whose CRM owner and required consumers match the manifest divided by all accounts scheduled to change in that manifest. Measure handoff completion as incoming accounts acknowledged by the receiving seller with the required relationship package divided by all transferred accounts. Track elapsed reconciliation time in hours from the first applied write to the last required acknowledgment. Do not publish fabricated seller capacity or attribute later revenue changes to the carve without a separate measurement design.

The RevOps owner schedules the cutover, regional managers approve transfers, and the GTM engineer maintains the manifest and consumer acknowledgments. Start with a bounded regional cohort that includes protected accounts and exceptions, not only clean unowned records. Define which ownership writers stop, who restores them, and which conflict stops the batch. Keep the previous version and the old owner values. Announce the effective time internally before sellers act on the new book.

Acquire the same persistent activation reservation for rollback. Pause the forward worker and re-establish ownership-writer exclusion across imports, integrations, manual edits, and routing before checking restoration eligibility. Keep exclusion through restoration readback and consumer reconciliation. If a writer cannot be excluded, stop automatic restoration for its affected records and reconcile them manually. Restore only accounts that still match the migration's applied values and have no later approved ownership decision. Mark the failed version withdrawn and preserve its history. Resume the previous version and normal writers only after CRM ownership and required consumers agree and the reservation closes. Sellers see the withdrawal and the current owner of the next customer interaction.[1][3]