When two systems disagree about a stage

Two connected systems can describe the same record differently — your CRM has a deal still in negotiation while your billing system already carries a signed subscription against it. When Beacon sees that, it raises a conflict rather than choosing between them.

​

Why Beacon does not simply pick one

A stage belongs to the system that produced it. Beacon reads stages and puts them in order; it has no authority to overrule the system that set one. If it quietly took the more recent, or the more complete, or the one that made a number look better, you would have a figure whose origin you could no longer trace — and the disagreement would still be there, now invisible. So the conflict goes to the owners of both systems, with both positions stated, and stays open until someone resolves it at the source.

​

What happens while it is open

​

Clearing it

1. Read which two systems disagree, and about what. The conflict names both, and the record.
2. Decide which one owns that record’s stage. For a deal in flight, that is normally your CRM. Once the contract is signed, the customer rail takes over — see Where a deal becomes a customer.
3. Correct it in that system, not in Beacon.
4. Wait for the next read. The conflict clears when the systems agree again; there is nothing to dismiss.

​

What not to do

Do not try to resolve it in Beacon. There is no override, deliberately. Beacon holds no stage of its own to correct — it points at the one your system set, so the only place a fix can land is the source. Do not treat it as an error. A conflict is usually a real process gap — a contract signed before the CRM was updated, an onboarding started early. The flag is doing its job by making it visible.

​

Related