Most CRMs treat every quote the same way: a rep fills in line items and hits send. That works fine for small, routine deals. It breaks down once deal size varies — a $2,000 engagement and a $100,000 one shouldn't move through the same unchecked path to a signature.
Venntive doesn't ship a packaged CPQ (configure-price-quote) module. But it does have the parts to assemble one: a custom field on Opportunities, a workflow trigger system, and a Quotes object that pulls Opportunity data directly into the document a rep sends. Put together, they create an approval gate that activates only when a deal crosses a threshold you define — without adding a new tool or a manual review step for every deal.
Here's how to build it.
1. Define your deal-size tiers
Under Settings > Opportunities > Custom Fields, create (or use an existing) field — for example, "Deal Size" — with a fixed set of options representing your pricing tiers. Mark it Required and enable Show on Kanban so the tier is visible at a glance on every Opportunity card.
2. Build the approval workflow
In Automation, create a workflow that notifies your designated approver when a high-tier deal needs review. Pull in the Opportunity context the approver needs to make a call — value, products, notes — so they aren't chasing down details before they can respond.
3. Branch the workflow by tier
Inside that workflow, add conditional logic so only qualifying tiers route to a human approver. Lower tiers can auto-pass with a notification only, so the gate doesn't add friction to every deal — just the ones that warrant a second look.
For deals that need more than one approver — say, a manager and then finance — use the workflow's Trigger Actions tab to Start a Journey instead of stopping at a single notification. Inside the Journey, an Action step notifies the first approver, a Decision step checks whether a CRM field (e.g. "Manager Approved") has been updated, and if so, a second Action notifies the next approver, and so on. This gives you a real multi-step approval chain built entirely from native objects.
4. Attach the trigger to the custom field
Back in Settings > Opportunities > Custom Fields, open the Deal Size field and use Add Trigger. Point it at the workflow you just built. Now, whenever a rep selects a qualifying tier on an Opportunity, the approval workflow (and, if configured, its Journey) fires automatically.
5. Treat the final gate as a team rule, not a system lock
This is the one place worth being direct about a current limitation: the Journey tracks and records each approval step, but nothing in Venntive ties a Journey's current position to the Send button on a Quote or Invoice. A rep could technically send a quote before the Journey reaches its final approval step. The gate holds because the team agrees to wait for confirmation that the Journey has completed before building and sending the quote — not because the system prevents sending early. Teams that need a hard, unbypassable block should build that expectation into their sales process documentation rather than assume the software enforces it.
6. Build the quote from approved Opportunity data
Once approved, create the Quote at the Contact level and use Venntive's placeholder fields — OpportunityValue_Placeholder, OpportunityProducts_Placeholder, OpportunityProfit_Placeholder, and others — to pull the approved numbers directly into the document. This keeps the sent quote matched to what was actually reviewed, instead of retyped and open to drift.
7. Test it end to end
Run one Opportunity through a tier that should auto-pass and one that should route to approval. Confirm the notification fires, the approver has enough context to decide, and the resulting quote reflects the approved figures.
Who this is for: Teams with a handful of deal-size tiers who want a lightweight review step on larger deals without adding new software.
Who this isn't for: Teams that need a hard, system-enforced block on sending. Multi-step chains (manager, then finance, then legal) are achievable using Journey Decision branching, as described above — but stopping a rep from sending before that chain resolves still depends on the team following the process, not the software enforcing it.