ProductCRM & Pipeline
CRM and Pipeline
The CRM holds contacts, leads, accounts, customers and deals; the pipeline is the deal board over them. What makes it different from a CRM you have used before is that a record cannot be dragged forward on optimism: each forward move has a gate, and the gate is enforced on every path that can write the column, including the API and an agent.
Four sections, folded from three state machines
A record's position is reported as one of four canonical sections: Contact, Lead, Opportunity, Customer. Underneath, three separate state machines are running: the contact's own lifecycle column, the status of any lead row, and the stage of any deal. The canonical section is the furthest-forward signal across all three.
That fold exists because the same record used to read as two different stages on two different screens. One projection now decides, so the pipeline board, the contact record and the analytics all answer the same question the same way.
A record can be out of the active funnel while still belonging to a section. Three terminal reasons are reported explicitly rather than by disappearance: a churned customer, a lost deal, and a disqualified lead.
Deal stages
The pipeline board runs Prospecting, Qualification, Proposal, Negotiation, and then one of two closed stages: Closed won or Closed lost.
Contacts carry a longer lifecycle of their own, from subscriber through lead, MQL, SQL, opportunity, customer, evangelist and churned, with the legal next stages defined per stage. A move that is not one of them is refused with the list of what is allowed from where the record actually is.
What a forward move requires
Two gates guard the forward path, and they are the part of this product most worth understanding before you configure anything else.
- Contact to Lead
- A confirmed calendar event on the contact. Schedule a meeting to advance the contact. A manager can force past it explicitly.
- Lead to Opportunity
- A documented, rep-confirmed BANT assessment, AND an open opportunity row already on the contact. The lifecycle stage follows the deal and can never precede it: the direct lifecycle path can re-align a stage that has drifted from an existing deal, but minting the stage is the convert route's job.
One hold is not overridable by anyone: a suppressed contact can never be advanced. A manager force does not lift it, because it is a consent decision rather than a pipeline-hygiene one.
There is a fuller qualification matrix behind the same idea, keyed on the stage being entered: engagement to enter Lead, budget and authority and need and timeline to enter Opportunity, need and timeline to close. A signal that is missing, or that arrives as anything other than a confirmed boolean, counts as not confirmed, so the gate fails shut rather than open, and the refusal names exactly which signals are missing.
The gate is not a screen. It is composed into the single decision every writer of the lifecycle column consults, so the same rule applies to the CRM UI, a bulk action, the public API and an agent tool alike. An API key holds no workspace role, so it can never force past an overridable gate: asking for the override is a 403 rather than a silent refusal.
Imported records get no exemption
An importer may place a record at the stage your source system asserts, at the moment the row is created. That is the only exemption. Every move after the import follows the same Contact to Lead to Opportunity to Customer rules a natively created record follows: if a rep tries to move an imported lead to Opportunity without the BANT criteria met, it is blocked and the checklist is surfaced.
Syncing Salesforce or HubSpot
Two CRMs connect: Salesforce and HubSpot. The two directions are not in the same state, so it is worth being exact about which you are relying on.
- Reading
- Live for both. Records, activity and attachments are extracted from the connected system into SAGARIS.
- Writing back
- Live for Salesforce, gated by a deployed environment switch. For HubSpot the write-back path runs as a dry run: it computes what it would write and does not write it. There is no HubSpot go-live switch to ask for; that code is unreleased.
What SAGARIS can do inside HubSpot also depends on your own HubSpot subscription rather than on us. Custom objects are an Enterprise capability, workflow automation is Professional and above, and field write-back needs Starter and above. A portal can be Enterprise and still not have granted the custom-object scope, so the connection confirms the scope at runtime instead of inferring it from the tier.
When both systems have changed the same field, the conflict is recorded rather than silently resolved, and the decision is reviewable.
Behaviour on this page is read from
- src/lib/crm-stage.ts
- src/lib/lifecycle-stages.ts
- src/lib/opportunities.ts
- src/lib/lifecycle-gates.ts
- src/lib/bant-stage-advancement-gate.ts
- src/app/api/v1/contacts/[id]/route.ts
- src/lib/crm-ingestion-policy.ts
- src/lib/hubspot-tier-gate.ts
- src/lib/marketing/crm-sync-claims.ts
Was this page helpful?