# Approvals
Source: https://docs.getveles.com/get-started/calculator/approvals
Configure multi-tiered approval workflows that route deals to the right stakeholders based on the rules triggered during quoting.
Approval workflows in Veles ensure that deals are reviewed by the right people before they reach the buyer. Instead of a static, one-size-fits-all approval chain, Veles uses a tier-based system that routes deals to the appropriate leadership level based on which specific rules are triggered during quoting.
A rep building a quote that stays within all pricing guardrails can publish immediately. A quote with a 15% discount might need a sales manager's sign-off. A quote with a 30% discount and non-standard payment terms might need the VP of Sales and Finance. The approval system makes this routing automatic.
***
## How tiers work
Approval tiers are groups of authorized approvers organized by escalation level. You can create as many tiers as your organization requires.
**Example structure:**
| Tier | Label | Typical members |
| - | - | - |
| 1 | Sales Manager | First-line managers, team leads |
| 2 | Deal Desk | Deal desk analysts, pricing specialists |
| 3 | VP of Sales | VP-level leadership |
| 4 | Finance | CFO, finance approvers |
When a rule is triggered on a quote, it specifies which tier is required to approve. Multiple rules can trigger on the same quote, potentially requiring sign-off from multiple tiers.
***
## Routing: the "Ball in Court"
Veles uses your [org hierarchy](/get-started/quickstart/adding-users#manager) to determine who specifically within a tier should review the deal.
**Responsible party.** When a rep requests approval, Veles identifies the **closest manager** to that rep within the required tier. That manager becomes the primary approver -- the person with the "ball in court."
**Fallback approvers.** Other users assigned to the same tier also have authority to approve the deal. This prevents bottlenecks when the primary approver is unavailable (on PTO, in back-to-back meetings, etc.).
**Notification settings.** For each tier, you can choose to notify all members when an approval is requested, or only the responsible manager. Notifying the full group is useful for high-urgency deals; notifying only the manager keeps noise low for routine approvals.
Keep your [user hierarchy](/get-started/quickstart/adding-users#manager) up to date. Approval routing depends on the manager relationships you've defined. If a rep's manager changes and the hierarchy isn't updated, approvals will route to the wrong person.
***
## Configuring approval tiers
Navigate to **Admin Console > Calculator > Approvals**.
1. Click **Add Level** to create a new approval tier.
2. **Name the tier** with a clear label (e.g., "Sales Manager", "Deal Desk", "VP of Sales", "Finance").
3. **Assign users** to the tier. These are the people authorized to approve deals that reach this level.
4. **Set notification preferences** -- notify the full group or just the responsible manager.
5. Click **Save**.
Repeat for each escalation level your organization needs.
***
## Linking tiers to rules
Approval tiers become useful when they're connected to [Rules](/get-started/rules-and-approval/learn-the-basics). When configuring a rule, you specify which approval tier is required to clear a violation.
This creates a direct link between the condition (what went wrong) and the escalation path (who needs to sign off).
**Example workflow:**
| Rule condition | Required tier |
| - | - |
| Discount between 10% and 20% | Tier 1: Sales Manager |
| Discount over 20% | Tier 2: VP of Sales |
| Non-standard payment terms (Net-60+) | Tier 3: Finance |
| Deal includes unapproved product bundle | Tier 2: Deal Desk |
| TCV exceeds \$500k | Tier 3: VP of Sales |
A single quote can trigger multiple rules, requiring sign-off from multiple tiers. All required approvals must be met before the quote can be published.
***
## The rep experience
When a rep is building a [Pricing Option](/get-started/calculator/quote-options) and triggers a rule that requires approval:
1. **Rule alerts appear** on the line item or at the option level, explaining what was triggered and which tier needs to approve.
2. The **Publish** button dynamically changes to **Request Approval**.
3. The rep clicks Request Approval. The request is routed to the appropriate tier(s) based on the rules triggered.
4. The rep can see which tiers are required and where the approval currently sits (the "ball in court").
5. Once all required tiers approve, the Publish button becomes available and the quote can be sent to the buyer.
Reps can continue editing the quote while waiting for approval. However, if edits change the deal structure (new discounts, different products), the approval status may reset and require re-approval.
***
## Approval statuses
| Status | Meaning |
| - | - |
| **Draft** | The quote is being edited. No approval has been requested. |
| **Pending** | An approval request has been sent. Waiting for the required tier(s) to respond. |
| **Approved** | All required tiers have signed off. The quote can now be published. |
| **Rejected** | An approver has sent the deal back with comments. The rep needs to revise and re-request. |
### Rejection workflow
When an approver rejects a deal, they include comments explaining what needs to change. The quote returns to the rep in Draft status. The rep makes the requested changes and re-submits for approval. The full approval history (requests, rejections, comments, re-submissions) is preserved for audit purposes.
***
## Approvals and the publishing workflow
Approvals sit between the Build and Publish steps in the [quote lifecycle](/get-started/calculator/quote-options#publishing-and-versioning):
```text theme={null}
Build quote → Rules triggered → Request Approval → Approved → Publish → Share
```
If no rules are triggered (the deal is fully within guardrails), the approval step is skipped entirely and the rep can publish immediately. Approvals only gate publishing when the deal exceeds defined thresholds.
Once published, the quote version is locked. If the rep later edits the quote and introduces changes that trigger new rules, the approval cycle starts again for the new version.
***
## Best practices
**Start simple.** Two or three tiers cover most organizations. You can always add more as your approval needs become more nuanced.
**Align tiers to decision authority, not job titles.** Name tiers by the decision they represent ("Discount > 20%", "Non-standard terms") rather than organizational hierarchy. This makes it easier to reassign people when roles change.
**Use Deal Desk as a tier.** If you have a deal desk function, make them a tier. They can serve as the first line of review for complex deal structures before escalating to executive approvers.
**Audit quarterly.** Review who's in each tier, whether the rules linking to each tier are still appropriate, and whether approvals are causing unnecessary bottlenecks. If a tier is approving 100% of requests, the threshold may be too low.
***
## What's next
Configure the rules that trigger approval requirements.
See how approvals fit into the full quote lifecycle.
Set up the org hierarchy that drives approval routing.
Share approved quotes with buyers via the branded portal.
# Display Options
Source: https://docs.getveles.com/get-started/calculator/quote-display-options
Control what pricing detail buyers see on proposals: line items, totals, grouping, PDF layout, and portal customization.
# Display Options
Display Options give reps granular control over how much pricing detail the buyer sees on a proposal. You access them from the **Display Options** button at the top of any quote, next to the Request Approval button.
Every toggle affects both the [Web Portal](/get-started/calculator/web-portal) view and generated PDF documents unless noted otherwise. This lets you tailor the level of transparency to the audience -- full detail for procurement, totals-only for executive sponsors.
***
## Quote Lines
These toggles control what's visible on individual line items in the pricing table.
| Toggle | Default | What it controls |
| - | - | - |
| **Show Quantity** | On | Display the quantity for each line item (e.g., "50"). When off, the buyer sees the price but not the unit count. |
| **Show Quantity Labels** | On | Display the unit of measure label alongside the quantity (e.g., "50 Users" vs. just "50"). Requires Show Quantity to be on. |
| **Show List Prices** | Off | Display the pre-discount list price for each line. When off, the buyer only sees the final price. Useful for hiding the "anchor" price when you don't want to reveal the discount spread. |
| **Show Discount Percentages** | Off | Display the discount percentage applied to each line. When off, the buyer sees the net price without knowing the explicit discount. |
| **Group Sublines Together** | Off | When a product has multiple pricing components (e.g., a base fee plus a per-seat charge), this groups them into a single visual line. When off, each component is displayed separately. |
For most deals, leaving **Show List Prices** and **Show Discount Percentages** off gives you a cleaner proposal. The buyer sees the final price without the negotiation mechanics. Turn them on when the buyer's procurement team specifically requires full pricing transparency.
***
## Grouping
| Toggle | Default | What it controls |
| - | - | - |
| **Split out Recurring and One-Time Fees** | Off | When on, recurring products (licenses, subscriptions) and one-time products (implementation, setup) are displayed in separate tables. When off, all line items appear in a single table. |
Splitting fees is useful for deals with significant one-time components. It makes the recurring commitment (the ARR) visually distinct from the upfront costs, which helps buyers and their finance teams evaluate the deal structure.
***
## Total Formatting
These toggles control what summary information appears below the pricing table.
| Toggle | Default | What it controls |
| - | - | - |
| **Show Shared Inputs** | On | Display the shared inputs used in pricing calculations (e.g., the quantity value that drives multiple line items). When off, only the output prices are shown. |
| **Show Total Contract Value** | On | Display the TCV as a summary line. When off, TCV is hidden from the buyer. |
| **Only show final total** | Off | Hide all line-item pricing and display only the bottom-line total for the deal. No individual product prices, quantities, or discounts are visible. |
**Only show final total** is the most aggressive display option. It hides all line-item detail and shows a single number. Use this only for executive-level proposals where per-line detail would be noise, or for deals where you explicitly don't want the buyer breaking down the pricing by product.
***
## PDF Options
These settings apply only to generated PDF documents, not the Web Portal.
| Toggle | Default | What it controls |
| - | - | - |
| **Page Break Each Option** | Off | When on, each [Pricing Option](/get-started/calculator/quote-options) starts on a new page in the PDF. When off, options flow continuously. |
Enable this for proposals with multiple options that are each substantial enough to warrant their own page. For simpler multi-option proposals, keeping options on a continuous flow is usually cleaner.
***
## Portal Options
These settings apply only to the [Web Portal](/get-started/calculator/web-portal), not generated PDFs.
| Setting | What it controls |
| - | - |
| **Disable Background Image** | Turns off the default background image set by your admin. The portal renders with a clean, unadorned header. |
| **Custom Background Image** | Upload a background image specific to this proposal (overrides the admin default). Use this to personalize the portal for a specific buyer -- for example, uploading an image related to the customer's industry or brand. |
Custom backgrounds are a small touch that can make a big impression. For strategic deals, uploading a customer-relevant image signals that the proposal was built specifically for them, not generated from a template.
***
## Custom Columns
Custom Columns let you surface additional pricing data points on the line item table that aren't shown by default.
| Toggle | Default | What it controls |
| - | - | - |
| **List Rate** | Off | Display the per-unit list rate for each line item (before discounts). Distinct from Show List Prices, which shows the total list price. |
| **Offered Rate** | Off | Display the per-unit offered rate (after discounts). Shows the buyer exactly what they're paying per unit. |
These columns are especially useful for per-seat or per-unit products where the buyer cares about the unit economics, not just the total. Turning on **Offered Rate** while leaving **Show Discount Percentages** off lets you communicate the per-unit price without revealing the discount mechanics.
Additional custom columns beyond List Rate and Offered Rate can be configured by admins. If you've added custom fields to the Quote Line through the [Object Explorer](/get-started/pricing-and-packaging/product), they may be available as toggleable columns here.
***
## Common configurations
### Executive proposal (minimal detail)
* Show Quantity: **Off**
* Show List Prices: **Off**
* Show Discount Percentages: **Off**
* Only show final total: **On**
The buyer sees a single total. Clean, high-level, no line-item noise.
### Standard sales proposal
* Show Quantity: **On**
* Show Quantity Labels: **On**
* Show List Prices: **Off**
* Show Discount Percentages: **Off**
* Show Total Contract Value: **On**
The buyer sees products, quantities, and net prices. No discount mechanics visible. This is the default for most deals.
### Procurement-ready proposal (full transparency)
* Show Quantity: **On**
* Show Quantity Labels: **On**
* Show List Prices: **On**
* Show Discount Percentages: **On**
* List Rate: **On**
* Offered Rate: **On**
* Split out Recurring and One-Time Fees: **On**
Full pricing breakdown. Every line shows list price, discount, net price, and per-unit rates. Recurring and one-time fees are separated. This is what procurement teams typically request during formal vendor evaluation.
***
## What's next
Share proposals with buyers using the branded portal.
Configure PDF templates alongside display options.
Understand the full quote structure and publishing workflow.
Build the pricing configurations that display options apply to.
# Quote Lines
Source: https://docs.getveles.com/get-started/calculator/quote-line
Understand the line item on a quote: what data it contains, how pricing is calculated, and how lines carry through to Orders and Contracts.
A Quote Line is a single line item on a Pricing Option. It represents one product at a specific quantity and price within a specific [Phase](/get-started/calculator/quote-phase) of the deal. When you add a product from the catalog to a Pricing Option, you create a Quote Line.
Quote Lines are where the pricing engine does its work. Each line pulls its pricing logic from the product's [pricing plan](/get-started/pricing-and-packaging/creating-a-product#pricing-plans), applies any automated adjustments from [rules](/get-started/rules-and-approval/pricing-rules) and [data sheets](/get-started/pricing-and-packaging/data-sheets), and then exposes the result for the rep to review and optionally discount.
Critically, Quote Lines are simulation objects. They may reflect sophisticated pricing logic, but they do not trigger billing, provisioning, revenue recognition, or contract mutation. That only happens after the quote is [promoted](/get-started/calculator/quote-options#from-quote-to-order-promotion) to an Order.
***
## What a Quote Line contains
Each Quote Line stores the full commercial detail for a single product within a Phase:
| Field | Description |
| - | - |
| **Product** | The SKU from your [price book](/get-started/pricing-and-packaging/overview). Determines which pricing plan and method are used. |
| **Quantity** | The number of units (or the driver value for [driver-based products](/get-started/pricing-and-packaging/units-of-measure#input-kind-quantity-vs-driver)). |
| **List Price** | The starting price calculated from the product's pricing plan and tier structure. |
| **System Adjustment** | Any automated price changes applied by [Pricing Rules](/get-started/rules-and-approval/pricing-rules) or [Data Sheet](/get-started/pricing-and-packaging/data-sheets) lookups. |
| **System Price** | The price after automated adjustments, before any rep discount. |
| **Discount** | The rep's discretionary discount (percentage or back-calculated from a target price). |
| **Net Price** | The final price after all adjustments and discounts. This is what the buyer sees. |
| **Billing Frequency** | How the line item is billed: monthly, quarterly, annual, or one-time. Constrained by the product's [Deal Component](/get-started/pricing-and-packaging/deal-components) settings. |
| **Phase association** | The [Phase](/get-started/calculator/quote-phase) this line belongs to. The line inherits its service start and end dates from the Phase. |
***
## The pricing waterfall
Every Quote Line displays a transparent pricing waterfall that shows how the final price was reached. This is visible in the Calculator as columns on the line item table.
```text theme={null}
List Price (from price book)
↓
System Adjustment (rules, data sheets)
↓
System Price (post-automation, pre-rep)
↓
Rep Discount (manual or target-based)
↓
Net Price (what the buyer pays)
```
The waterfall gives reps and deal desk full visibility into how a price was derived. No black-box calculations -- every step is visible and traceable.
### Where each value comes from
**List Price** is calculated by the pricing engine based on the product's pricing method (flat fee, volume, graduated, stair-step, or percentage of) and the quantity or driver value the rep entered. This calculation uses the tier structure defined on the product's pricing plan.
**System Adjustment** is the sum of all automated changes applied by the rules engine. Pricing Rules can increase or decrease the price based on deal conditions (customer segment, product combination, deal size). Data Sheet lookups can inject values like regional multipliers or ERP-specific uplifts.
**System Price** is simply List Price adjusted by System Adjustment. This is the "machine-recommended" price before the rep makes any manual changes.
**Rep Discount** is the discretionary discount the rep applies. This can be entered two ways: type a discount percentage directly into the field, or double-click the Net Price cell and enter a **target price** -- Veles back-calculates the required discount percentage automatically. Rep discounting is subject to [rep permissions](/get-started/pricing-and-packaging/creating-a-product#rep-permissions) on the product (discounting can be disabled) and [Validation Rules](/get-started/rules-and-approval/quote-validation) that enforce discount thresholds.
**Net Price** is the final output: System Price minus the discount. This is what appears on the proposal and what carries through to the Order at promotion.
***
## How lines relate to Phases
Quote Lines do not independently define their own service dates. They belong to a [Phase](/get-started/calculator/quote-phase) and inherit its start and end dates. This ensures that every line item is explicitly bounded within a commitment interval before the quote is promoted.
In a single-Phase deal, all lines belong to the one Phase and share the same service period. In a multi-Phase deal, the same product can appear in multiple Phases with different pricing or quantities in each.
**Example:** A 2-year ramp deal might have the same Platform License product as a Quote Line in both Phase 1 (Year 1: 50 seats at $40) and Phase 2 (Year 2: 100 seats at $45). These are two separate Quote Lines, each inheriting the dates from their respective Phase.
***
## How lines relate to Products
When you add a product to a Pricing Option, the Quote Line pulls its configuration from the product's pricing plan:
* The **pricing method** (flat, volume, graduated, stair-step, percentage of) determines how the List Price is calculated.
* The **tier structure** determines the rate for the quantity entered.
* The **unit of measure** determines what the rep is entering (seats, API calls, GB) and how it's labeled.
* **Rep permissions** determine what the rep can modify on this line: whether list price is editable, whether discounting is allowed, whether quantity can be changed, and whether the product name can be customized.
The product configuration sets the defaults and constraints. The Quote Line is where those constraints are applied to a specific deal context.
***
## Discounting on a line
Reps have two methods for applying discounts to a Quote Line:
### Direct discount entry
Type a discount percentage into the discount field. Veles calculates the Net Price from the System Price and the percentage entered.
### Target pricing
Double-click the Net Price field and enter the final price you want to charge. Veles back-calculates the required discount percentage to reach that target. This is useful when a rep knows the price they need to hit but doesn't want to work out the math manually.
### Discount constraints
Discounting is governed by multiple layers:
1. **Product-level:** If [Disable Discounting](/get-started/pricing-and-packaging/creating-a-product#rep-permissions) is toggled on for the product, reps cannot apply any manual discounts. Only automated pricing rules apply.
2. **Rule-level:** [Validation Rules](/get-started/rules-and-approval/quote-validation) can enforce maximum discount thresholds (e.g., "no more than 20% on any line"). [Data Sheet](/get-started/pricing-and-packaging/data-sheets)-driven thresholds can vary by customer segment or product category.
3. **Approval-level:** Discounts that exceed defined thresholds trigger [approval workflows](/get-started/calculator/approvals). The quote cannot be published until the approver signs off.
***
## Rule alerts on lines
The rules engine monitors every Quote Line in real time. When a line item violates a company policy, a **rule alert** appears directly on the line. Alerts can also appear at the Pricing Option level for deal-wide violations.
Each alert includes:
* **What was triggered** -- the specific rule that was breached.
* **Why** -- an explanation of the condition that caused the alert (e.g., "discount exceeds 20% threshold for Enterprise segment").
* **Who needs to approve** -- the user or role required to resolve the alert.
If you're an Admin, alerts include a direct link to the rule configuration in the Admin Console for quick adjustment.
Alerts are informational during deal building -- they don't block the rep from continuing to configure the quote. But they must be resolved (typically through approval) before the quote can be published.
***
## Quote Lines at promotion
When a quote is [promoted](/get-started/calculator/quote-options#from-quote-to-order-promotion) to an Order, each Quote Line is transformed into an **Order Line**. This is not a simple copy. The system materializes the final commercial values into immutable execution fields:
| Quote Line field | Becomes on Order Line |
| - | - |
| Net Price | Final net price (no longer recalculable) |
| Quantity | Final quantity |
| Discount | Final discount amount |
| Billing Frequency | Billing frequency |
| Phase association | Order Phase association |
At the moment of promotion, pricing ceases to be dynamic. The Order Line contains fully resolved values that are independent of the pricing engine, pricing rules, or any future changes to the price book. If the product's list price changes tomorrow, existing Order Lines are unaffected.
Order Lines subsequently produce **Contract Lines** when the Order is activated, carrying the same values into the durable commercial state of the [Contract](/get-started/contract-management/overview).
```text theme={null}
QuoteLine → OrderLine → ContractLine
```
***
## Custom fields on Quote Lines
Like other Veles objects, the Quote Line can be extended with custom fields through the [Object Explorer](/get-started/pricing-and-packaging/product). Navigate to **Pricebook > Object Explorer > Quote Line** to view the built-in fields and add custom ones.
Custom fields on Quote Lines are useful for carrying deal-specific metadata that doesn't belong on the product itself -- things like implementation priority, customer-specific configuration notes, or deal-specific cost basis overrides. Custom field values on Quote Lines propagate through to Order Lines and Contract Lines at promotion and activation.
***
## What's next
Understand how Phases structure the commitment schedule that lines belong to.
Build options with products, terms, and multiple line configurations.
How the pricing engine calculates the List Price on each line.
Configure the guardrails that validate and constrain Quote Lines.
# Quote
Source: https://docs.getveles.com/get-started/calculator/quote-options
Understand how quotes work in Veles: the block-based structure, pricing options, CRM sync, versioning, and the path from draft to buyer.
A Quote in Veles is a pricing construct used to model a potential commercial agreement. It exists to simulate, optimize, and negotiate pricing structures without affecting operational or financial systems. Quotes combine pricing options, legal terms, and narrative content into a single proposal that can be shared with buyers.
Every quote is tied to a **Customer** (company) in Veles and can be linked to a CRM opportunity or deal for bi-directional sync. Quotes are mutable by design -- they can undergo multiple revisions because no billing, provisioning, or revenue systems depend on them. When the buyer accepts, the quote is **promoted** to an Order, which is the boundary between modeling and execution.
Quotes are simulation objects. They may reflect highly sophisticated pricing logic (tiered discounts, ramps, floors, bundled pricing), but they do not trigger billing, revenue recognition, provisioning, or contract mutation until promoted to an Order.
***
## Anatomy of a quote
A quote is composed of two parts: the **Context Block** (fixed header) and one or more **content blocks** (the body).
### Context Block
The Context Block sits at the top of every quote and provides the deal metadata. It ensures brand consistency and gives both the rep and buyer the essential context for the proposal.
| Field | Description |
| - | - |
| **Company logo** | Your branding, pulled from [Account Setup](/get-started/quickstart/account-setup#brand-identity). |
| **Proposal name** | A descriptive title for the deal (e.g., "Acme Corp -- Enterprise Expansion Q3"). |
| **Prepared By** | The sales rep or deal owner. |
| **Prepared For** | The customer contact receiving the proposal. |
| **Issued On** | The date the quote is sent. |
| **Valid Through** | The expiration date, used to create urgency and track validity. |
These fields can be populated manually or auto-filled from your CRM when the quote is linked to an opportunity.
### Content blocks
Below the Context Block, quotes are built using a modular **block** system. You stack different block types to create a complete proposal. Blocks can be reordered, added, or removed at any time before publishing.
Veles supports four block types:
The core of every quote. A Pricing Option block opens the **Veles Calculator**, where you select products from your catalog, set quantities, configure deal terms (contract length, billing frequency, ramp schedules), and apply discounts.
Every quote needs at least one Pricing Option. You can add multiple options to give the buyer choices on a single proposal (e.g., Option A: 1-year term, Option B: 3-year term, Option C: 3-year with premium support).
[Full details →](/get-started/calculator/quote-options)
Insert predefined legal language directly into the proposal. Terms blocks bridge the gap between sales and legal during negotiations.
**Example:** If a rep offers a significant discount, they might include a "Co-Marketing" term requiring the customer to participate in a case study, or a "Payment Terms" clause specifying net-30 payment.
[Full details →](/get-started/calculator/terms)
Flexible open-text fields with a title and body. Use these for narrative content that gives the buyer context around the pricing.
**Common uses:** Executive summaries, statements of work (SOW), implementation scope and assumptions, customer success commitments, or any other content that helps the buyer understand the deal beyond the numbers.
[Full details →](/get-started/calculator/blocks)
Embed videos from **Loom** or **Vidyard** directly into the proposal. Video walkthroughs let reps personally explain the pricing and terms, which increases engagement in asynchronous sales cycles.
Requires an active [Loom](/get-started/integrations/loom) or Vidyard integration.
***
## Building a Pricing Option
When you add a Pricing Option block, the Veles Calculator opens. This is where the deal gets configured.
### Select products
The product catalog appears on the left side. Click a product to add it as a line item. Products are filtered by your assigned [categories, regions, and segments](/get-started/pricing-and-packaging/product-filters), so you only see what's relevant to your deal.
Once added, the line item prompts for required inputs -- typically a quantity or a [driver value](/get-started/pricing-and-packaging/units-of-measure#input-kind-quantity-vs-driver), depending on the product's unit of measure.
### Set terms and timeline
At the top of the builder, configure the temporal structure:
* **Start and end dates** for the agreement
* **Term length** (e.g., 12 months, 24 months)
* **Multi-year support** up to 5 years
* **Billing frequency** from the options allowed by your admin configuration (monthly, quarterly, annual)
### Phases
For deals with pricing that changes over time (ramps, step-ups, multi-year structures), quotes are organized into **Phases**. A Phase is a discrete commitment interval with an explicit start and end date, representing a contiguous period during which a defined set of commercial terms applies.
Phases are strictly sequential and non-overlapping. Together they define the full schedule of the commercial commitment. Quote Lines are always associated with a specific Phase -- they inherit the Phase's date boundaries rather than defining their own service dates independently.
**Example:** A 3-year ramp deal might have three Phases: Year 1 (50 seats at 45/user), Year 2 (75 seats at \$48), Year 3 (100 seats at \$50/user). Each Phase is a distinct commitment window with its own pricing, and the Quote Lines within each Phase define the product-level obligations for that window.
When a quote is promoted to an Order, the Phase structure carries forward: each Quote Phase becomes an Order Phase, and each Quote Line becomes an Order Line associated with the corresponding Order Phase. The commitment schedule defined during quoting becomes binding at promotion.
### Real-time metrics
As you build, Veles calculates and displays key metrics in real time:
* **TCV** (Total Contract Value)
* **Year 1 Recurring** (ARR)
* **Year 1 Services** (one-time fees)
### Discounting
The line item table shows the full pricing waterfall so you can see exactly how a price is reached:
| Column | What it shows |
| - | - |
| **List Price** | The starting price from your price book. |
| **System Adjustment** | Automated changes driven by [Pricing Rules](/get-started/rules-and-approval/pricing-rules) or [Data Sheets](/get-started/pricing-and-packaging/data-sheets). |
| **System Price** | The price after automated adjustments, before any rep discount. |
| **Rep Discount** | The discretionary discount applied by the rep. |
Reps can apply discounts two ways: enter a discount percentage directly, or double-click the final price field and type a **target price** -- Veles back-calculates the required discount percentage automatically.
### Rules and approvals
Veles monitors the deal configuration in real time. If a line item or the overall deal structure breaches a company policy (e.g., discount exceeds 20%, unauthorized billing frequency, missing required product), **rule alerts** appear at the line item or option level.
Each alert explains why it was triggered and who needs to approve it. If you're an Admin, alerts include a direct link to the rule logic in the Admin Console.
[Full Pricing Options reference →](/get-started/calculator/quote-options)
***
## Multiple options on a single quote
Veles supports multiple Pricing Options on one quote, allowing you to present the buyer with choices without creating separate proposals.
**Common patterns:**
* Good / Better / Best packages
* Short-term vs. long-term commitment (1-year vs. 3-year)
* Different product configurations at different price points
The first option is marked **Primary** by default (the one you expect to close). You can reassign Primary status to any option.
For each option, you can:
* **Clone** it to duplicate a complex configuration and make small tweaks
* **Hide** it from the buyer while keeping it for internal reference
* **Delete** it entirely
While Veles supports unlimited options, presenting 2-3 choices is generally most effective. More than that risks creating analysis paralysis for the buyer.
***
## Publishing and versioning
Quotes move through a clear workflow from draft to buyer:
Configure your pricing options, add terms and text blocks, and finalize the proposal content. Everything is in draft state -- the buyer sees nothing.
If any pricing rules are breached (e.g., discount thresholds), the **Publish** button changes to **Request Approval**. The quote is routed to the appropriate approver based on your [approval configuration](/get-started/calculator/approvals) and org hierarchy.
Once all approvals are met (or if none were required), click **Publish**. This creates a permanent **version snapshot** of the quote, locking the pricing and content at that point in time. The published version is what the buyer sees.
Send the published quote to the buyer via the [Web Portal](/get-started/calculator/web-portal) (a branded link they can view in their browser) or generate a PDF document.
You can continue editing the quote after publishing -- changes stay in draft until you publish again, creating a new version. Veles tracks every published version, so you have a full audit trail of what was sent to the buyer and when.
***
## From Quote to Order: Promotion
When the buyer accepts and the deal is ready to execute, the quote is **promoted** to an Order. Promotion is not a clerical step -- it is the boundary between modeling and execution.
During promotion, the system:
1. **Locks the Quote** to prevent further modification. The quote becomes a historical negotiation artifact.
2. **Creates an Order** linked to the originating account and, if applicable, to an existing Contract.
3. **Transforms Quote Lines into Order Lines**, materializing the final commercial values (quantities, net prices, discounts, service dates) into immutable execution fields. Pricing ceases to be dynamic and becomes authoritative.
4. **Carries the Phase structure forward.** Each Quote Phase becomes an Order Phase with the same service boundaries.
5. **Enables downstream processes** such as billing orchestration (Stripe), CRM sync, and contract mutation.
Edits to a Quote after promotion do not cascade to the Order or Contract. Any changes to an executed deal require a new Order through the [amendment process](/get-started/contract-management/overview).
### Order creation vs. Order activation
It's important to distinguish between these two events. Order creation may occur immediately upon quote acceptance, but activation can be gated by additional steps: signature confirmation, finance approval, payment confirmation, or compliance review.
Contract mutation and billing typically occur only upon activation:
* **Quote acceptance** → Order created (pending state)
* **Order activation** → Contract updated + billing triggered
See [Contract Management](/get-started/contract-management/overview) for details on how activated Orders affect the Contract.
***
## CRM sync
When a quote is linked to a CRM opportunity or deal, data flows bi-directionally:
* **CRM → Veles:** Opportunity data (account, contacts, deal metadata) populates the quote's Context Block.
* **Veles → CRM:** Quote status, totals, and key metrics sync back to the CRM record as the deal progresses.
Changes in either system are reflected in the other. When a quote is approved and converted to an order, the committed data is pushed to the CRM as well.
[Connect your CRM →](/get-started/quickstart/connect-your-crm)
***
## Sharing via the Web Portal
The [Web Portal](/get-started/calculator/web-portal) is a branded, interactive page where buyers view your proposal. It provides a modern buying experience with engagement tracking built in.
Key capabilities:
* **Draft vs. live views** -- reps edit in draft mode; buyers only see published versions
* **Magic Link authentication** -- buyers enter their email and click a secure link to access the proposal
* **Engagement analytics** -- see who viewed the proposal, when, which options they clicked, and how long they spent
* **Display controls** -- toggle visibility of quantities, list prices, discounts, and other line item details
* **Real-time updates** -- update a proposal during a live call and the buyer simply refreshes to see the new version
[Web Portal reference →](/get-started/calculator/web-portal)
***
## What's next
Deep dive into building options: products, terms, discounting, and approvals.
Learn about the block types available for building proposals.
Insert legal terms and deal-specific language into quotes.
Configure and share interactive buyer-facing proposals.
Set up approval workflows for discounts and deal structure.
Configure the pricing guardrails that govern the quoting process.
# Quote Phases
Source: https://docs.getveles.com/get-started/calculator/quote-phase
Structure deals into sequential time periods with distinct pricing, quantities, and terms using Quote Phases.
A Phase is a discrete commitment interval within a deal. Each Phase has an explicit start and end date and represents a contiguous period during which a defined set of commercial terms applies. Phases are how Veles models deals where pricing, quantities, or product mix change over time.
For a simple annual deal, there's a single Phase covering the full term. For a multi-year ramp, there's one Phase per commitment window, each with its own pricing and quantity structure.
***
## Why Phases exist
In many B2B deals, the commercial commitment isn't uniform across the contract term. Common scenarios include:
* **Ramp deals** -- pricing or quantity increases over time (e.g., 50 seats in Year 1, 100 seats in Year 2)
* **Step-up pricing** -- the per-unit rate changes at defined intervals
* **Phased rollouts** -- different products activate at different points in the term
* **Promotional periods** -- discounted pricing for an initial period that reverts to standard rates
Without Phases, you'd need to model these as separate quotes or resort to manual calculations. Phases let you structure the full commitment schedule within a single Pricing Option, with each interval explicitly bounded and priced.
***
## How Phases work
### Structure
Phases are strictly **sequential** and **non-overlapping**. Together they cover the full duration of the commercial commitment from start to end. There are no gaps between Phases and no periods where two Phases overlap.
Each Phase defines:
| Attribute | Description |
| - | - |
| **Start date** | When this commitment interval begins. |
| **End date** | When this commitment interval ends. The next Phase (if any) starts the following day. |
| **Duration** | The length of the interval (derived from start and end dates). |
### Quote Lines belong to Phases
Quote Lines are always associated with a specific Phase. They do not independently define their own service dates -- instead, they inherit the date boundaries of the Phase they belong to. This ensures that all product-level commitments are explicitly bounded and structurally ordered before the quote is promoted.
A single Phase can contain multiple Quote Lines (different products), and the same product can appear across multiple Phases (with different pricing or quantities in each).
***
## Common patterns
### Single Phase (simple deal)
A straightforward 12-month or 24-month deal with uniform pricing across the entire term.
```text theme={null}
Phase 1: Jan 2026 - Dec 2026
└─ Platform License: 50 seats × $40/user/mo
└─ Premium Support: 10% of recurring
```
Most deals start here. You only need multiple Phases when the commercial terms change over time.
### Multi-year ramp
Pricing or quantity increases at defined annual intervals. Each year is a separate Phase with its own line item configuration.
```text theme={null}
Phase 1: Jan 2026 - Dec 2026 (Year 1)
└─ Platform License: 50 seats × $40/user/mo
Phase 2: Jan 2027 - Dec 2027 (Year 2)
└─ Platform License: 75 seats × $45/user/mo
Phase 3: Jan 2028 - Dec 2028 (Year 3)
└─ Platform License: 100 seats × $50/user/mo
```
The buyer sees the full commitment schedule on the proposal. TCV, Year 1 ARR, and other metrics are calculated across all Phases.
### Step-up pricing
The quantity stays the same, but the per-unit rate changes at defined intervals. Common for deals that offer a promotional rate for the first period.
```text theme={null}
Phase 1: Jan 2026 - Jun 2026 (Promotional)
└─ Platform License: 100 seats × $30/user/mo
Phase 2: Jul 2026 - Dec 2026 (Standard)
└─ Platform License: 100 seats × $50/user/mo
```
### Phased product rollout
Different products activate at different points during the contract.
```text theme={null}
Phase 1: Jan 2026 - Dec 2026 (Core only)
└─ Platform License: 50 seats × $40/user/mo
Phase 2: Jul 2026 - Dec 2026 (Add analytics mid-year)
└─ Analytics Add-on: 50 seats × $15/user/mo
```
Note that Phases for different products can overlap in calendar time as long as the Phase sequence within each Pricing Option is internally consistent.
***
## Building Phases in the Calculator
When you open a [Pricing Option](/get-started/calculator/quote-options) in the Veles Calculator, the Phase structure is managed at the top of the builder alongside the deal's start date, end date, and term length.
For a single-Phase deal, the default configuration is all you need -- one Phase covering the full term. To add additional Phases:
1. Configure the overall deal term (e.g., 3 years).
2. Add a Phase for each commitment interval. Set the start and end dates for each.
3. Within each Phase, add the products and configure quantities, pricing, and discounts specific to that interval.
Veles validates that Phases are sequential and non-overlapping. If you try to create a Phase that gaps or overlaps with another, the system will flag the conflict.
The real-time metrics at the top of the Calculator (TCV, Year 1 Recurring, Year 1 Services) update as you add and modify Phases, so you can see the financial impact of the full commitment schedule as you build it.
***
## Phases through the deal lifecycle
The Phase structure isn't just a quoting convenience -- it carries through the entire deal lifecycle with structural parity at every layer.
### At promotion (Quote → Order)
When a Quote is promoted, each Quote Phase becomes an **Order Phase** with the same service boundaries, and each Quote Line becomes an **Order Line** associated with the corresponding Order Phase.
At this point, the commitment schedule is no longer a modeling construct. The start and end dates become binding execution intervals embedded in the Order. Pricing ceases to be dynamic and becomes authoritative.
### At activation (Order → Contract)
When the Order is activated, each Order Phase produces a **Contract Phase**, and each Order Line produces a **Contract Line**. The Contract now contains the full commitment schedule as durable commercial state.
```text theme={null}
QuotePhase → OrderPhase → ContractPhase
QuoteLine → OrderLine → ContractLine
```
This parity means that nothing is lost in translation between layers. A three-year ramp structured as three Phases on the Quote is represented as three Phases on the Order and three Phases on the Contract. Finance can see exactly what was committed for each interval.
### In amendments
When an amendment Quote references an existing Contract, the amendment can introduce new Phases or modify future Phases without affecting executed ones. Existing Phase segments remain intact -- only future commitment windows are affected.
For example, if a customer on a 3-year ramp wants to add seats starting in Year 2, the amendment creates new or modified Quote Lines in the Year 2 and Year 3 Phases. The Year 1 Phase (already executed) is untouched.
See [Contract Management](/get-started/contract-management/overview) for details on how amendments interact with the Contract.
***
## What's next
Build options with products, discounting, and approval workflows.
Understand the full quote structure: blocks, publishing, and promotion.
How Phases carry through to Contracts and are affected by amendments.
How mid-Phase changes are calculated and applied.
# Terms
Source: https://docs.getveles.com/get-started/calculator/terms
Manage pre-approved legal clauses that reps can add to quotes during negotiation, protecting margins while accelerating deal cycles.
Terms in Veles are pre-approved legal clauses that reps can attach to specific Pricing Options during the negotiation process. They represent the non-price part of a deal -- the obligations, commitments, and trade-offs that sit alongside the commercial numbers.
Terms are managed as a centralized library by admins and inserted into quotes as [Terms blocks](/get-started/calculator/blocks). The legal language is locked -- reps can choose which terms to include, but they cannot edit the text. This ensures every proposal that goes out the door is compliant with your legal team's requirements.
***
## Why Terms exist
In most B2B negotiations, price isn't the only lever. Buyers ask for discounts, and sellers need to protect value. Terms give reps a structured way to trade non-price concessions for price concessions -- what the deal desk world calls "give to get."
Instead of a rep improvising legal language in an email or copy-pasting from old contracts, they select from a library of pre-approved clauses directly in the Calculator. The clause is attached to a specific Pricing Option, so the buyer sees exactly what's included with the price they're being quoted.
**Example:** A buyer asks for a 20% discount. The rep can say, "I can do that on Option B, which includes our standard co-marketing term." Option A (full price) has no terms attached. The buyer sees both options on the proposal and understands the trade-off.
***
## Common use cases
**Co-marketing agreements.** Language defining how a customer must participate in case studies, press releases, or logo usage in exchange for a preferred rate. Often tiered (Tier 1: logo only, Tier 2: case study, Tier 3: joint webinar).
**Multi-year pool options.** Standardized language for customers who pre-purchase credits, licenses, or capacity over a multi-year term at a locked rate.
**Opt-out / early termination clauses.** Pre-approved language for contract breaks, cancellation windows, or at-will termination. Typically attached to shorter-term or month-to-month options.
**Payment terms.** Net-30, net-60, or custom payment schedules attached to specific pricing options.
**Auto-renewal language.** Clauses defining whether the contract auto-renews, the notice period for cancellation, and any renewal uplift.
**Usage commitments.** Minimum usage thresholds or overage terms for consumption-based products.
***
## How reps use Terms
When building a [Pricing Option](/get-started/calculator/quote-options) in the Calculator, reps have access to the Terms library. The workflow:
1. **Browse the library.** Available terms are listed with their names and descriptions. The full legal text is viewable but not editable.
2. **Toggle terms on or off.** Adding a term attaches it to the specific Pricing Option being built. Removing it detaches it.
3. **Tag to specific options.** Terms are associated with individual Pricing Options, not the quote as a whole. This allows different options to carry different terms. Option A (standard price) might have no terms, while Option B (discounted price) includes co-marketing and auto-renewal language.
The attached terms appear on the published proposal and in generated documents. The buyer sees the full legal text alongside the pricing for that option.
Terms are a powerful negotiation tool when combined with [multiple Pricing Options](/get-started/calculator/quote-options#multiple-options-on-a-single-quote). Present the buyer with a "clean" option at full price and a discounted option with terms attached. The trade-off is visible and explicit.
***
## Admin configuration
Admins manage the Terms library from the **Admin Console > Calculator > Terms**. For each term, you define:
### Term name
How the rep identifies the term in the library (e.g., "Co-Marketing Tier 1", "Early Termination - 90 Day Notice", "Net-60 Payment Terms"). Keep names concise and descriptive so reps can scan the library quickly.
### Legal text
The full, formal language that appears on the proposal and in generated documents. This text is locked once saved -- reps cannot edit it when attaching it to a Pricing Option.
Have your legal team review and approve the text before publishing a term to the library. Once a rep attaches a term to a published quote, the language is part of the proposal sent to the buyer.
### Availability
Control which products or categories a term can be used with. For example, a "Co-Marketing" term might be available for all products, while a "Usage Commitment" term is only available for consumption-based products.
This prevents reps from attaching irrelevant terms to deals where they don't apply.
***
## Terms on the proposal
When a quote is published, attached terms appear as part of the Pricing Option on both the [Web Portal](/get-started/calculator/web-portal) and in generated PDF documents. The buyer sees the legal text formatted as a distinct section within the option, clearly associated with that specific pricing configuration.
If the buyer is comparing multiple options, they can see which terms are attached to each. This makes the "give to get" trade-off transparent: the discounted option comes with explicit obligations, and the full-price option does not.
***
## Terms vs. Text blocks
Terms and [Text blocks](/get-started/calculator/blocks) both add non-pricing content to a quote, but they serve different purposes:
| | Terms | Text blocks |
| - | - | - |
| **Content source** | Pre-approved library, managed by admin | Free-text, written by the rep |
| **Editability** | Locked -- reps cannot modify the language | Fully editable by the rep |
| **Association** | Attached to a specific Pricing Option | Standalone block on the quote |
| **Use case** | Legal clauses, compliance language | Executive summaries, SOWs, implementation notes |
| **Governance** | Centrally controlled | Rep discretion |
Use Terms for anything that needs legal review and consistency across deals. Use Text blocks for deal-specific narrative content.
***
## What's next
Build the pricing configurations that terms are attached to.
Learn about all block types: pricing options, terms, text, and video.
See how terms appear on the buyer-facing proposal.
Route quotes for review based on pricing and terms combinations.
# Web Portal
Source: https://docs.getveles.com/get-started/calculator/web-portal
Share interactive, branded proposals with buyers and track engagement in real time.
The Web Portal is a branded, interactive page where buyers view your proposals. Instead of sending a static PDF, you share a link to a live page that reflects your brand, updates in real time, and gives you visibility into how the buyer is engaging with the deal.
Buyers see the published version of the quote -- pricing options, terms, and content blocks -- rendered in a clean interface with your logo, colors, and optional custom background image.
***
## Admin setup
Before reps can use the portal, an admin needs to configure it.
Navigate to **Admin Console > Calculator > Portal**.
1. **Enable the portal** by toggling it on. This makes it available for all quotes.
2. **Upload a default background image** for the portal header. Recommended size: **960 x 400 pixels**.
3. **Configure a custom domain** (optional). Map a subdomain like `proposals.yourcompany.com` so the portal looks and feels like a native part of your brand rather than a third-party link.
***
## Draft vs. live views
Reps access the portal via the **Web Portal** tab at the top of any Quote page (next to the Pricing and PDF tabs).
The portal has two states:
**Draft view.** This is the rep's sandbox. You can rearrange blocks, adjust pricing, and add content without the buyer seeing anything. All changes stay in draft until you publish.
**Live (Prospect) view.** This is what the buyer sees. Changes only move from draft to live when you [publish](/get-started/calculator/quote-options#publishing-and-versioning) the quote. Publishing creates a permanent version snapshot and requires all [approvals](/get-started/calculator/approvals) to be met.
You can update a proposal during a live call with a buyer. Make changes in draft, hit Publish, and the buyer simply refreshes their page to see the new version.
***
## Sharing and security
On the right side of the portal page, you'll find the **Portal URL** -- the link you share with the buyer.
### Magic Link authentication
For sensitive proposals, enable **Magic Link** access. Instead of an open URL, buyers must enter their email address and click a verification link sent to their inbox before they can view the proposal. This ensures your pricing data doesn't end up in the wrong hands.
### Managing access
Click **Manage Portal Access** to see a detailed activity log for the proposal:
* **Visitor email** -- who viewed the proposal
* **Visit start time** -- when they opened it
* **Specific events** -- which pricing options they clicked, which sections they viewed
* **Duration** -- how long they spent on the page
This engagement data is available in real time and gives your sales team signal on buyer intent without requiring a follow-up call.
***
## Display options
Veles gives reps granular control over exactly how much pricing detail the buyer sees. These toggles let you simplify complex pricing for executive buyers or provide full transparency for procurement.
### Line item settings
* **Quantity & labels** -- show or hide the quantity and UOM labels (e.g., "50 Users").
* **List Price** -- toggle visibility of the pre-discount list price.
* **Discount percentage** -- show or hide the discount applied to each line.
* **Sublines** -- group sublines (components) together for a cleaner look, or ungroup them for full detail.
### Table and total settings
* **Fee separation** -- split recurring and one-time fees into separate tables, or keep them combined.
* **Shared inputs** -- show or hide the shared inputs used in calculations.
* **TCV visibility** -- toggle whether Total Contract Value is displayed.
* **Totals-only mode** -- hide line-item pricing entirely and show only the final totals. Useful for executive-level proposals where the per-line detail is noise.
### Visual customization
* **Custom background** -- while there's a default admin background, reps can disable it or upload a company-specific image for a personal touch on individual proposals.
* **Custom columns** -- turn on any custom columns you've built to display additional data points to the buyer.
***
## Why use the Web Portal over PDF
| | Web Portal | PDF |
| - | - | - |
| **Updates** | Real-time. Publish changes and the buyer sees them immediately. | Static. Every change requires generating and re-sending a new file. |
| **Engagement tracking** | Full analytics: who viewed, when, which options, duration. | No visibility. You don't know if they opened it. |
| **Interactivity** | Buyers can click between options, expand sections, and explore. | Flat document. All options are laid out linearly. |
| **Security** | Magic Link authentication. Access can be revoked. | Once sent, you lose control of the file. |
| **Branding** | Full branded experience with logo, colors, background. | Branded but static. No interactivity. |
PDF generation is still available for buyers who need a downloadable document (procurement processes, internal routing). You can use both -- send the portal link for the live experience and attach a PDF for offline reference.
***
## What's next
Understand the full quote structure and publishing workflow.
Configure approval workflows that gate publishing to the portal.
Configure the logo, colors, and branding that appear on the portal.
Generate PDF proposals alongside the portal experience.
# Contract Line
Source: https://docs.getveles.com/get-started/contract-management/contract-line
Understand Contract Lines: the product-level entitlements that define what a customer is paying for and entitled to receive.
A Contract Line is the product-level entitlement within a [Contract Phase](/get-started/contract-management/contract-phase). It defines what a customer is entitled to for a specific product during a specific commitment interval: the active quantity, the contracted price, the billing cadence, and the service boundaries.
Contract Lines are the system of record for entitlements. When someone asks "what is this customer paying for right now?", the answer is the set of active Contract Lines on the current Contract Phase.
***
## How Contract Lines are created
Contract Lines are produced when an [Order is activated](/get-started/orders/overview#order-creation-vs-activation). Each [Order Line](/orders/order-line) creates or modifies a Contract Line based on the Order's commercial classification and the contract impact instructions on the line.
```text theme={null}
OrderLine (activated) → ContractLine (created or modified)
```
Contract Lines are never created manually. They are always the result of an executed Order.
***
## What a Contract Line contains
| Field | Description |
| - | - |
| **Product** | The SKU. Identifies what the customer is entitled to. |
| **Active quantity** | The number of units the customer is currently entitled to. |
| **Contracted price** | The authoritative price for this product on this contract. This is the price that was committed at execution, not the current list price. |
| **Billing cadence** | How this entitlement is billed: monthly, quarterly, annual, or one-time. |
| **Service start** | When this entitlement begins. Inherited from the parent Contract Phase. |
| **Service end** | When this entitlement expires. Inherited from the parent Contract Phase. |
| **Renewal behavior** | How this line should be treated at renewal: auto-renew, manual renewal, or do not renew. |
| **Parent Contract Phase** | The Phase this line belongs to. |
| **Originating Order Line** | Reference to the Order Line that created or last modified this Contract Line. |
***
## The contracted price
The contracted price on a Contract Line is one of the most important values in the system. It is the authoritative price for this product on this contract -- the price that was agreed to during negotiation, resolved at [promotion](/get-started/calculator/quote-options#from-quote-to-order-promotion), and committed at [activation](/get-started/orders/overview#order-creation-vs-activation).
The contracted price is not the current list price. It is not recalculated when the price book changes. It is not affected by new pricing rules or data sheet updates. It is the price that was locked at the moment of execution.
This distinction matters most during [amendments](/get-started/contract-management/overview#contracted-price-preservation). When a customer modifies their contract mid-term, the contracted price serves as the baseline:
**Example:** A product was contracted at 4.25/unit after negotiation. The customer wants to add 20 more seats mid-term. The incremental seats are priced relative to the 4.25 contracted rate -- not the current list price of \$5.00. The system preserves the negotiated rate unless explicitly overridden.
This ensures commercial integrity, auditability, and predictability across the life of the agreement.
***
## How Contract Lines are affected by different Order types
### New Business
Each Order Line creates a new Contract Line. These initial Contract Lines establish the baseline entitlement: what the customer bought, at what price, for what period.
### Amendment: add product
The Order Line creates a new Contract Line for a product that wasn't on the Contract before. The new line is added to the appropriate Contract Phase (active or future, depending on when the new product takes effect).
### Amendment: modify existing
The Order Line adjusts an existing Contract Line. Common modifications include:
* **Increase quantity** -- the active quantity on the Contract Line is updated. For mid-term increases, [proration](/get-started/contract-management/proration-logic) is typically applied for the remaining duration of the active Phase.
* **Decrease quantity** -- the active quantity is reduced (if permitted by your configuration).
* **Adjust pricing prospectively** -- the contracted price is updated for future Phases only. The historical contracted price in past Phases is preserved.
The Contract Line's history is maintained. The system tracks what the quantity and price were before the amendment and what they are after.
### Renewal
Expiring Contract Lines are replaced by new ones with updated terms. The renewal may include:
* **Price uplift** -- the contracted price is adjusted (e.g., 5% annual increase).
* **Quantity changes** -- the quantity may increase or decrease based on the renewal negotiation.
* **Term changes** -- billing cadence or service boundaries may be adjusted.
The prior Contract Lines are preserved as historical records in their original Phases. The new Contract Lines are created in the new renewal Phase.
***
## Active vs. historical Contract Lines
Contract Lines exist in one of three states, determined by the status of their parent [Contract Phase](/get-started/contract-management/contract-phase):
**Active.** The parent Phase is current. These lines define what the customer is entitled to right now and what they are being billed for.
**Future.** The parent Phase hasn't started yet. These lines represent upcoming commitments (common in ramp and multi-year deals). They can be modified by amendments.
**Historical.** The parent Phase has ended. These lines are preserved as a permanent record of what was committed during that period. They cannot be modified and serve as the audit trail for past commercial state.
The ability to reconstruct the exact state of a customer's entitlements at any historical point in time is a direct result of preserving historical Contract Lines. Finance teams rely on this for revenue recognition, audit compliance, and reconciliation.
***
## Contract Lines and billing
If [Stripe](/get-started/quickstart/connect-your-stripe-account) is connected, active Contract Lines drive ongoing billing:
* **Recurring lines** generate invoices on their billing cadence (monthly, quarterly, annual) using the contracted price and active quantity.
* **Prorated lines** (from mid-term amendments) generate adjusted invoices for the remainder of the current Phase.
* **Renewal lines** trigger billing at the start of the new Phase using the updated contracted price.
The contracted price on the Contract Line is what appears on the invoice. There is no recalculation at billing time -- the price was resolved at execution and is used as-is.
***
## Contract Lines and the MCP server
Through the [Veles MCP server](/get-started/create-a-quote#ai-and-the-mcp-server), AI agents can query Contract Lines programmatically. This enables workflows like:
* Pulling the current entitlement state for a customer to inform a renewal conversation
* Checking contracted prices before building an amendment quote
* Monitoring upcoming Phase transitions to proactively generate renewal quotes
***
## Example: Contract Line through amendments
**Initial deal:** Customer buys 50 seats of Platform at \$40/user.
| Contract Line | Quantity | Contracted Price | Phase |
| - | - | - | - |
| Platform License | 50 | \$40/user | Year 1 (active) |
**Amendment: add 25 seats mid-term.**
| Contract Line | Quantity | Contracted Price | Phase | Notes |
| - | - | - | - | - |
| Platform License | 75 | \$40/user | Year 1 (active) | Quantity increased. Incremental 25 seats prorated for remaining months. Contracted price preserved at \$40. |
**Renewal with 5% uplift:**
| Contract Line | Quantity | Contracted Price | Phase |
| - | - | - | - |
| Platform License | 75 | \$40/user | Year 1 (historical) |
| Platform License | 75 | \$42/user | Year 2 (active) |
The Year 1 line is preserved at $40. The Year 2 line reflects the $42 renewal rate. Both are visible on the Contract.
***
## What's next
The commitment intervals that Contract Lines belong to.
The full Contract object model and mutation logic.
How mid-Phase changes are prorated on Contract Lines.
The execution-layer lines that produce Contract Lines.
# Contract Phase
Source: https://docs.getveles.com/get-started/contract-management/contract-phase
Understand Contract Phases: the durable commitment intervals that represent the current and historical state of a customer agreement.
A Contract Phase is a commitment interval on the Contract that represents a contiguous time period during which a defined set of commercial terms is (or was) in effect. Contract Phases are the durable-state counterpart of [Quote Phases](/get-started/calculator/quote-phase) and [Order Phases](/orders/order-phase) -- they carry the same structure but represent what has actually been committed, not what was modeled or executed.
The Contract is not a snapshot of a single deal. It is the accumulated result of every Order activated over time. Contract Phases reflect that history: some are active (the current commitment window), some are historical (past commitment windows preserved for audit), and some are future (upcoming commitment windows from ramp or multi-year deals).
***
## How Contract Phases are created
Contract Phases are produced when an [Order is activated](/get-started/orders/overview#order-creation-vs-activation). Each Order Phase creates or modifies a Contract Phase on the associated Contract.
```text theme={null}
OrderPhase (activated) → ContractPhase (created or modified)
```
The behavior depends on the Order's [commercial classification](/get-started/orders/overview#commercial-classifications):
### New Business
Each Order Phase creates a new Contract Phase from scratch. For a 3-year ramp deal with three Order Phases, the Contract will have three Contract Phases -- one for each year of the commitment.
### Amendment
New or modified Order Phases are applied to the Contract prospectively. The system appends new Contract Phases for future commitment windows or adjusts existing future Phases. Previously executed Phases remain intact.
For example, if a customer on a 3-year deal amends their Year 2 commitment, only the Year 2 and Year 3 Contract Phases are affected. The Year 1 Phase (already executed) is untouched.
### Renewal
The system creates new Contract Phases that replace or succeed the expiring ones. The prior Contract Phases are preserved as historical records, maintaining a complete audit trail of the commercial relationship.
Renewal Phases may contain updated pricing (with uplift), adjusted quantities, or modified terms. The transition from old Phases to new Phases marks the boundary between contract periods.
***
## What a Contract Phase contains
| Field | Description |
| - | - |
| **Start date** | When this commitment interval begins (or began). |
| **End date** | When this commitment interval ends (or ended). |
| **Status** | Whether the Phase is **active** (current), **future** (upcoming), or **historical** (past). |
| **Contract Lines** | The product-level entitlements for this interval. See [Contract Lines](/get-started/contract-management/contract-line). |
| **Parent Contract** | The Contract this Phase belongs to. |
| **Originating Order Phase** | Reference to the Order Phase that created or last modified this Contract Phase. |
***
## Phase lifecycle
Contract Phases move through a natural lifecycle as time passes:
The Phase exists on the Contract but its start date hasn't arrived yet. Common in multi-year and ramp deals where future commitment windows are defined upfront. Future Phases can be modified by amendment Orders.
The current date falls within the Phase's start and end dates. This Phase defines the customer's current entitlements. The Contract Lines within this Phase are what the customer is paying for and entitled to receive right now.
The Phase's end date has passed. It is no longer active but is preserved on the Contract as a permanent record. Historical Phases cannot be modified -- they represent what was committed during that period. Finance can reference historical Phases to reconstruct the state of any account at any point in time.
***
## Contract Phases and amendments
When an amendment Order is activated, the Contract mutation engine evaluates which Phases are affected:
**Historical Phases** are never modified. They represent executed commitments and are preserved for audit integrity.
**The active Phase** may be modified if the amendment takes effect during the current commitment window (e.g., adding seats mid-term). Proration is typically applied for the remaining duration of the active Phase. See [Proration Logic](/get-started/contract-management/proration-logic).
**Future Phases** can be modified, replaced, or extended. An amendment might adjust pricing in a future Phase, add new products to an upcoming commitment window, or extend the Contract by appending additional Phases.
Amendments always operate as a forward-looking delta against the current Contract state. They modify active and future Phases prospectively. They never rewrite historical Phases or recompute past pricing.
***
## Contract Phases and renewals
At renewal, the system handles Phase transitions in one of two ways:
**Term extension.** The existing Contract's final Phase is extended or a new Phase is appended with updated terms. The Contract remains a single continuous record.
**Successor contract.** A new Contract is created and the active lines are migrated forward into new Phases. The prior Contract and its Phases are preserved in full as a historical record.
In either case, the historical Phases from prior commitment periods remain intact. The complete pricing history -- every rate, every quantity, every Phase boundary -- is preserved across the full lifespan of the customer relationship.
***
## Example: full lifecycle
A customer signs a 2-year deal, then amends mid-way through Year 1, then renews:
**Initial deal (New Business Order activated):**
| Contract Phase | Status | Products |
| - | - | - |
| Year 1: Jan-Dec 2026 | Active | Platform: 50 seats × \$40 |
| Year 2: Jan-Dec 2027 | Future | Platform: 50 seats × \$40 |
**Amendment in June 2026 (adds Analytics):**
| Contract Phase | Status | Products |
| - | - | - |
| Year 1: Jan-Dec 2026 | Active | Platform: 50 seats × $40, Analytics: 50 seats × $ 15 (prorated from Jun) |
| Year 2: Jan-Dec 2027 | Future | Platform: 50 seats × $40, Analytics: 50 seats × $ 15 |
**After Year 1 completes:**
| Contract Phase | Status | Products |
| - | - | - |
| Year 1: Jan-Dec 2026 | Historical | Platform: 50 seats × $40, Analytics: 50 seats × $ 15 |
| Year 2: Jan-Dec 2027 | Active | Platform: 50 seats × $40, Analytics: 50 seats × $ 15 |
**Renewal (extends for Year 3 with 5% uplift):**
| Contract Phase | Status | Products |
| - | - | - |
| Year 1: Jan-Dec 2026 | Historical | Platform: 50 × $40, Analytics: 50 × $ 15 |
| Year 2: Jan-Dec 2027 | Historical | Platform: 50 × $40, Analytics: 50 × $ 15 |
| Year 3: Jan-Dec 2028 | Future | Platform: 50 × $42, Analytics: 50 × $ 15.75 |
Every Phase is preserved. Finance can reconstruct the exact commercial state at any point in the relationship.
***
## What's next
The product-level entitlements within each Contract Phase.
The full Contract object model and mutation logic.
How mid-Phase changes are prorated.
The execution-layer Phases that produce Contract Phases.
# Creating a Contract
Source: https://docs.getveles.com/get-started/contract-management/creating-a-contract-manually
Manually create contracts in Veles for backfilling existing agreements or recording deals that originated outside the quoting workflow.
Most contracts in Veles are created automatically when a Quote is [promoted](/get-started/calculator/quote-options#from-quote-to-order-promotion) to an Order and the Order is [activated](/get-started/orders/overview#order-creation-vs-activation). But there are situations where you need to create a contract manually -- backfilling an existing agreement that predates your Veles instance, recording a deal that was negotiated outside the platform, or migrating active contracts from a legacy system.
The manual contract creation wizard walks you through a 4-step process: Contract Details, Phases & Line Items, Documents, and Review & Activate.
Manual contract creation is a **backfill** operation. Double-check all dates, pricing, and billing details against the original signed agreement. Once a contract is activated, it becomes part of the revenue recognition process and requires a formal [amendment](/get-started/contract-management/overview#amendment) to modify or cancel.
***
## Starting a draft
To create a contract manually, navigate to the customer's account and click **Create Contract**. A confirmation dialog appears:
* The contract is created as a **draft** for the selected company.
* Drafts can be freely edited and deleted.
* Once activated, the contract is locked and becomes the source of truth.
Click **Create Draft** to enter the contract editor.
***
## Step 1: Contract Details
*Dates & billing*
The first step sets up the foundational terms that apply to every Phase and Line Item on the contract.
### Effective period
Set the **start date** and **end date** for the full contract duration. The **term** is calculated automatically from these dates.
Veles validates the dates and flags potential issues. For example, if you enter a start date of April 1, 2026 and an end date of April 1, 2027, Veles will note that this is "1 year and 1 day" and that a full 1-year term typically ends on March 31, 2027. Click **Fix** to auto-correct, or leave as-is if the dates match your signed agreement.
The effective period defines the outer boundaries of the contract. All [Phases](/get-started/contract-management/contract-phase) must fall within this range.
### Owner & billing
| Field | Description |
| - | - |
| **Billing name** | The company or contact name used on invoices. |
| **Billing email** | The email address where invoices are sent. |
| **Address** | The full billing address: street, suite/unit, city, state, and postal code. |
If the billing contact differs from the primary company contact, update it here. Billing info is used for invoicing and appears on generated financial documents.
### Purchase order (optional)
If the customer has issued a purchase order, enter the PO number here. This associates the PO with the contract for reference and can appear on invoices.
### Contract owner
The team member responsible for managing this contract and its renewals. The owner appears in the [Renewals dashboard](/get-started/contract-management/renewal-reporting) and can be used as a filter.
Click **Save & Continue** to proceed to Step 2.
***
## Step 2: Phases & Line Items
This step defines the commercial structure of the contract: what's being sold, at what price, and across what time periods.
### Adding Phases
The timeline bar at the top shows the full contract period (from the effective dates set in Step 1) and tracks how much of the term is covered by Phases.
Click **+ Add Phase** to create a commitment interval. For each Phase, set:
* **Start date** and **end date** within the contract's effective period.
* Phases must be sequential and non-overlapping.
* Together, they should cover the full contract duration.
For a simple annual deal, create a single Phase spanning the full term. For multi-year or ramp deals, create one Phase per commitment interval.
### Adding Line Items
Within each Phase, add the products and pricing that define the customer's entitlements:
* Select products from your [price book](/get-started/pricing-and-packaging/overview).
* Set the **quantity** and **contracted price** for each product.
* Configure **billing cadence** (monthly, quarterly, annual, one-time).
For backfilled contracts, enter the actual contracted price from the signed agreement -- not the current list price. The contracted price becomes the authoritative baseline for future [amendments](/get-started/contract-management/overview#contracted-price-preservation) and [renewals](/get-started/contract-management/overview#renewal).
The summary panel on the left tracks your progress: number of Phases, Line Items, and Total Value update as you build.
Click **Save & Continue** to proceed to Step 3.
***
## Step 3: Documents
*Attachments*
Attach supporting documents to the contract for reference. This is where you store the signed agreement, SOWs, order forms, or any other documentation associated with the deal.
Click **+ Add Document** to upload files. Supported formats include **PDF**, **DOCX**, and common image formats (PNG, JPG).
Documents are attached to the contract record and accessible to anyone who can view the contract. They're for reference only -- they don't affect the contract's commercial terms or pricing.
Document upload is optional. You can activate a contract without attaching documents and add them later.
Click **Save & Continue** to proceed to Step 4.
***
## Step 4: Review & Activate
*Final check*
The final step presents a summary of the contract and a readiness checklist before activation.
### Activation checklist
Veles validates that the contract is complete and flags any missing elements:
| Check | Status |
| - | - |
| **Effective period set** | Shows the date range and term length. |
| **Phases and line items** | Shows the count of Phases and Line Items. Incomplete if zero. |
| **Billing address provided** | Confirms billing details are entered. |
| **Owner assigned** | Shows the contract owner. |
| **Documents uploaded** | Optional. Shows whether supporting documents are attached. |
| **Special terms** | Confirms any special terms are recorded. |
Items with a green checkmark are complete. Items with a dash are either incomplete or optional.
### Contract details summary
Below the checklist, a summary displays the contract's key details (period, owner, billing address) and Phases & Line Items count. Click **Edit** on any section to go back and make changes.
### Activating
When you're ready, click **Activate Contract**.
**Activation is permanent.** Once activated, dates, pricing, and terms are locked. The contract becomes the system of record for this customer's entitlements. Future changes require a formal amendment.
If you're not ready to activate, you can save the contract as a draft and return later. Drafts can be freely edited and deleted.
After activation:
* The contract status changes from **Draft** to **Active**.
* [Contract Phases](/get-started/contract-management/contract-phase) and [Contract Lines](/get-started/contract-management/contract-line) become the authoritative entitlement record.
* The contract appears in the [Renewals dashboard](/get-started/contract-management/renewal-reporting) based on its end date.
* If [Stripe](/get-started/quickstart/connect-your-stripe-account) is connected, billing orchestration begins based on the contract's billing cadence.
***
## When to use manual contract creation
**Backfilling existing agreements.** When you first deploy Veles, your active customer contracts need to be entered into the system so that amendments, renewals, and reporting work correctly. Manual creation lets you record these agreements with their actual contracted pricing and terms.
**Off-platform deals.** If a deal was negotiated and signed outside of Veles (e.g., via email and a manually signed PDF), you can create the contract directly to bring it into the system of record.
**Migration from legacy CPQ.** When transitioning from another CPQ system, manual contract creation (or CSV import) establishes the baseline ARR and entitlement state in Veles.
For large-scale migrations with many contracts, contact the Veles team at [**hi@getveles.com**](mailto:hi@getveles.com) to discuss bulk import options rather than creating each contract individually.
***
## What's next
Understand the full contract lifecycle: amendments, renewals, and price preservation.
How Phases structure the commitment schedule on a contract.
The product-level entitlements that define what customers are paying for.
Track upcoming renewals from the Renewals dashboard.
# Contract Overview
Source: https://docs.getveles.com/get-started/contract-management/overview
Understand how Veles manages contracts as durable commercial state: the cumulative result of every order activated over time.
The Contract in Veles represents the durable commercial state of a customer relationship. It is not a transaction and it is not a document. It is the accumulated result of every executed Order applied over time -- the authoritative record of what a customer is entitled to right now.
When a New Business Order activates, the Contract is created. When an Amendment Order adds seats, the Contract is incrementally updated. When a Renewal Order extends the term, the Contract reflects the new commitment. The Contract is never overwritten wholesale. It is mutated prospectively, preserving the history of every prior commitment.
This page covers the Contract object model, how Orders affect Contracts, and the rules that govern amendments and renewals.
***
## The object model
The Contract mirrors the same three-level structure as Quotes and Orders:
| Layer | Quote | Order | Contract |
| - | - | - | - |
| **Header** | Quote | Order | Contract |
| **Time segments** | QuotePhase | OrderPhase | ContractPhase |
| **Line items** | QuoteLine | OrderLine | ContractLine |
This structural parity is intentional. Every commitment interval and line item is tracked from the moment it's modeled on a quote, through its execution as an order, to its durable state on the contract. Nothing is lost in translation between layers.
### Contract
The top-level record representing the full commercial relationship with a customer. It stores the account association, overall term, activation state, and references to all Orders that have affected it.
### Contract Phases
Each Contract Phase represents a contiguous time period during which a specific set of commercial terms applies. Phases are sequential and non-overlapping. They correspond to the Phases defined on the originating Quotes and Orders.
For a simple annual deal, there may be a single Phase. For a multi-year ramp deal, there will be one Phase per commitment interval (e.g., Year 1, Year 2, Year 3), each with its own pricing and quantity structure.
### Contract Lines
Contract Lines define the product-level entitlements within each Phase: the active quantity, contracted price, billing cadence, and service boundaries for each SKU. Contract Lines are the system of record for what the customer is paying for and what they're entitled to receive.
***
## How Orders affect Contracts
When an Order is activated, the system evaluates how each Order Line should affect the associated Contract. The behavior depends on the Order's commercial classification.
### New Business
If no prior Contract exists for the customer, Order activation creates a new Contract. Each Order Line produces one or more Contract Lines that define the initial entitlement: active quantity, contracted price, service start and end, billing cadence, and renewal behavior.
The Contract becomes the system of record for this customer's commercial relationship from this point forward.
### Amendment
If the Order references an existing Contract, the system applies mutation logic rather than creating a new baseline. The Contract is incrementally modified to reflect the change.
Amendment Orders can instruct the system to:
* Increase or decrease quantity of an existing Contract Line
* Add new products as new Contract Lines
* Adjust service periods
* Extend the term
* Introduce new Phases for future commitment windows
The Contract mutation engine resolves any conflicts that arise: co-termination of add-on products with the master term, proration of mid-term changes, alignment of new Phases with existing ones, and preservation of previously contracted pricing.
Amendments modify the Contract prospectively. They do not rewrite history. Existing executed segments remain intact -- only future commitment windows are affected.
### Renewal
In renewal scenarios, the system either extends the existing Contract term in place or creates a successor Contract and migrates active lines forward.
Renewal Orders often replace expiring Contract Lines with new ones that contain updated pricing, quantities, or terms. The historical record of prior pricing remains intact in previous Contract Phases, maintaining a full audit trail of the commercial relationship over time.
***
## Contracted price preservation
This is one of the most important concepts in contract management: **amendments do not reprice history**.
When an amendment Quote is created, it references the active Contract. That Contract contains the authoritative commercial state from all prior Orders: active quantities, service intervals, contracted unit prices, and any negotiated discounts or uplifts.
The amendment uses the **contracted price** as the baseline -- not the current list price and not the pricing rules that were in effect during the original negotiation.
**Example:** A product was originally contracted at $4.25/unit (after negotiation and discounting). If the customer adds seats mid-term via an amendment, the incremental seats are priced relative to that $4.25 contracted rate unless explicitly overridden. The system does not recompute pricing from the current price book or reapply the discount logic from the original deal.
This preserves three critical properties:
1. **Commercial integrity** -- negotiated pricing remains stable and enforceable across the life of the contract.
2. **Auditability** -- historical pricing logic does not need to be re-derived. The contracted price is authoritative.
3. **Predictability** -- amendments modify state; they do not reinterpret it. Both the customer and the finance team know what to expect.
At promotion of an amendment Quote, new or modified Phases become new Order Phases, new or modified Quote Lines become new Order Lines, and the Contract is updated by appending or adjusting future commitment segments. Existing executed segments remain untouched.
In practical terms, an amendment behaves as a forward-looking delta against the current Contract state, not as a recalculation of the entire commercial relationship.
***
## Activation vs. creation
It's important to distinguish between when an Order is created and when it's activated, because these are different events with different downstream effects.
**Order creation** may happen immediately when a quote is accepted. But the Order can remain in a pending state while additional steps are completed: signature confirmation, finance approval, payment processing, or compliance review.
**Order activation** is what actually triggers contract mutation, billing orchestration, and provisioning. Until the Order is activated, the Contract is unchanged.
```text theme={null}
Quote accepted → Order created (pending)
↓
Signature / Finance / Payment gates
↓
Order activated → Contract updated + Billing triggered
```
This separation ensures that commercial commitments are not recorded in the Contract until all required approvals and confirmations are complete.
***
## What each layer is authoritative for
After a deal moves through the full lifecycle, each object serves a specific purpose:
| Object | Authoritative for | Mutability |
| - | - | - |
| **Quote** | Historical negotiation artifact. What was proposed and how pricing was modeled. | Locked after promotion. |
| **Order** | Transactional history. What was committed, when, and by whom. | Immutable after activation. |
| **Contract** | Current entitlement state. What the customer is entitled to right now. | Updated only through new Orders. |
Edits to a Quote after promotion do not cascade to Orders or Contracts. Any changes to an executed deal require a new Order through the amendment process. This separation preserves auditability and financial integrity.
***
## System integrity
The architecture enforces a deliberate separation of concerns:
* **Quotes** are mutable and computational. The pricing engine operates here.
* **Orders** are authoritative and transactional. They contain fully resolved commercial values independent of future pricing model changes.
* **Contracts** are stateful and cumulative. They reflect the current reality of the customer relationship.
This design ensures that pricing experimentation on quotes never affects entitlements, that financial systems operate on immutable commitments, that amendments preserve historical integrity, and that revenue recognition aligns with executed Orders rather than draft Quotes.
***
## What's next
Understand how quotes are built, including Phases and the Promotion workflow.
Deep dive into amendment logic, renewal workflows, and price preservation.
How Veles calculates prorated charges for mid-term changes.
Configure the guardrails that govern amendments and renewals.
# Renewal Reporting
Source: https://docs.getveles.com/get-started/contract-management/renewal-reporting
Track upcoming contract renewals and expirations from the Renewals dashboard: filter by window, owner, and ARR at risk.
The Renewals dashboard gives your team a single view of every contract approaching its renewal date. It's accessible from the **Renewals** tab in the main navigation (alongside Companies, Quotes, and Approvals) and is designed to help sales, RevOps, and customer success teams prioritize renewal conversations before contracts expire.
***
## The dashboard
The Renewals view shows all active contracts with upcoming renewal dates, presented as a sortable, filterable table.
### Summary metrics
Three metrics are displayed at the top right of the dashboard, giving you an instant snapshot of your renewal pipeline:
| Metric | What it shows |
| - | - |
| **Contracts** | Total number of contracts matching your current filters. |
| **Total ARR** | The combined annual recurring revenue across all filtered contracts. |
| **Expiring ≤ 90D** | The number of contracts expiring within the next 90 days. This is your most urgent renewal queue. |
### Table columns
| Column | Description |
| - | - |
| **Company** | The customer account associated with the contract. |
| **Contract #** | The contract identifier. Click to open the full contract record. |
| **ARR** | The annual recurring revenue for this contract. |
| **Renewal Date** | The date the current contract term expires. Sortable to surface the most urgent renewals. |
| **Renewal** | The renewal status or action for this contract. |
***
## Filtering renewals
The dashboard provides three filters to narrow the view to the renewals that matter most.
### Search
The search bar filters by company name. Use it to quickly find a specific account's renewal status. Keyboard shortcut: **⌘+K** (Mac) or **Ctrl+K** (Windows).
### Owner
Filter by who owns the account or contract. Options include:
* **Anyone** -- show all renewals across the team (default).
* **Specific user** -- filter to renewals owned by a specific rep or CSM.
This is useful for managers reviewing their team's renewal pipeline or for individual reps focusing on their own book of business.
### Renewal Window
The renewal window filter is the primary tool for prioritizing by urgency. It segments contracts by how soon they expire:
| Window | What it shows |
| - | - |
| **All Dates** | Every contract with an upcoming renewal, regardless of timing. |
| **≤ 30 days** | Contracts expiring within the next 30 days. These need immediate action. |
| **31-60 days** | Contracts expiring in 1-2 months. Active renewal conversations should be underway. |
| **61-90 days** | Contracts expiring in 2-3 months. Renewal outreach should begin. |
| **91-180 days** | Contracts expiring in 3-6 months. Early planning and relationship check-ins. |
| **181-365 days** | Contracts expiring in 6-12 months. Long-range pipeline visibility. |
| **365+ days** | Contracts expiring more than a year out. Useful for multi-year deal tracking. |
Use the **≤ 30 days** and **31-60 days** filters in your weekly pipeline review to identify contracts that need immediate renewal attention. The **Expiring ≤ 90D** metric at the top gives you the total count without filtering.
***
## Using the Renewals dashboard
### Weekly renewal review
For sales managers and RevOps leads, the Renewals dashboard is a natural part of the weekly pipeline review:
1. Open the **Renewals** tab.
2. Set the Renewal Window to **≤ 30 days** to surface contracts expiring this month.
3. Review each contract's ARR to prioritize by revenue impact.
4. Check the renewal status for each -- has a renewal quote been created? Is an approval pending?
5. Widen to **31-60 days** to see what's coming next month.
### Individual rep workflow
Reps and CSMs can filter by their own name in the **Owner** filter to see only their renewals. This provides a focused view of their renewal pipeline without the noise of the full team's contracts.
### Proactive renewal outreach
Use the **61-90 days** and **91-180 days** windows to identify contracts that aren't urgent yet but should have renewal conversations starting. Early engagement gives you more time to negotiate, upsell, and address any customer concerns before the renewal deadline creates pressure.
***
## From renewal to action
When you identify a contract that needs renewal attention, the typical workflow is:
1. Click the contract in the Renewals table to open the full contract record.
2. Review the current [Contract Phases](/get-started/contract-management/contract-phase) and [Contract Lines](/get-started/contract-management/contract-line) to understand what the customer is currently entitled to and at what price.
3. Create a renewal [Quote](/get-started/calculator/quote-options) referencing the existing contract. The renewal quote can include updated pricing (with uplift), adjusted quantities, or modified terms.
4. Build and send the renewal proposal through the standard quoting workflow: configure pricing options, route through [approvals](/get-started/calculator/approvals) if needed, and share via the [Web Portal](/get-started/calculator/web-portal).
5. When the buyer accepts, [promote](/get-started/calculator/quote-options#from-quote-to-order-promotion) the quote to a renewal Order, which updates the Contract with new Phases and Lines.
***
## What's next
Understand the contract lifecycle: amendments, renewals, and price preservation.
How renewal Orders create new Contract Phases.
Build renewal quotes through the standard quoting workflow.
Configure rules that govern renewal pricing and discount thresholds.
# Document Generation
Source: https://docs.getveles.com/get-started/document-generation/overview
Generate branded proposals, order forms, and contracts from quote data using DOCX or Google Docs/Slides templates with dynamic merge fields.
Veles generates branded proposals, order forms, and contracts directly from quote data. You build templates in Microsoft Word (DOCX) or Google Docs/Slides, insert merge fields that reference quote variables, and Veles renders the final document with live deal data at generation time.
Templates are managed by admins and available to reps when generating documents from a quote. The output reflects your [brand identity](/get-started/quickstart/account-setup#brand-identity) (logo, colors) and can include pricing tables, terms, CRM data, and any content from the quote's blocks.
***
## Supported formats
| Format | Template | Output | Notes |
| - | - | - | - |
| **DOCX** (Microsoft Word) | `.docx` file with merge fields | PDF or DOCX | Uses Word's MERGEFIELD syntax. Most flexible for complex layouts. |
| **Google Docs** | Google Doc with template tags | PDF or Google Doc | Uses `{{ }}` handlebars syntax. Easier to collaborate on templates. |
| **Google Slides** | Google Slide deck with template tags | PDF or Google Slides | Same `{{ }}` syntax. Best for visual proposals and pitch decks. |
***
## Template syntax
### Inserting merge fields
1. Place your cursor where you want the dynamic value.
2. Press `Ctrl+F9` (Windows) or `Cmd+F9` (Mac) to create field brackets `{ }`.
3. Type the MERGEFIELD syntax between the brackets.
4. Press `Cmd+Shift+Option+U` to save the merge field.
5. Use `Alt+F9` (Windows) or `Option+F9` (Mac) to toggle between field codes and rendered values.
**Alternative:** Insert → Quick Parts → Field → choose "MergeField" from the list.
### Syntax reference
| Operation | Syntax |
| - | - |
| **Simple value** | `MERGEFIELD =title \* MERGEFORMAT` |
| **Nested value** | `MERGEFIELD =owner.name \* MERGEFORMAT` |
| **Loop start** | `MERGEFIELD options:each(option) \* MERGEFORMAT` |
| **Loop variable** | `MERGEFIELD =option.name \* MERGEFORMAT` |
| **Loop end** | `MERGEFIELD options:endEach \* MERGEFORMAT` |
| **Conditional start** | `MERGEFIELD salesforce:if \* MERGEFORMAT` |
| **Conditional end** | `MERGEFIELD salesforce:endIf \* MERGEFORMAT` |
| **Boolean conditional** | `MERGEFIELD block:if(is_option) \* MERGEFORMAT` |
### Syntax reference
Google Docs and Google Slides use the same handlebars-style syntax.
| Operation | Syntax |
| - | - |
| **Simple value** | `{{ title }}` |
| **Nested value** | `{{ owner.name }}` |
| **Loop start** | `{{ #each(options) as option }}` |
| **Loop variable** | `{{ option.name }}` |
| **Loop end** | `{{ /each }}` |
| **Conditional start** | `{{ #if(salesforce) }}` |
| **Else if** | `{{ #elseif(primary_option) }}` |
| **Else** | `{{ #else }}` |
| **Conditional end** | `{{ /if }}` |
***
## Template variables reference
Every variable below is available in all template formats. Use dot notation to access nested values (e.g., `owner.name`, `line.formatted.price`).
### Top-level fields
| Variable | Type | Description |
| - | - | - |
| `title` | String | The quote/opportunity title. |
| `logo` | Image | Company logo from your [brand settings](/get-started/quickstart/account-setup#brand-identity). |
| `terms_html` | HTML | Combined HTML from all Terms and Text blocks. Nullable. |
| `term` | Hash | The copy of each term on the quote, by the term's variable key (dynamic keys). See [Placing individual terms](#placing-individual-terms). |
| `blocks` | Array | All quote blocks in order (title, terms, options, text). See [Blocks](#blocks). |
| `options` | Array | Pricing Option blocks only. See [Options](#options). |
| `primary_option` | Object | The primary option (nullable if none set). Same structure as an option. |
### Owner (sales rep)
Access via `owner.*`.
| Variable | Type | Description | Example |
| - | - | - | - |
| `owner.name` | String | Full name | "Michael Scott" |
| `owner.email` | String | Email address | "[michael@company.com](mailto:michael@company.com)" |
| `owner.phone` | String | Phone number | "(555) 123-4567" |
| `owner.job_title` | String | Job title | "Regional Manager" |
### Title block
Access via `title_block.*` or when iterating blocks with `is_title`.
| Variable | Type | Description |
| - | - | - |
| `title_block.name` | String | Quote name. |
| `title_block.from` | String | From company name. |
| `title_block.prepared_by` | String | Preparer name. |
| `title_block.prepared_by_extra` | String | Preparer additional info (title, email). |
| `title_block.for` | String | Recipient company name. |
| `title_block.for_extra` | String | Recipient additional info. |
| `title_block.issued_on` | Date | Issue date (e.g., "January 15, 2025"). |
| `title_block.valid_until` | Date | Expiry date. |
### Blocks
The `blocks` array contains all blocks in the quote, in display order. Since blocks are polymorphic (they can be different types), use the type flags to conditionally render content.
| Flag | True when |
| - | - |
| `is_title` | Title block (cover page data). |
| `is_terms` | Terms or aggregated terms block. |
| `is_option` | Pricing Option block. |
| `is_text` | Text block (free-form content). |
Each block also has `terms_html` (for Terms/Text blocks) and `name` (for Title/Option blocks).
### Options
Access via the `options` array, `primary_option`, or when iterating blocks with `is_option`. Each option contains:
| Variable | Type | Description | Example |
| - | - | - | - |
| `option.name` | String | Option name. | "Enterprise Plan" |
| `option.frequency` | String | Billing frequency. | "annual", "monthly", "quarterly" |
| `option.year_count` | Integer | Number of calculation periods. | 3 |
| `option.formatted_contract_length` | String | Human-readable contract length. | "3 years" |
| `option.total_value` | String | Raw decimal total. | "150000.00" |
| `option.formatted_total_value` | Currency | Formatted total. | "\$150,000.00" |
| `option.currency` | String | Currency code. | "USD" |
| `option.start_date` | Date | First calculation start. | "January 1, 2025" |
| `option.end_date` | Date | Last calculation end. | "December 31, 2027" |
| `option.service_start_date` | Date | Service start date (nullable). | |
| `option.uplift` | String | Annual uplift percentage (nullable). | "3%" |
| `option.custom_fields` | Hash | Option-level custom fields (dynamic keys). | |
| `option.terms_html` | HTML | Terms specific to this option (nullable). | |
| `option.term` | Hash | The copy of each term on this option, by the term's variable key (dynamic keys). | |
| `option.calculations` | Array | One per billing period. See [Calculations](#calculations). | |
### Calculations (periods)
Each option contains a `calculations` array with one entry per billing period (year, quarter, month). Access via `option.calculations`.
| Variable | Type | Description | Example |
| - | - | - | - |
| `calc.year` | Integer | 1-based period number. | 1 |
| `calc.currency` | String | Currency code. | "USD" |
| `calc.start_date` | Date | Period start. | "January 1, 2025" |
| `calc.end_date` | Date | Period end. | "December 31, 2025" |
| `calc.total_discount` | Float | Raw discount amount. | 5000.0 |
| `calc.credits` | String | Formatted credits (abbreviated). | "100K" |
| `calc.credits_full` | String | Full unscaled credits number. | "100000" |
| `calc.credit_rate` | Currency | Unit price per credit. | |
| `calc.credit_discount` | String | Discount on credits. | |
| `calc.credit_total` | Currency | Credits total formatted. | |
| `calc.summary` | Hash | Summary variables (dynamic keys). | |
| `calc.uom_fields` | Hash | UOM field values (dynamic keys). | `{"seats": "100K"}` |
| `calc.custom_columns` | Hash | Custom calculation columns (dynamic keys). | |
| `calc.any_one_time` | Boolean | Has one-time lines? | |
| `calc.any_recurring` | Boolean | Has recurring lines? | |
| `calc.any_transactional` | Boolean | Has transactional lines? | |
| `calc.lines` | Array | All line items. See [Line Items](#line-items). | |
| `calc.one_time_lines` | Array | One-time lines only. | |
| `calc.recurring_lines` | Array | Recurring lines only. | |
#### Formatted totals
Access via `calc.formatted.*`.
| Variable | Type | Description | Example |
| - | - | - | - |
| `calc.formatted.total` | Currency | Period total. | "\$50,000.00" |
| `calc.formatted.original_total` | Currency | Pre-discount total. | "\$55,000.00" |
| `calc.formatted.discount` | Currency | Discount amount. | "\$5,000.00" |
| `calc.formatted.discount_total` | Currency | Total discount formatted. | |
| `calc.formatted.system_total` | Currency | System-calculated total. | |
| `calc.formatted.system_discount` | Currency | System-calculated discount. | |
#### One-time vs. recurring breakout
Access via `calc.breakout.*`. Both raw numbers and formatted strings are available.
| Variable | Type | Description |
| - | - | - |
| `calc.breakout.one_time_original` | Float | Raw one-time original amount. |
| `calc.breakout.one_time_total` | Float | Raw one-time total. |
| `calc.breakout.recurring_original` | Float | Raw recurring original amount. |
| `calc.breakout.recurring_total` | Float | Raw recurring total. |
| `calc.breakout.formatted_one_time_original` | Currency | One-time list price. |
| `calc.breakout.formatted_one_time_total` | Currency | One-time net price. |
| `calc.breakout.formatted_recurring_original` | Currency | Recurring list price. |
| `calc.breakout.formatted_recurring_total` | Currency | Recurring net price. |
| `calc.breakout.formatted_one_time_list` | Currency | One-time list (alternate). |
| `calc.breakout.formatted_one_time_net` | Currency | One-time net (alternate). |
| `calc.breakout.formatted_recurring_list` | Currency | Recurring list (alternate). |
| `calc.breakout.formatted_recurring_net` | Currency | Recurring net (alternate). |
### Line items
Access via `calc.lines`, `calc.one_time_lines`, or `calc.recurring_lines`. Each line represents a single product on the quote.
| Variable | Type | Description | Example |
| - | - | - | - |
| `line.product_name` | String | Product display name. | "Enterprise License" |
| `line.product_sku` | String | Product SKU (nullable). | |
| `line.category` | String | Product category (nullable). | |
| `line.quantity` | String | Quantity value. | "50" |
| `line.metric_value` | String | UOM + scale suffix. | "100K" |
| `line.unit_price` | Float | Raw unit price. | 100.0 |
| `line.one_time` | Boolean | Is this a one-time charge? | |
| `line.is_transactional` | Boolean | Is this a transactional charge? | |
| `line.prorated` | Boolean | Is this prorated? | |
| `line.custom_columns` | Hash | Line-level custom columns (dynamic keys). | |
| `line.product_custom_fields` | Hash | Product custom fields (dynamic keys). | |
#### Formatted line values
Access via `line.formatted.*`. These are pre-formatted for display.
| Variable | Type | Description | Example |
| - | - | - | - |
| `line.formatted.name` | String | Display name. | |
| `line.formatted.original_price` | Currency | List price. | "\$5,000.00" |
| `line.formatted.price` | Currency | Net price. | "\$4,500.00" |
| `line.formatted.discount` | Currency | Discount amount. | "\$500.00" |
| `line.formatted.prorated_price` | Currency | Prorated price (if applicable). | |
| `line.formatted.unit_price` | Currency | Formatted unit price. | "\$100.00" |
| `line.formatted.system_price` | Currency | System-calculated price. | |
| `line.formatted.system_price_discount` | Currency | System price discount. | |
#### Unit of Measure
Access via `line.uom.*` (nullable -- may not be present on all lines).
| Variable | Type | Description | Example |
| - | - | - | - |
| `line.uom.key` | String | UOM key. | "seats" |
| `line.uom.label` | String | UOM display label. | "Seats" |
### Salesforce data
Available when the quote is linked to Salesforce. **Always wrap in a conditional** since this is null when Salesforce is not connected.
| Variable | Type | Description |
| - | - | - |
| `salesforce.account_name` | String | SF account name. |
| `salesforce.account_id` | String | SF account ID. |
| `salesforce.account_phone` | String | Account phone. |
| `salesforce.account_website` | String | Account website URL. |
| `salesforce.stage` | String | Opportunity stage. |
| `salesforce.crm_url` | String | Link to Salesforce record. |
| `salesforce.cpq_url` | String | Link to Veles CPQ record. |
| `salesforce.last_sync` | String | Last sync timestamp (ISO 8601). |
| `salesforce.custom_fields.*` | Dynamic | Custom fields mapped in Veles. Access via dot notation: `salesforce.custom_fields.my_field`. |
#### Addresses
Access via `salesforce.billing_address.*` or `salesforce.shipping_address.*` (both nullable).
| Variable | Type |
| - | - |
| `*.street` | String |
| `*.city` | String |
| `*.state` | String |
| `*.postal_code` | String |
| `*.country` | String |
***
## Template examples
### Cover page (DOCX)
```text theme={null}
«=title_block.name»
Prepared for: «=title_block.for»
«=title_block.for_extra»
Prepared by: «=title_block.prepared_by»
«=title_block.prepared_by_extra»
Date: «=title_block.issued_on»
Valid until: «=title_block.valid_until»
```
### Iterating through all blocks (DOCX)
Use the type flags to render each block type differently:
```text theme={null}
«blocks:each(block)»
«block:if(is_title)»
«=block.name»
Prepared by: «=block.prepared_by»
«block:endIf»
«block:if(is_option)»
Option: «=block.name»
Total: «=block.formatted_total_value»
«block:endIf»
«block:if(is_terms)»
«=block.terms_html»
«block:endIf»
«block:if(is_text)»
«=block.terms_html»
«block:endIf»
«blocks:endEach»
```
### Pricing options with year-by-year breakdown (DOCX)
```text theme={null}
«options:each(option)»
«=option.name» — «=option.formatted_contract_length»
Total Contract Value: «=option.formatted_total_value»
«option.calculations:each(calc)»
Year «=calc.year» («=calc.start_date» – «=calc.end_date»)
Total: «=calc.formatted.total»
«calc:if(any_one_time)»
One-Time Fees: «=calc.breakout.formatted_one_time_total»
«calc:endIf»
«calc:if(any_recurring)»
Recurring: «=calc.breakout.formatted_recurring_total»
«calc:endIf»
«option.calculations:endEach»
«options:endEach»
```
### Line items table (DOCX)
```text theme={null}
«calc.lines:each(line)»
«=line.formatted.name» | «=line.quantity» | «=line.formatted.unit_price» | «=line.formatted.price»
«calc.lines:endEach»
```
### Separate one-time and recurring tables (DOCX)
```text theme={null}
«calc:if(any_recurring)»
Recurring Charges:
«calc.recurring_lines:each(line)»
«=line.formatted.name» | «=line.quantity» | «=line.formatted.price»
«calc.recurring_lines:endEach»
Recurring Total: «=calc.breakout.formatted_recurring_total»
«calc:endIf»
«calc:if(any_one_time)»
One-Time Charges:
«calc.one_time_lines:each(line)»
«=line.formatted.name» | «=line.formatted.price»
«calc.one_time_lines:endEach»
One-Time Total: «=calc.breakout.formatted_one_time_total»
«calc:endIf»
```
### Salesforce customer info with conditional (DOCX)
```text theme={null}
«salesforce:if»
Customer: «=salesforce.account_name»
«=salesforce.billing_address.street»
«=salesforce.billing_address.city», «=salesforce.billing_address.state» «=salesforce.billing_address.postal_code»
«salesforce:endIf»
```
### Placing individual terms
Every term has a variable key, shown on the term in **Admin > Terms**. The key is made from the term's name when the term is created (`Payment Terms` becomes `payment_terms`) and stays the same when the term is renamed, so templates that use it keep working.
`term.` prints that term's copy on its own, without the number and title `terms_html` puts in front of it, so you can place one term anywhere and write your own heading. It is blank when the quote does not carry the term, which makes it a condition too: wrap a section in it and the whole section is left out when the term is not on the quote. `terms_html` still prints every term together.
DOCX:
```text theme={null}
«term.payment_terms:if»
Section 4 - Payment Terms
«=term.payment_terms»
«term.payment_terms:else»
Standard payment terms apply.
«term.payment_terms:endIf»
```
Google Docs:
```text theme={null}
{{ #if(term.payment_terms) }}
Section 4 - Payment Terms
{{ term.payment_terms }}
{{ #else }}
Standard payment terms apply.
{{ /if }}
```
On a quote with several options, `term` covers every term on the quote and `option.term` covers the terms on one option.
### Full proposal (Google Docs)
```text theme={null}
{{ title_block.name }}
Prepared for: {{ title_block.for }}
Prepared by: {{ title_block.prepared_by }}
Date: {{ title_block.issued_on }}
{{ #each(options) as option }}
Option: {{ option.name }}
Contract Length: {{ option.formatted_contract_length }}
Total: {{ option.formatted_total_value }}
{{ #each(option.calculations) as calc }}
Year {{ calc.year }}:
{{ #each(calc.lines) as line }}
- {{ line.formatted.name }}: {{ line.quantity }} × {{ line.formatted.unit_price }} = {{ line.formatted.price }}
{{ /each }}
Period Total: {{ calc.formatted.total }}
{{ /each }}
{{ /each }}
{{ #if(salesforce) }}
Customer: {{ salesforce.account_name }}
{{ /if }}
```
***
## Dynamic hash fields
Several variables use dynamic keys (marked as "Hash" in the reference). These include `custom_fields`, `custom_columns`, `summary`, `uom_fields`, `product_custom_fields`, and `term`.
Access dynamic fields with dot notation using the field key:
```text theme={null}
«=option.custom_fields.my_custom_field»
«=calc.custom_columns.my_column»
«=salesforce.custom_fields.my_sf_field»
«=line.product_custom_fields.my_product_field»
```
The available keys depend on what custom fields you've configured in the [Object Explorer](/get-started/pricing-and-packaging/product), [Display Options](/get-started/calculator/quote-display-options), and [CRM field mapping](/get-started/quickstart/connect-your-crm#field-mapping).
***
## Tips
**Use `formatted` values for display.** Most numeric fields have both a raw value (e.g., `line.unit_price` = `100.0`) and a formatted version (e.g., `line.formatted.unit_price` = `"$100.00"`). Use the formatted versions in templates to get proper currency formatting without manual work.
**Always wrap Salesforce data in conditionals.** The `salesforce` object is null when no CRM is connected. Referencing `salesforce.account_name` without a conditional will produce an error in the generated document.
**Use `one_time_lines` and `recurring_lines` for split tables.** Instead of looping through all `lines` and checking the `one_time` flag on each, use the pre-filtered arrays for cleaner templates.
**Test with a real quote.** Generate a document from an actual quote to verify all merge fields resolve correctly. Nullable fields, empty arrays, and missing custom fields are the most common causes of template errors.
***
## What's next
Configure the logo and brand color that appear in generated documents.
Understand the quote structure that document generation renders from.
Control what pricing detail appears in generated documents.
Share interactive proposals alongside generated documents.
# HubSpot
Source: https://docs.getveles.com/get-started/integrations/hubspot
Connect Veles to HubSpot: authentication, company sync, deal linking, and pushing quotes back to HubSpot.
Veles integrates with HubSpot natively through OAuth. No package installation or custom objects required -- Veles connects directly to HubSpot's API to sync deal, company, and contact data. The integration is managed from **Admin Console > Integrations > HubSpot**, which contains two configuration tabs covering connection setup and company sync.
This page covers the full HubSpot setup. For a quick overview of CRM connection, see [Connect your CRM](/get-started/quickstart/connect-your-crm).
## Prerequisites
Before connecting, ensure you have:
* **HubSpot admin or super admin credentials** -- the user who authorizes the connection determines the API access level.
* **Veles admin access** -- only Veles admins can configure integrations.
* **A HubSpot plan that supports API access** -- Professional or Enterprise for most features.
## Setup
In Veles, go to **Admin Console > Integrations > HubSpot**.
Click **Connect to HubSpot**. You'll be redirected to HubSpot's authorization page.
Log in with your HubSpot admin credentials and authorize Veles to access your HubSpot account.
Once authorized, you'll be redirected back to Veles. The integration status will show **Configured** with a green badge.
Use a dedicated HubSpot user for the integration connection rather than a personal login. If the authenticated user's HubSpot credentials are revoked or their account is deactivated, the connection will break.
## General
The **General** tab manages the core connection between Veles and your HubSpot account.
Once authenticated, the General tab displays:
| Field | Description |
| - | - |
| **Connected as** | The HubSpot user who authorized the connection. |
| **Status** | Shows **Configured** when the connection is live and active. |
| **Primary CRM** | Indicates whether HubSpot is set as your primary CRM in Veles. |
From this tab you can:
* **Enable / Disable** -- toggle the integration on or off without disconnecting.
* **Make Primary CRM** -- set HubSpot as your default CRM. This controls which CRM context appears in the quote builder, opportunity list, and push workflows.
* **Disconnect** -- completely remove the HubSpot connection, credentials, and settings.
## Companies
The **Companies** tab manages company sync between HubSpot and Veles.
### How company sync works
Veles pulls company records from HubSpot and keeps them updated as changes occur. The sync runs in two phases:
1. **Initial sync** -- when first enabled, Veles imports all companies associated with deals modified in the past year. This runs as a background job and may take several minutes depending on your HubSpot data volume.
2. **Incremental sync** -- after the initial sync completes, Veles automatically checks for new and modified companies on a recurring schedule.
### Manual sync
Click **Sync Companies** to trigger an immediate sync rather than waiting for the next automatic cycle. The tab displays a **Last synced** timestamp showing when data was last pulled from HubSpot.
### What syncs
| HubSpot field | Veles field |
| - | - |
| Company name | Customer name |
| Domain | Website |
| Industry | Industry |
| Address, City, State, Zip, Country | Address fields |
| Phone | Phone |
| Owner | Account owner (matched by email) |
## What syncs between systems
Once connected, Veles exchanges data with HubSpot across these objects:
| Veles object | HubSpot object | Sync direction | What flows |
| - | - | - | - |
| **Customer** | Company | HubSpot → Veles | Company name, address, industry, domain, phone. |
| **Contact** | Contact | HubSpot → Veles | Name, email, title, phone. Used to populate the "Prepared For" field on quotes. |
| **Quote** | Deal | Bi-directional | Quote metadata, status, and totals sync back to the deal. Deal data populates quote context. |
| **Order** | Deal | Veles → HubSpot | When a quote converts to an order, committed deal data is pushed to HubSpot. |
| **Contract** | Deal | Veles → HubSpot | Active contract details, including entitlements and renewal dates. |
Veles pulls company and contact data from HubSpot, but HubSpot remains the system of record for those objects. Edits to customer or contact info should be made in HubSpot -- they'll sync to Veles automatically.
## Linking quotes to deals
Veles quotes can be linked to HubSpot deals, creating a bi-directional connection that keeps both systems in sync.
### Link during quote creation
1. Click **New Quote**.
2. Select the **Link from CRM** tab.
3. Search for a HubSpot deal by name (minimum 2 characters).
4. Click the deal to create a linked quote.
The deal picker shows a searchable table with columns for deal name, company, owner, type, and stage. By default, only open deals are shown.
### Link an existing quote
1. Open the quote in the builder.
2. Click the **HubSpot menu** in the toolbar.
3. Select **Link to Deal**.
4. Search for and select the deal.
### Unlink a quote
1. Open the quote in the builder.
2. Click the **HubSpot menu**.
3. Select **Unlink**.
When a quote is linked, a HubSpot icon appears in the opportunity header. Clicking it opens the deal directly in HubSpot.
## Syncing deal data
Once a quote is linked to a deal, you can pull the latest deal data from HubSpot into Veles at any time:
1. Open the linked quote.
2. Click the **HubSpot menu**.
3. Select **Sync**.
The sync pulls the current deal name, stage, type, owner, and associated company data into Veles. The **Last Synced** timestamp in the menu shows when data was last pulled.
### Owner matching
Veles matches HubSpot deal owners to Veles users by email address (case-insensitive). If a matching user isn't found in Veles, the deal will still link but a warning is displayed.
## Pushing quotes to HubSpot
Push your finalized quote data back to HubSpot as line items and a native HubSpot quote.
From the HubSpot menu in the quote builder, select **Push to HubSpot**. Or navigate directly to the push page from the opportunity.
Select which pricing **option** to push (if your quote has multiple options). The form shows each option's name, TCV, term length, and line count. Optionally set a **service start date**.
Click **Simulate Push** to run a dry-run preview of what will be sent to HubSpot without making any changes.
Click **Push to HubSpot** to send the data. You'll be taken to a status page showing real-time progress of the background job.
Once the push succeeds, click **View in HubSpot** to see the created line items and quote in your HubSpot deal.
### What gets pushed
* **Line items** -- each quote line is created as a HubSpot line item on the deal, including quantity, price, SKU, frequency, and billing period.
* **Native quote** -- a HubSpot quote object is created with the title, total amount, and TCV.
* **Notes** -- optional notes can be attached to the deal.
### Product matching
Veles matches products to HubSpot by **SKU**. Ensure your HubSpot product SKUs match the SKUs configured in Veles for line items to link correctly.
## Company field sync
Individual company records can be synced on demand from the company detail page:
1. Navigate to the company in Veles.
2. Click the **sync icon** next to the HubSpot company ID badge.
3. Veles pulls the latest company properties (industry, lifecycle stage, segment, website) from HubSpot.
The HubSpot company ID appears as a clickable orange badge on the company detail page, linking directly to the record in HubSpot.
## HubSpot data in Veles
Once connected, HubSpot data flows into Veles across several areas:
* **Quotes.** The Context Block can auto-populate from the linked deal: deal name, customer info, rep details, and stage.
* **Opportunity list.** The CRM Link column shows a HubSpot icon for linked quotes. The CRM Account Name column shows the associated company. The Status column shows the HubSpot deal stage alongside the Veles status.
* **Activity feed.** Link and unlink events are recorded in the opportunity's activity history with the user who performed the action and a timestamp.
* **Contract management.** When a quote is promoted to an order or contract, the committed deal data syncs back to HubSpot.
## User authentication
Each Veles user can connect their own HubSpot account for personalized access. This is separate from the admin-level integration connection.
### Connect your personal account
Navigate to **Settings > Integrations** and click **Connect** next to HubSpot. Once connected, your CRM dropdown in the top navigation shows a green status indicator and your HubSpot domain.
### Session expiry
If your HubSpot OAuth session expires, Veles displays a prompt to re-authenticate. Click **Login With HubSpot** to refresh your session. You'll be redirected back to your current page after re-authenticating.
## Troubleshooting
### Connection shows disconnected
* Verify the user who authorized the integration still has active HubSpot admin credentials.
* Check that the HubSpot account hasn't been suspended or downgraded to a plan without API access.
* Try disconnecting and reconnecting from **Admin Console > Integrations > HubSpot**.
### Deals not appearing in search
* Ensure you're searching with at least 2 characters.
* By default, only **open deals** are shown. Closed deals are filtered out.
* Verify your HubSpot user has permission to view the deals in question.
* If you see an authentication error, re-authenticate via the HubSpot login prompt.
### Company sync not running
* The initial sync must complete before incremental syncs begin. Check the **Companies** tab for sync status.
* If the initial sync appears stuck, trigger a manual sync with the **Sync Companies** button.
* Verify the integration is enabled on the **General** tab.
### Push to HubSpot fails
* Confirm the quote is linked to a HubSpot deal before pushing.
* Check that the opportunity is in the correct state (not still in draft).
* Review the job status page for specific error messages.
* Ensure product SKUs in Veles match those in HubSpot for line item matching.
### Owner not matching
* Veles matches HubSpot owners to Veles users by **email address**. Ensure the email addresses match between systems.
* If an owner can't be resolved, the deal will still sync but the owner field may be empty in Veles.
### Rate limiting
If you see rate limit errors in sync operations, HubSpot is throttling API requests. Veles handles this automatically with retry logic, but if issues persist, check your HubSpot API usage dashboard and consider spacing out manual sync triggers.
For persistent issues, reach out to the Veles team at [**hi@getveles.com**](mailto:hi@getveles.com) with the specific error message or sync behavior you're seeing.
## What's next
Overview of CRM connection for both Salesforce and HubSpot.
Build a quote linked to a live HubSpot deal.
Add billing and payment collection to your deal flow.
Set up pricing guardrails now that your data is flowing.
# Salesforce
Source: https://docs.getveles.com/get-started/integrations/salesforce
Connect Veles to Salesforce: authentication, environment configuration, field mapping across proposals, products, companies, and users.
Veles integrates with Salesforce via API, providing bi-directional sync between your CRM data and the quoting engine. The integration is managed from **Admin Console > Integrations > Salesforce**, which contains eight configuration tabs covering every aspect of the connection.
This page covers the full Salesforce setup. For a quick overview of CRM connection, see [Connect your CRM](/get-started/quickstart/connect-your-crm).
***
## General
The General tab manages the core connection between Veles and your Salesforce instance.
### Authentication
Click **Connect to Salesforce** and log in with your Salesforce admin credentials to authorize the connection. Once authenticated, the General tab displays:
* **Authenticated as** -- the Salesforce user who authorized the connection (name and email).
* **SFDC Connected** status badge -- confirms the connection is live.
* **Primary CRM** badge -- indicates Salesforce is set as your primary CRM in Veles.
If the authenticated user's Salesforce credentials are revoked or their account is deactivated, the connection will break. Use a dedicated integration user or service account rather than a personal login when possible. See [Integration User](#integration-user).
### Connection information
| Field | Description |
| - | - |
| **Environment** | Choose whether Veles connects to your Salesforce **Production** or **Sandbox** instance. Use Sandbox for testing your integration setup before going live. |
| **Instance URL** | The URL of your Salesforce instance (e.g., `https://yourcompany.my.salesforce.com`). Veles uses this to route API calls to the correct org. |
Click **Update Connection Information** to save changes to the environment or instance URL.
When first setting up the integration, start with a **Sandbox** environment to test field mappings and sync behavior without affecting production data. Switch to Production once you've validated the configuration.
### Pricebook information
| Field | Description |
| - | - |
| **Pricebook** (optional) | Specify which Salesforce Pricebook to use when linking products between the two systems. If not provided, Veles assumes the standard pricebook. |
This setting matters if your Salesforce org uses multiple pricebooks (e.g., separate books for different regions or customer tiers). Set it to the pricebook that matches the products you've configured in Veles.
Click **Update Pricebook** to save.
***
## CPQ
The CPQ tab provides access to your Salesforce CPQ rule configuration. If you're migrating from Salesforce CPQ, this tab lets you view your existing SFDC CPQ rules directly in Veles without switching between systems.
For each imported rule, the CPQ Configuration view shows the original SFDC rule details: rule name, rule ID, active status, conditions, scope, type, evaluation event, and evaluation order. A **View in CPQ** button links back to the original rule in Salesforce.
See [Translating SFDC Rules to Veles](/get-started/rules-and-approval/translating-sfdc-rules-to-veles) for the full migration guide.
***
## Integration User
The Integration User tab configures which Salesforce user Veles uses for API operations. This determines the permissions and visibility available to the integration.
Best practice is to use a dedicated Salesforce integration user rather than a personal admin account. This ensures the connection isn't disrupted when individual users change roles, leave the organization, or update their passwords.
The integration user needs sufficient Salesforce permissions to read and write the objects that Veles syncs with: Accounts, Contacts, Opportunities, and any custom objects used in your field mappings.
### Authentication modes
Click **Configure Integration User** and choose how Veles authenticates as the integration user:
| Mode | What you provide |
| - | - |
| **Shared Credentials** | A Veles user who has connected their Salesforce account. Veles uses that user's OAuth connection. |
| **Dedicated User** | The integration user's username, password, and security token. |
| **Client Credentials** | The consumer key and secret of a Connected App you create with the OAuth 2.0 client credentials flow enabled. No password is shared with Veles. |
### Setting up client credentials
The client credentials flow lets Veles connect without a password or a browser login, which makes it a good fit for an API-only integration user (such as one on the Salesforce Integration license).
1. In Salesforce Setup, create a Connected App (or External Client App) for Veles. Enable OAuth with the **Manage user data via APIs (api)** scope, and enable the **client credentials flow**.
2. In the app's OAuth policies, set **Run As** to your integration user. Every API call Veles makes runs as this user, with this user's permissions.
3. Copy the app's **consumer key** and **consumer secret**.
4. In Veles, set the **Instance URL** on the General tab to your My Domain URL (e.g., `https://yourcompany.my.salesforce.com`). Salesforce only accepts client credentials at your My Domain, not at `login.salesforce.com` or `test.salesforce.com`.
5. On the Integration User tab, click **Configure Integration User**, choose **Client Credentials**, and paste the consumer key and secret.
Once saved, the Integration User tab shows the Run As user Veles connected as.
***
## Field Mapping
Veles provides four separate field mapping tabs, each handling a different object type. Field mapping defines how data flows between Salesforce fields and Veles fields -- which fields correspond to each other, and how values are transformed during sync.
All four mapping tabs follow the same pattern: you define source fields (in one system), target fields (in the other), and optionally set transformation rules.
### Proposal Field Mapping
Maps fields between Salesforce Opportunity fields and Veles Quote/Proposal fields.
**What syncs:**
| Direction | What flows |
| - | - |
| **Salesforce → Veles** | Opportunity data populates the quote Context Block: deal name, amount, stage, close date, and custom opportunity fields. |
| **Veles → Salesforce** | Quote status, totals (TCV, ARR), and key metrics write back to custom fields on the Opportunity. |
**Common mappings:**
| Salesforce field | Veles field | Direction |
| - | - | - |
| Opportunity Name | Quote title | SF → Veles |
| Account Name | Customer name | SF → Veles |
| Amount | Total Contract Value | Veles → SF |
| Stage | Quote status | Veles → SF |
| Custom fields | Custom proposal fields | Bi-directional |
Configure your mappings in the **Proposal Field Mapping** tab. Veles ships with sensible defaults for standard Opportunity fields. Add custom mappings for any org-specific fields you want to sync.
### Product Field Mapping
Maps fields between Salesforce Product/Pricebook Entry fields and Veles Product fields.
**What syncs:**
| Direction | What flows |
| - | - |
| **Salesforce → Veles** | Product name, SKU, description, and custom product fields populate the Veles catalog. |
| **Veles → Salesforce** | Product-level data from Veles can write back to Salesforce product records. |
This mapping is especially important if you maintain your product catalog in Salesforce and want to keep it in sync with Veles. The [External ID](/get-started/pricing-and-packaging/product) field on Veles products stores the Salesforce Product ID to maintain the link between records.
### Company Field Mapping
Maps fields between Salesforce Account fields and Veles Customer (Company) fields.
**What syncs:**
| Direction | What flows |
| - | - |
| **Salesforce → Veles** | Account name, billing address, shipping address, industry, phone, website, and custom account fields. |
| **Veles → Salesforce** | Customer-level data from Veles can write back to the Account. |
Company field mapping ensures that when a rep creates a quote for a customer, the account data from Salesforce is available in Veles without re-entry.
### User Field Mapping
Maps fields between Salesforce User fields and Veles User fields.
**What syncs:**
| Direction | What flows |
| - | - |
| **Salesforce → Veles** | User name, email, title, region, and custom user fields. |
| **Veles → Salesforce** | User-level data from Veles can write back to the User record. |
User field mapping is particularly useful for [Product Filters](/get-started/pricing-and-packaging/product-filters). If your Salesforce users have region or vertical assignments, mapping those fields to Veles means you can use them as [CRM-sourced filter values](/get-started/pricing-and-packaging/product-filters#crm-fields) without duplicating the data.
***
## Working with field mappings
All four mapping tabs share the same configuration interface. For each mapping:
1. Select the **source field** (the field you're mapping from).
2. Select the **target field** (the field you're mapping to).
3. Optionally set a **transformation** if the value needs to be modified during sync:
* **Direct** -- value copies as-is.
* **Formula** -- a formula transforms the value (e.g., concatenating fields, calculating a derived value).
* **Static** -- a fixed value is applied regardless of the source.
Review the default mappings before adding custom ones. Veles pre-configures mappings for standard Salesforce fields (Opportunity Name, Account Name, Amount, etc.). You typically only need to add mappings for custom fields specific to your org.
***
## Actions
The Actions tab provides manual operations for the Salesforce integration:
* **Sync now** -- trigger an immediate sync rather than waiting for the next automatic cycle.
* **Reset connection** -- disconnect and reconnect the Salesforce integration (useful for troubleshooting).
* **View sync log** -- review recent sync operations, errors, and field-level issues.
Use the sync log to diagnose integration problems. Each log entry shows the objects synced, the fields updated, and any errors encountered (e.g., field type mismatches, permission failures, or missing required fields).
***
## Salesforce data in Veles
Once connected and mapped, Salesforce data flows into Veles across several areas:
**Quotes.** The [Context Block](/get-started/calculator/quote-options#context-block) can auto-populate from the linked Opportunity: deal name, customer info, rep details, and any mapped custom fields.
**Product Filters.** CRM-sourced fields from the User mapping can drive [Product Filters](/get-started/pricing-and-packaging/product-filters#crm-fields), controlling which products each rep sees during quoting.
**Document Generation.** The full Salesforce data object (account, addresses, stage, custom fields) is available in [document templates](/get-started/document-generation#salesforce-data) via the `salesforce.*` variables.
**Contract Management.** When a quote is [promoted](/get-started/calculator/quote-options#from-quote-to-order-promotion) to an Order, the committed deal data syncs back to Salesforce, keeping the CRM current as deals progress through the lifecycle.
***
## Troubleshooting
### Connection shows disconnected
1. Verify the authenticated user still has active Salesforce credentials.
2. Check that the Instance URL is correct and matches your current Salesforce org.
3. If you recently switched between Sandbox and Production, re-authenticate.
4. Try resetting the connection from the **Actions** tab.
### Fields not syncing
1. Confirm the field mapping exists in the appropriate mapping tab.
2. Check that the field types are compatible (e.g., a Salesforce picklist mapping to a Veles text field may not behave as expected).
3. Verify the integration user has read/write access to the fields in question.
4. Check the sync log in the **Actions** tab for specific error messages.
### Products not linking
1. Confirm the **Pricebook** setting on the General tab matches the pricebook containing your products.
2. Check that the product's External ID in Veles matches the Salesforce Product ID.
3. Verify Product Field Mapping is configured correctly.
For persistent issues, reach out to the Veles team at [**hi@getveles.com**](mailto:hi@getveles.com) with the error details from the sync log.
***
## What's next
Overview of CRM connection for both Salesforce and HubSpot.
Migrate your Salesforce CPQ rules to Veles.
Use Salesforce user fields as CRM-sourced filter values.
Use Salesforce data in document templates.
# Stripe
Source: https://docs.getveles.com/get-started/integrations/stripe
Connect Veles to Stripe: sync customers, match and import products, manage billing data, and review unmatched records.
Veles integrates with Stripe to sync customer billing data, import your product catalog, and orchestrate payment collection. The integration is managed from **Admin Console > Integrations > Stripe** and contains four tabs: General, Customers, Products, and Subscriptions.
This page covers the full Stripe setup and ongoing management. For initial connection steps, see [Connect your Stripe Account](/get-started/quickstart/connect-your-stripe-account).
***
## General
The General tab manages the core connection between Veles and your Stripe account.
### Connection information
Once connected, the General tab displays your connection details:
| Field | Description |
| - | - |
| **Account** | Your Stripe account name. |
| **Account ID** | The Stripe account identifier (e.g., `acct_1lVl...`). |
| **Mode** | **Test** or **Live**. Determines whether Veles interacts with your Stripe test environment or production environment. |
| **Connected** | The date the connection was established. |
| **Customers Last Synced** | How recently customer data was synced between the systems. |
Start with **Test** mode to verify the integration behavior before switching to Live. In Test mode, Veles syncs with your Stripe test data -- no real transactions are affected.
### Managing the connection
**Update API Key.** If you need to refresh or rotate your Stripe API key, click **Update API Key** and enter the new key. The connection updates without requiring a full reconnection.
**Disconnect.** Click **Disconnect** to sever the Stripe integration. This stops all sync and billing orchestration immediately. Existing data in Veles (imported products, synced customers) is preserved but will no longer update.
### Automatic sync
Once connected, customer data syncs automatically on a regular cadence. The "Customers Last Synced" timestamp on the General tab shows when the most recent sync occurred.
***
## Customers
The Customers tab shows Stripe customers and their match status against Veles Customer (Company) records.
### How customer matching works
When Veles syncs with Stripe, it attempts to match each Stripe customer to an existing Customer record in Veles. Matching uses identifying information (name, email, domain) to find the corresponding record.
Customers can be in one of two states:
* **Matched** -- the Stripe customer is linked to a Veles Customer record. Billing data flows between them.
* **Not Matched** -- the Stripe customer doesn't have a corresponding Veles record. Needs manual review.
### Reviewing unmatched customers
When unmatched customers exist, a yellow alert banner appears at the top of the tab:
> "X unmatched Stripe customers need review"
Click **Review** to see the unmatched records and manually link them to existing Veles Customer records, or create new Customer records from the Stripe data.
Reviewing unmatched customers ensures that billing data from Stripe is properly associated with the right customer accounts in Veles. Unmatched customers won't have their billing data reflected in Veles until they're linked.
***
## Products
The Products tab is where you manage the sync between your Stripe product catalog and your Veles [price book](/get-started/pricing-and-packaging/overview). This is the primary tool for importing products from Stripe and maintaining the link between the two catalogs.
### The Products table
The table shows every product in your Stripe account with the following columns:
| Column | Description |
| - | - |
| **Name** | The product name in Stripe. |
| **Description** | The product description from Stripe. |
| **Stripe ID** | The Stripe product identifier (e.g., `prod_Tij...`). |
| **Status** | **Active** or **Inactive** in Stripe. |
| **Match Status** | How the product is linked to Veles. See [Match statuses](#match-statuses). |
| **Veles Product** | The linked Veles product (if matched). Click to open the product in Veles. |
| **Created in Stripe** | When the product was created in your Stripe account. |
You can search products by name, filter columns, and trigger a manual sync with the **Sync** button. The "Last synced" timestamp shows when the product data was last refreshed.
### Match statuses
Each Stripe product has one of three match statuses:
| Status | Meaning | What to do |
| - | - | - |
| **Matched: name\_match** | Veles automatically matched this Stripe product to a Veles product by name. The link was created without manual intervention. | Verify the match is correct. If the names are similar but the products are different, unlink and rematch manually. |
| **Matched: import** | This product was imported from Stripe into Veles, creating a new Veles product from the Stripe data. | The product is fully linked. Review the imported product's pricing plan and add any Veles-specific configuration (categories, custom fields, rep permissions). |
| **Not Matched** | No Veles product is linked to this Stripe product. | Review and either match to an existing Veles product or import to create a new one. |
### Reviewing unmatched products
When unmatched products exist, a yellow alert banner appears:
> "X unmatched Stripe products need review"
Click **Review** to see the unmatched records and take action:
* **Match to existing** -- link the Stripe product to a Veles product that already exists in your price book.
* **Import** -- create a new Veles product from the Stripe data (name, SKU, pricing structure).
* **Ignore** -- leave the product unmatched if it's not relevant to quoting (e.g., internal test products, archived SKUs).
When importing products from Stripe, unit labels come in blank because Stripe doesn't have an equivalent concept. After import, update each product's [Unit of Measure](/get-started/pricing-and-packaging/units-of-measure) label in Veles (e.g., change "units" to "seats" or "API calls").
### Keeping catalogs in sync
The Products tab is not just for initial import -- it's an ongoing management tool. As you add new products in Stripe, they'll appear here as **Not Matched** on the next sync. Review and match them to keep the two catalogs aligned.
Similarly, if you change a product's name or status in Stripe, the updated data will sync to this tab. Matched products automatically reflect the changes.
***
## Subscriptions
The Subscriptions tab shows active Stripe subscriptions and their relationship to Veles [Contracts](/get-started/contract-management/overview). This tab provides visibility into the billing-side state of your customer relationships.
***
## Stripe data flow
Here's how data flows between Stripe and Veles across the deal lifecycle:
```text theme={null}
Stripe Products → Import/Match → Veles Price Book
Stripe Customers → Match/Sync → Veles Customers
↓
Quote → Order → Contract
↓
Veles Orders → Stripe Invoices
Veles Contracts → Stripe Subscriptions
```
**Inbound (Stripe → Veles):**
* Products and pricing import into the Veles price book
* Customer records sync to Veles Customer objects
* Subscription status provides billing-side context for contract management
**Outbound (Veles → Stripe):**
* Committed orders trigger invoice creation in Stripe
* Contract data drives subscription management in Stripe
* Payment status syncs back to Veles for visibility
***
## Troubleshooting
### Unmatched products keep appearing
If products you've already addressed reappear as unmatched after a sync:
1. Check that the match was saved correctly -- click the product and verify the Veles Product column shows the linked product.
2. If the product was renamed in Stripe, the name\_match may have broken. Re-match manually.
### Products showing as Inactive
Products with **Inactive** status in Stripe won't be available for matching or import until they're reactivated in your Stripe dashboard. If you need to quote an inactive Stripe product, either reactivate it in Stripe or create the product manually in Veles.
### Customer sync not running
1. Check the "Customers Last Synced" timestamp on the General tab. If it's stale, click **Sync** on the Customers tab to trigger a manual sync.
2. Verify the connection is still active (General tab shows connection details, not a "Connect" button).
3. If the API key has expired or been rotated in Stripe, click **Update API Key** to enter the new key.
### Mode mismatch
If you're not seeing expected products or customers, check the **Mode** field on the General tab. **Test** mode only syncs with Stripe's test environment. Switch to **Live** for production data.
For persistent issues, reach out to the Veles team at [**hi@getveles.com**](mailto:hi@getveles.com) with your Stripe Account ID and a description of the sync behavior.
***
## What's next
Initial connection setup and payment configuration.
Import products from Stripe or create them manually.
Configure bank accounts and payment methods for billing.
How contracts drive billing through Stripe.
# Overview
Source: https://docs.getveles.com/get-started/overview
Veles is an AI-native CPQ platform that handles pricing, quoting, orders, and contracts for B2B SaaS teams.
Veles is a Configure, Price, Quote (CPQ) platform built for modern B2B SaaS revenue teams. It manages the full lifecycle of a deal -- from product catalog and pricing logic through quoting, order execution, contract management, and renewal -- in a single system.
Veles connects your CRM (Salesforce or HubSpot), your billing system (Stripe), and your document workflows so that pricing decisions made in a quote propagate cleanly through to invoicing and revenue recognition, without manual handoffs or spreadsheet side-channels.
## What makes Veles different
**AI-native architecture.** Veles is built with an [MCP (Model Context Protocol) server](/mcp), which means AI agents and LLMs can read, create, and modify quotes, products, and pricing programmatically. Your team can build agent workflows that go from a call transcript to a finished proposal without touching the UI.
**One data model, no schema bloat.** Veles uses a compact object model with three clear stages -- Quotes, Orders, and Contracts -- so your data stays clean as deals move through the pipeline.
**Rules that actually work.** Pricing rules, validation rules, formula rules, and approval flows are all configured in-app with no code. If you're migrating from Salesforce CPQ, there's a dedicated guide for [translating your existing rules](/get-started/rules-and-approval/translating-sfdc-rules-to-veles).
## Choose your path
Set up your account, configure your product catalog, build pricing logic, and start generating quotes. The Quickstart gets you from zero to first deal.
Connect Veles to your CRM, Stripe, and other tools. Use the MCP server to build AI-powered deal workflows on top of Veles data.
## Core capabilities
### Pricing & product catalog
Define your products, pricing models (flat, tiered, volume, usage-based), currencies, and packaging. Use product categories and filters to keep large catalogs manageable for your sales team.
[Go to Pricing & Packaging →](/get-started/pricing-and-packaging/overview)
### Quoting
Build quotes with multiple pricing options, custom terms, ramp schedules, and discount logic. Share interactive quotes via a web portal, route them through approvals, and generate branded documents.
[Go to the Calculator →](/get-started/calculator/quote-options)
### Rules & approvals
Set up pricing guardrails, validation rules, formula-driven fields, and multi-step approval chains. No code required — rules are configured through the UI and enforced automatically.
[Go to Rules & Approvals →](/get-started/rules-and-approval/learn-the-basics)
### Contract management
Track active contracts as a living ledger. Handle amendments, co-termination, proration, and automated renewals with configurable uplift policies.
[Go to Contract Management →](/get-started/contract-management/overview)
### Document generation
Auto-generate proposals, order forms, and contracts from quote data using HTML/CSS templates. Output to PDF or integrate with Google Drive for e-signature workflows.
[Go to Document Generation →](/get-started/document-generation)
### Integrations
Managed package with bi-directional sync.
Native CRM integration.
Billing and payment collection.
Call recording sync.
Docs, Slides, and e-sign.
Scheduling integration.
## For developers: the Veles MCP server
Veles exposes a native [MCP server](get-started/veles-mcp) that lets AI agents and LLMs interact with your CPQ data directly. This means you can:
* **Query** products, quotes, customers, and contracts programmatically
* **Create and update** quotes, line items, and pricing options through tool calls
* **Build agent workflows** that chain Veles actions with other MCP-compatible tools (CRMs, document generators, communication platforms)
If you're building AI-powered sales workflows — like turning a Gong transcript into a draft proposal — the MCP server is where you start.
## Object Manager
For power users and admins: the [Object Manager](/object-manager/objects/customer) gives you direct access to customize the underlying data model. Define custom fields, adjust object relationships, and configure the metadata that drives Veles behavior across your instance.
# Creating a Product
Source: https://docs.getveles.com/get-started/pricing-and-packaging/creating-a-product
Full reference for creating and configuring products in Veles: pricing plans, components, tiers, lookup drivers, rep permissions, and multi-currency support.
This is the detailed reference for product configuration in Veles. It covers every option available when creating or editing a product, including advanced scenarios like multi-component pricing, formula-based pricing floors, and multi-currency plans.
**First time setting up a product?** The [Adding a Product](/get-started/quickstart/adding-a-product) guide in the Quickstart section walks through the basics and includes a Stripe import option. Start there if you just need to get your first product into the catalog.
***
## Product details
Navigate to **Admin > Price Books > Products** and click **+ New Product**.
| Field | Required | Description |
| - | - | - |
| **Name** | Yes | Display name shown in the catalog and on quotes. |
| **SKU** | Yes | Unique identifier across your entire Veles environment. Used for reporting, CRM sync, and ERP/billing integration. Duplicate SKUs are rejected at save. |
| **Category** | No | Assigns the product to a [Product Category](/get-started/pricing-and-packaging/product-categories) for catalog organization and reporting. |
| **Description** | No | Internal notes or customer-facing details. This text does not appear on quotes unless you configure it to via document templates. |
| **Custom fields** | No | Metadata tags like Region, Segment, or Vertical. These drive [Product Filters](/get-started/pricing-and-packaging/product-filters) (controlling which reps see the product) and carry through to quote lines for downstream reporting. |
| **Status** | Toggle | **Active** products are visible in the catalog and available during quoting. **Inactive** products are hidden from reps but preserved in the system for historical reporting. |
Click **Save**. You'll land on the Product Details page where you can add pricing plans.
***
## Pricing plans
A pricing plan defines how a product is priced and sold. Every product needs at least one pricing plan to be quotable. Click **Add Pricing Plan** from the Product Details page.
### Plan-level settings
**Currency:** The currency for this pricing plan. If you sell in multiple currencies, create a separate pricing plan for each. For example, a product might have a USD plan and a EUR plan, each with their own tier structure. See [Adding Currencies](/get-started/pricing-and-packaging/adding-currencies).
**Payment type:**
* **Recurring** -- billed on a repeating schedule (annual, monthly, quarterly). Used for SaaS licenses, subscriptions, and ongoing services.
* **One-time** -- billed once at the time of the transaction. Used for implementation fees, setup costs, and one-off services.
**Pricing floor** (optional): Sets the minimum price for the product, preventing reps from discounting below a threshold. You can define the floor as:
* **Fixed amount** -- a hard dollar value (e.g., \$1,000 minimum).
* **Formula** -- a calculated floor based on other variables (e.g., cost-plus margin, or a percentage of list price). Formulas can reference [Data Sheets](/get-started/pricing-and-packaging/data-sheets) for dynamic floor calculations.
***
## Components
A pricing plan is built from one or more **components**. Each component has its own name, pricing method, and tier structure. The final price is the sum of all components.
**Single-component products** (most common): A product with one pricing dimension. For example, a SaaS license priced per seat. Name the component (e.g., "Base License"), select a pricing method, and configure tiers.
**Multi-component products**: A product with multiple pricing dimensions that add together. For example:
* Component 1: "Platform Fee" -- a flat \$500/month base
* Component 2: "Per-Seat License" -- \$25/user/month using volume pricing
* Component 3: "Premium Support" -- 10% of the total using Percentage Of
The rep sees the combined price on the quote line. Each component calculates independently and the results are summed.
Multi-component pricing is powerful but adds complexity. Use it when a product genuinely has multiple independent pricing dimensions. If you're just applying a discount or surcharge, a [Pricing Rule](/get-started/rules-and-approval/pricing-rules) is usually simpler.
***
## Pricing methods
Each component requires a pricing method. These determine how the price is calculated from the rep's inputs.
| Method | Calculation | Best for |
| - | - | - |
| **Flat Fee** | Fixed price. Quantity defaults to 1. | Implementation fees, one-time services. |
| **Volume Lookup** | All units at the tier reached. Rate x total quantity. | Per-seat licensing. |
| **Graduated Lookup** | Units priced progressively by tier. Sum of each tier. | Usage-based billing, consumption models. |
| **Stair-step Lookup** | Fixed fee per range. No per-unit multiplication. | Platform packages, bucket pricing. |
| **Percentage Of** | % of other line items in the same pricing option. | Support plans, success fees. |
For detailed explanations with worked numerical examples for each method, see [Pricing Models](/get-started/pricing-and-packaging/pricing-models).
### Percentage Of: advanced options
The Percentage Of method has two additional settings:
**Tiered percentages:** Instead of a single flat percentage, you can define tiers. For example, 10% on the first $100k of deal value and 7% on anything above $100k.
**ARR-only calculation:** Toggle this to calculate the percentage against recurring line items only, excluding one-time fees. This is commonly used for support plans where the fee should be a percentage of ARR, not the total deal value including implementation.
***
## Lookup drivers
The **lookup driver** determines what input value drives the pricing calculation. This is the "x" in "price per x."
**Quantity** (default): The number of units the rep enters. Use this for standard per-seat, per-license, or per-unit products.
**Custom drivers**: For transactional or consumption-based products where the pricing input isn't a simple unit count. Examples:
* "Transaction Value" -- the dollar amount of transactions processed, used to determine a per-transaction rate
* "Annualized Construction Volume" -- a customer metric that drives tiered pricing
* "Credit Consumption" -- estimated API or compute credits
With custom drivers, the driver value determines the rate, but the quantity on the order is typically fixed at **1** (representing one instance of the SKU).
When using custom pricing drivers, set **Quantity Editable** to off and default the quantity to **1**. The driver determines the price; the quantity represents the SKU count on the order, not the consumption volume.
### Input scale
Input scale simplifies data entry for reps working with large numbers. Options: **Singles**, **Hundreds**, **Thousands**, **Millions**.
When set to "Millions," a rep enters `42.5` and Veles interprets it as 42,500,000. This reduces data entry errors on high-volume consumption products.
***
## Pricing tiers
For Volume, Graduated, and Stair-step pricing methods, you define tiers using the boundary table.
### How boundaries work
Veles uses **upper boundaries** to define tier ranges. Each tier covers the range from the previous tier's upper boundary to its own.
| Tier | Upper boundary | Price |
| - | - | - |
| 1 | 5 | \$50/unit |
| 2 | 10 | \$40/unit |
| 3 | 25 | \$30/unit |
| 4 | ∞ (unlimited) | \$20/unit |
In this example: 0-5 units are Tier 1, 6-10 are Tier 2, 11-25 are Tier 3, and 26+ are Tier 4.
### Live calculation preview
As you build the tier table, Veles shows a live preview of the calculated price for a given input. Use this to verify your tier structure produces the expected results before saving.
### Editing tiers on live products
You can edit a product's tier structure after it's live. Changes apply to new quotes only -- existing quotes that already include the product retain the pricing from when the line item was added.
***
## Rep permissions
At the bottom of each pricing plan, toggle the permissions that control what reps can modify when they add this product to a quote.
### List Price Editable
When ON, reps can manually override the calculated list price with a custom value.
Use this sparingly -- it's designed for legacy SKUs without standardized pricing or new products that haven't been fully priced yet. When a rep manually edits the list price, automatic calculations are overridden. To recalculate pricing after a quantity change, the rep must clear the List Price field first.
### Disable Discounting
When ON, reps cannot apply discretionary discounts to this product. Only automated [Pricing Rules](/get-started/rules-and-approval/pricing-rules) or promotions will affect the price. Use this for products with non-negotiable pricing (e.g., regulated fees, pass-through costs).
### Name Editable
When ON, reps can rename the product on customer-facing documents. The underlying SKU and system name remain unchanged for reporting and CRM sync purposes.
Renamed products revert to their original system name when synced to a CRM or Stripe. The custom name only appears in Veles-generated documents and the buyer web portal.
### Quantity Editable
When ON, reps can change the unit count even if a default quantity was set on the product. When OFF, the quantity is locked to the default value.
### Transactional
Marks the product as billed in arrears (e.g., a percentage of transaction volume processed). Transactional products are:
* Excluded from **Total ARR** calculations on the quote
* Displayed as a **rate** to the buyer (not a fixed total)
* Typically used for revenue-share or consumption-based line items where the final amount is determined post-close
***
## Managing existing products
### Editing a product
Navigate to **Admin > Price Books > Products**, select the product, and click **Edit** on the Product Details page. You can update any field: name, SKU, category, custom fields, description, or status.
Changes to product metadata (name, category, custom fields) take effect immediately across the platform. Changes to pricing plans affect new quotes only -- existing quotes retain their original pricing.
### Multi-currency products
To support international pricing, add multiple pricing plans to a single product, one per currency. Each plan has its own tier structure and pricing logic, allowing you to set region-appropriate pricing rather than relying on currency conversion.
Navigate to the Product Details page and click **Add Pricing Plan** again. Select the new currency and configure the plan independently.
### Deactivating a product
Set the product's Status to **Inactive** to remove it from the catalog. Inactive products are hidden from reps during quoting but remain in the system. Existing quotes and contracts that reference the product are unaffected.
To reactivate, set the Status back to **Active**.
***
## How products connect to other price book elements
Products don't exist in isolation. Here's how they interact with the other components in your price book:
[**Categories**](/get-started/pricing-and-packaging/product-categories) organize products for catalog navigation and can be used as criteria in pricing rules (e.g., "require a shipping fee when a Hardware product is added").
[**Custom fields and filters**](/get-started/pricing-and-packaging/product-filters) control which reps see which products, and carry metadata through to quote lines for reporting.
[**Units of Measure**](/get-started/pricing-and-packaging/units-of-measure) define the label for what's being counted (e.g., "Per User", "Per GB"). UOMs can be shared across a category or unique to a single product.
[**Data Sheets**](/get-started/pricing-and-packaging/data-sheets) provide reference data that pricing formulas and floors can look up at calculation time (e.g., a regional pricing matrix).
[**Deal Components**](/get-started/pricing-and-packaging/deal-components) define the billing frequencies available for the product and carry contextual data to quote lines.
[**Rules**](/get-started/rules-and-approval/learn-the-basics) enforce guardrails: validation rules prevent invalid configurations, pricing rules adjust calculations automatically, and approval rules route quotes for review based on discount thresholds or product combinations.
***
## What's next
Detailed breakdown of each pricing method with worked examples.
Organize your catalog before building out your full price book.
Upload reference data for dynamic pricing lookups and formulas.
Set up the guardrails that govern how reps quote these products.
# Data Sheets
Source: https://docs.getveles.com/get-started/pricing-and-packaging/data-sheets
Upload reference tables that the Veles pricing engine can query at quoting time for dynamic pricing, discounts, and validation logic.
Data Sheets are reference tables that the Veles pricing engine queries in real time during quoting. They work like spreadsheet tabs -- rows and columns of data that you upload once and reference across your pricing formulas, pricing floors, and rules.
Use Data Sheets when your pricing logic depends on external data that doesn't belong hard-coded on a single product. Instead of embedding every pricing variation into individual product configurations, you centralize the data in one place and let the engine look it up.
***
## When to use Data Sheets
Data Sheets are the right tool when:
* Pricing varies by a dimension that isn't the quantity (e.g., geography, customer tier, ERP system, industry vertical)
* Discount thresholds differ across customer segments and you need the rules engine to validate them
* You have a matrix of values that would be impractical to maintain as individual product configurations
* The same reference data is used across multiple products or rules
If the pricing logic is straightforward (flat fee, standard per-unit tiers), you don't need a Data Sheet -- the product's pricing plan handles that directly.
***
## How Data Sheets work
Every Data Sheet has a unique **name** that acts as its identifier. Pricing formulas and rules reference this name to look up specific values based on inputs provided during quoting.
**The flow:**
1. A rep selects a product and enters inputs (quantity, a dropdown selection, a custom field value).
2. The pricing engine evaluates the product's formula and encounters a Data Sheet reference.
3. The engine queries the Data Sheet, matching the rep's input against a column to find the corresponding value.
4. The returned value is used in the calculation (as a multiplier, a rate, a discount threshold, etc.).
This all happens instantly -- the rep sees the calculated price in real time.
***
## Creating a Data Sheet
1. Navigate to **Admin > Price Books > Data Sheets**.
2. Click **+ New Data Sheet**.
3. **Name your sheet.** Use a clear, concise name with underscores instead of spaces (e.g., `ERP_Uplift`, `Regional_Pricing_2026`, `Discount_Thresholds`). This name is how you'll reference the sheet in formulas and rules.
4. **Build your table:**
* Add columns to define your data points.
* Enter data manually or **paste directly from a spreadsheet** (Excel or Google Sheets copy-paste is supported).
5. Click **Save**.
The data is immediately available for use in the formula builder and rules engine.
***
## Use cases
### Dynamic pricing adjustments
You have an uplift fee based on which ERP system your customer uses.
**Data Sheet:** `ERP_Uplift`
| ERP\_Type | Uplift\_Percentage |
| - | - |
| SAP | 15% |
| Oracle | 12% |
| NetSuite | 5% |
| Other | 0% |
**How it's used:** In the product's pricing formula, you tell Veles: "If the rep selects 'SAP' from the dropdown, look up the `ERP_Uplift` sheet and multiply the base price by 1.15."
When the uplift for SAP changes from 15% to 20%, you update the Data Sheet once. Every product referencing it picks up the change automatically.
### Regional pricing matrices
You sell at different price points depending on the customer's geography.
**Data Sheet:** `Regional_Pricing`
| Region | Base\_Rate | Support\_Rate |
| - | - | - |
| North America | \$50 | \$5 |
| EMEA | €45 | €4.50 |
| APAC | \$40 | \$4 |
| LATAM | \$35 | \$3.50 |
**How it's used:** A pricing formula references `Regional_Pricing` and uses the rep's selected region to look up the base rate, replacing a hard-coded price with a dynamic one. This lets you maintain a single product SKU with region-specific pricing rather than creating separate products per region.
### Discount thresholds by customer tier
Your discount policy varies by customer segment, and you need the approval engine to enforce it.
**Data Sheet:** `Discount_Thresholds`
| Segment | Max\_Discount\_Percent | Approval\_Required\_Above |
| - | - | - |
| Enterprise | 25% | 15% |
| Mid-Market | 20% | 10% |
| SMB | 15% | 5% |
**How it's used:** A [Validation Rule](/get-started/rules-and-approval/quote-validation) references this sheet to check whether a rep's discount exceeds the maximum for the customer's segment. An [Approval Rule](/get-started/calculator/approvals) triggers manager review when the discount exceeds the "Approval Required Above" threshold.
### Pricing floors from external data
You need minimum prices that vary by product and region.
**Data Sheet:** `Pricing_Floors`
| SKU | Region | Min\_Price |
| - | - | - |
| PLATFORM-001 | North America | \$10,000 |
| PLATFORM-001 | EMEA | €8,500 |
| ANALYTICS-001 | North America | \$3,000 |
| ANALYTICS-001 | EMEA | €2,500 |
**How it's used:** A product's [pricing floor](/get-started/pricing-and-packaging/creating-a-product#pricing-plans) is configured as a formula that looks up this Data Sheet by SKU and region, returning the appropriate minimum price dynamically.
***
## Referencing Data Sheets in formulas
Data Sheets are referenced by name in the formula builder. The exact syntax depends on the context (pricing formula, pricing floor, or rule), but the pattern is the same: specify the sheet name, the lookup column, the lookup value, and the return column.
For example, to look up the uplift percentage for a selected ERP type:
```text theme={null}
LOOKUP("ERP_Uplift", "ERP_Type", [selected_erp], "Uplift_Percentage")
```
The formula builder provides autocomplete for available Data Sheet names and column headers.
Use the live calculation preview on the pricing plan to test your Data Sheet lookups before saving. Enter different inputs and verify that the correct values are returned.
***
## Managing Data Sheets
### Editing data
Navigate to **Admin > Price Books > Data Sheets** and select the sheet. Edit values directly in the grid, add or remove rows, or paste updated data from a spreadsheet. Click **Save** and the changes take effect immediately.
Changes apply to new quotes and any quote that recalculates pricing. Existing quotes with locked line items retain their original values.
### Adding columns
You can add new columns to an existing Data Sheet at any time. Existing formulas that reference the sheet aren't affected -- they only look up the columns they're configured to use.
### Deleting a Data Sheet
Remove the sheet from **Admin > Price Books > Data Sheets**. Any formulas or rules that reference the deleted sheet will fail to resolve, so review dependencies before deleting.
Before deleting a Data Sheet, search your pricing formulas and rules for references to its name. Broken references will cause pricing calculation errors during quoting.
***
## Best practices
**Use underscores in names.** Names like `Regional_Pricing_2026` are easier to reference in formulas than names with spaces. Avoid special characters.
**Centralize logic, don't duplicate it.** If multiple products reference the same uplift or discount data, use one Data Sheet. This ensures a single update propagates everywhere.
**Version by year if rates change annually.** If your pricing matrix changes each fiscal year, name sheets with the year (e.g., `Discount_Thresholds_2026`) so you can maintain the old sheet for reference while switching formulas to the new one.
**Keep sheets focused.** A sheet called `Everything` with 50 columns is harder to maintain than three focused sheets. Organize by use case: one for regional pricing, one for discount thresholds, one for uplift fees.
***
## What's next
Reference Data Sheet values in pricing rules and validation logic.
Use Data Sheets in pricing formulas and pricing floors.
Build formula-driven fields that query Data Sheets dynamically.
Configure billing frequencies and contextual data for products.
# Pricing & Packaging
Source: https://docs.getveles.com/get-started/pricing-and-packaging/overview
Understand the building blocks of your Veles price book: products, pricing models, categories, rules, data sheets, and more.
The price book is the foundation of everything in Veles. It defines what you sell, how it's priced, and the guardrails that keep your team quoting accurately. Every quote your reps build pulls from this configuration, so getting it right here means cleaner deals downstream.
Your price book is managed in the Admin Console under **Admin > Price Books** and is composed of six core elements. You don't need to configure all six to get started -- products and pricing models are the minimum. The rest add structure, flexibility, and automation as your catalog and deal complexity grow.
**New to Veles?** If you're setting up your price book for the first time, start with the [Adding a Product](/get-started/quickstart/adding-a-product) guide in the Quickstart section. It walks you through creating your first product and pricing plan step by step.
***
## Products
Products are the individual SKUs in your catalog. Each product has a name, a unique SKU, and one or more pricing plans that define how it's sold.
A product on its own is just metadata. The pricing plan is where the real logic lives -- it defines the currency, payment type (recurring or one-time), pricing method (flat, tiered, volume, etc.), and the rep permissions that control what salespeople can modify during quoting.
| Attribute | Required | Purpose |
| - | - | - |
| **Name** | Yes | Display name in the catalog and on quotes. |
| **SKU** | Yes | Unique identifier used for reporting, CRM sync, and ERP integration. |
| **Category** | No | Groups the product for catalog navigation and reporting. |
| **Description** | No | Internal notes or customer-facing context. |
| **Custom fields** | No | Tags like Region, Segment, or Vertical used for filtering and reporting. |
| **Status** | Toggle | Active products are visible to reps. Inactive products are hidden. |
[Creating a Product →](/get-started/pricing-and-packaging/creating-a-product)
***
## Pricing models
The pricing model determines how Veles calculates the price for a product based on the inputs a rep provides (typically quantity). Veles supports five methods:
| Method | How it works | Common use case |
| - | - | - |
| **Flat Fee** | Fixed price, no quantity math. | Implementation fees, one-time services. |
| **Volume Lookup** | All units priced at the tier reached. | Per-seat SaaS licensing. |
| **Graduated Lookup** | Units priced progressively by tier (like tax brackets). | Usage-based billing. |
| **Stair-step Lookup** | Flat fee per range, regardless of exact quantity. | Platform packages (e.g., 0-50 employees). |
| **Percentage Of** | Price as a % of other line items in the quote. | Support plans, success fees. |
Each pricing model is configured on the product's pricing plan. You can combine multiple components within a single plan (e.g., a base license fee plus a percentage-based support fee).
[Pricing Models →](/get-started/pricing-and-packaging/pricing-models)
***
## Categories
Categories group products into logical families, similar to Product Families in Salesforce. They control how products are organized in the quoting interface and how revenue is reported by product line.
Common categories include "SaaS Subscriptions", "Professional Services", "Hardware", and "Add-ons". When a rep opens the product catalog during quoting, categories appear as filters so they can narrow down a large price book quickly.
Categories also serve as criteria for [Rules](/get-started/rules-and-approval/learn-the-basics). For example, you could create a rule that requires a "Shipping" fee whenever a product from the "Hardware" category is added to a quote.
Create your category structure before importing or creating products. It's easier to assign categories during product setup than to go back and organize later.
[Product Categories →](/get-started/pricing-and-packaging/product-categories)
***
## Units of Measure
Units of Measure (UOM) define the input that drives pricing -- what exactly is being counted when a rep enters a quantity.
For most products, this is straightforward: "Per User", "Per Seat", or "Per License." But for consumption-based or usage-based products, you might define units like "Per GB", "Per 1,000 API Calls", or "Per Million Transactions."
Veles gives you two options for managing units:
* **Shared UOMs** apply a single measure across an entire product category (e.g., every product in "SaaS Subscriptions" is measured "Per User").
* **Unique UOMs** define a specialized measure for a single product (e.g., a storage product measured "Per GB").
[Units of Measure →](/get-started/pricing-and-packaging/units-of-measure)
***
## Data Sheets
Data Sheets are reference tables that the Veles pricing engine can query at quoting time. They work like spreadsheet tabs -- rows and columns of data that you upload once and reference across your pricing formulas and rules.
Use Data Sheets when your pricing logic depends on external data that doesn't belong on the product itself. For example:
* A **regional pricing matrix** that adjusts list price based on the customer's geography.
* An **ERP uplift table** that applies different multipliers depending on which system the customer runs (e.g., SAP = 15%, Oracle = 12%, NetSuite = 5%).
* A **discount threshold table** that maps customer tiers to maximum allowable discounts.
Data Sheets support copy-paste from Excel or Google Sheets, and once saved, they're immediately available in the formula builder and rules engine. When a value changes (e.g., the SAP uplift moves from 15% to 20%), you update the Data Sheet in one place and every product referencing it picks up the change automatically.
[Data Sheets →](/get-started/pricing-and-packaging/data-sheets)
***
## Deal Components
Deal Components control the transactional parameters of how a product is sold -- the settings that sit alongside the price itself.
**Billing frequencies** define which payment schedules a rep is authorized to offer for a given product. For example, you might allow Monthly, Quarterly, and Annual billing on a SaaS license but restrict a Professional Services fee to a single upfront payment.
**Contextual data** carries custom field values from the product level directly to quote lines. This is useful for downstream reporting -- if a product is tagged with a specific region or vertical, that metadata flows through to the quote line so you can slice revenue data by those dimensions later.
[Deal Components →](/get-started/pricing-and-packaging/deal-components)
***
## Product Filters & Custom Fields
Filters and custom fields work together to control which products a rep sees during quoting.
**Custom fields** are metadata tags you define on products -- things like Region, Segment, or Vertical. They serve two purposes: filtering the catalog for reps and providing reporting dimensions on quote lines.
**Product filters** use those custom fields (along with categories) to scope the catalog view. When a rep assigned to "Enterprise" and "North America" opens the product catalog, they only see products tagged with those values. This keeps large catalogs manageable and prevents reps from quoting products outside their territory.
[Product Custom Fields →](/get-started/pricing-and-packaging/product) · [Product Filters →](/get-started/pricing-and-packaging/product-filters)
***
## Multi-currency support
Veles supports pricing in multiple currencies. Your base currency is set during account setup (determined by your company's country), and you can add additional currencies to support international deals. Each product's pricing plan specifies a currency, and you can create multiple pricing plans on the same product for different currencies.
[Adding Currencies →](/get-started/pricing-and-packaging/adding-currencies)
***
## How these pieces connect
Here's how the components work together when a rep builds a quote:
1. The rep opens the product catalog, filtered by their assigned **categories**, **regions**, and **segments** (via **filters** and **custom fields**).
2. They select a product. The product's **pricing plan** determines the **pricing model** and the available **billing frequencies** (via **deal components**).
3. The rep enters a quantity using the product's **unit of measure**.
4. The pricing engine calculates the price, referencing **data sheets** for any lookup-driven logic and applying **rules** for validation, discounts, and approvals.
5. The calculated line item, with all its metadata, is added to the quote.
The rest of this section covers each component in detail. If you're setting up from scratch, we recommend working through them roughly in this order: Products → Categories → Pricing Models → Units of Measure → Deal Components → Data Sheets → Rules.
***
## All pages in this section
Create products manually and configure pricing plans.
Organize your catalog into logical product families.
Control which products reps see based on segment and region.
Add metadata to products for filtering and reporting.
Understand flat, volume, graduated, stair-step, and percentage pricing.
Configure multi-currency support for international deals.
Upload reference data for dynamic pricing lookups.
Configure billing frequencies and contextual data.
Define the inputs that drive your pricing calculations.
# Pricing Models
Source: https://docs.getveles.com/get-started/pricing-and-packaging/pricing-models
Understand how each pricing method in Veles calculates price from quantity: flat fee, volume, graduated, stair-step, and percentage of.
When you configure a [pricing plan](/get-started/pricing-and-packaging/creating-a-product#pricing-plans) for a product, each component requires a **pricing method**. The pricing method determines how Veles calculates the final price based on the inputs a rep provides during quoting.
Veles supports five pricing methods. Each works differently, and choosing the right one depends on how you sell the product.
***
## Flat Fee
A single fixed price regardless of quantity. The quantity defaults to 1 -- the product is either included in the quote or it isn't.
**Best for:** Implementation fees, one-time services, fixed-price add-ons, setup costs.
**How it works:** No calculation. The price is the price.
**Example:** A "Standard Implementation" product is set to a flat fee of $5,000. No matter what else is on the quote, the implementation line item is always $5,000.
***
## Volume Lookup
A single rate is applied to the **entire quantity** based on which tier that quantity falls into. All units are priced at the same rate.
**Best for:** Per-seat SaaS licensing, per-unit pricing, ACV-based models.
**How it works:** Veles identifies which tier the total quantity falls into, then multiplies the entire quantity by that tier's rate.
**Example:**
| Tier | Range | Rate |
| - | - | - |
| 1 | 0 - 5 | \$50/unit |
| 2 | 6 - 10 | \$40/unit |
| 3 | 11 - 25 | \$30/unit |
If a rep enters a quantity of **8**:
* 8 falls into Tier 2
* Total = $40 x 8 = **$320\*\*
All 8 units are priced at the Tier 2 rate. The Tier 1 rate is never applied.
Volume pricing creates natural price breaks that incentivize larger deals. A rep can show a buyer that going from 5 seats ($250) to 6 seats ($240) actually costs less -- a useful negotiation lever.
***
## Graduated Lookup
Units are priced **progressively** based on the tier they fall into, like tax brackets. Each tier's units are priced at that tier's rate, and the results are summed.
**Best for:** Usage-based billing, consumption models, utility-style pricing.
**How it works:** Every unit between a tier's lower and upper boundary is multiplied by that tier's rate. The totals from all tiers are added together.
**Example:**
| Tier | Range | Rate |
| - | - | - |
| 1 | 0 - 5 | \$50/unit |
| 2 | 6 - 10 | \$40/unit |
| 3 | 11 - 25 | \$30/unit |
If a rep enters a quantity of **8**:
* First 5 units at Tier 1: 5 x $50 = $250
* Remaining 3 units at Tier 2: 3 x $40 = $120
* Total = $250 + $120 = **\$370**
Compare this to Volume pricing, which would charge \$320 for the same quantity. Graduated pricing always produces a higher total because lower tiers are never discounted retroactively.
### Volume vs. Graduated: when to use which
| | Volume | Graduated |
| - | - | - |
| **Price at 8 units** | $320 (all at $ 40) | $370 (5 at $ 50 + 3 at \$40) |
| **Price break behavior** | Dramatic -- crossing a tier reprices everything | Smooth -- each additional unit is priced at its own tier |
| **Best for** | SaaS seats where you want to reward larger commits | Usage billing where incremental cost should decrease gradually |
***
## Stair-step Lookup
A **fixed dollar amount** for anything that falls within a tier's range, regardless of the exact quantity. There is no per-unit multiplication.
**Best for:** Platform packages, bucket pricing (e.g., "0-50 employees" plan), tiered flat-rate plans.
**How it works:** If the input falls within the tier boundaries, the flat price for that tier is applied. The quantity doesn't affect the calculation within a tier.
**Example:**
| Tier | Range | Price |
| - | - | - |
| 1 | 0 - 5 units | \$500 |
| 2 | 6 - 10 units | \$800 |
| 3 | 11 - 25 units | \$1,200 |
* A quantity of **4** costs **\$500**
* A quantity of **5** costs **\$500**
* A quantity of **6** costs **\$800**
* A quantity of **9** costs **\$800**
The price only changes when the quantity crosses a tier boundary.
Stair-step pricing is ideal for products where you sell capacity in buckets rather than individual units. Think "up to 50 employees" vs. "per employee."
***
## Percentage Of
Price is calculated as a **percentage of the value of other products** included in the same pricing option.
**Best for:** Support plans, success fees, platform fees, revenue-share line items.
**How it works:** Veles sums the value of the other line items in the pricing option and applies the configured percentage.
**Example:**
| Other line items | Value |
| - | - |
| Core Platform License | \$80,000 |
| Analytics Add-on | \$20,000 |
| **Total** | **\$100,000** |
A "Premium Support" product configured as 10% of total = **\$10,000**.
The final deal value including support = \$110,000.
### Tiered percentages
Instead of a single flat percentage, you can define tiers that apply different rates based on the total value of other line items.
**Example:**
| Tier | Deal value range | Rate |
| - | - | - |
| 1 | $0 - $ 100,000 | 10% |
| 2 | \$100,001+ | 7% |
On a $150,000 deal: the first $100,000 is at 10% ($10,000) and the remaining $50,000 is at 7% ($3,500). Total support fee = **$13,500\*\*.
### ARR-only calculation
Toggle this option to calculate the percentage against **recurring line items only**, excluding one-time fees.
**Example:** A deal includes $100,000 in recurring licenses and $25,000 in one-time implementation. With ARR-only enabled, a 10% support fee is calculated on $100,000 (= $10,000), not on $125,000 (= $12,500).
This is commonly used for support plans where the fee should scale with recurring revenue, not total deal value.
***
## Comparison at a glance
| Method | Pricing basis | Per-unit math? | Best use case |
| - | - | - | - |
| **Flat Fee** | Single fixed price | No | Implementation, setup fees |
| **Volume** | Rate x total quantity (single tier) | Yes | SaaS per-seat licensing |
| **Graduated** | Sum of rate x units per tier | Yes | Usage-based billing |
| **Stair-step** | Fixed fee per range | No | Platform packages, buckets |
| **Percentage Of** | % of other line items | No | Support plans, success fees |
***
## Lookup drivers and input scale
Pricing methods that use tiers (Volume, Graduated, Stair-step) rely on a **lookup driver** to determine which tier applies.
**Quantity** (default): The number of units the rep enters. Use this for standard per-seat or per-unit products.
**Custom drivers**: For products where pricing is driven by a metric other than unit count -- like transaction value, construction volume, or credit consumption. The driver value determines the tier and rate, while the order quantity is typically fixed at 1.
**Input scale** simplifies data entry for large numbers. Set it to Singles, Hundreds, Thousands, or Millions so a rep can enter `42.5` instead of `42,500,000`. The scale is applied before tier evaluation.
For full details on configuring lookup drivers and input scale, see [Creating a Product](/get-started/pricing-and-packaging/creating-a-product#lookup-drivers).
***
## Pricing tiers: how boundaries work
For Volume, Graduated, and Stair-step methods, you define tiers using the **boundary table** in the pricing plan. Veles uses **upper boundaries** to set ranges.
| Tier | Upper boundary | Price |
| - | - | - |
| 1 | 5 | \$50/unit |
| 2 | 10 | \$40/unit |
| 3 | 25 | \$30/unit |
| 4 | ∞ (unlimited) | \$20/unit |
This means: 0-5 is Tier 1, 6-10 is Tier 2, 11-25 is Tier 3, and 26+ is Tier 4.
Veles shows a **live calculation preview** as you build the tier table, so you can verify the math before saving. Changes to tiers on a live product apply to new quotes only -- existing quotes retain their original pricing.
***
## What's next
Configure pricing plans, components, and rep permissions on your products.
Upload reference data for dynamic pricing lookups and formulas.
Apply automatic price adjustments based on deal conditions.
Define what's being counted: seats, API calls, GB, or custom units.
# Product Custom Fields
Source: https://docs.getveles.com/get-started/pricing-and-packaging/product
Add custom fields to products through the Object Explorer -- create them manually in Veles or pull them in from your CRM.
Custom fields let you extend the Product object with your own data beyond the built-in fields. Use them to tag products with metadata like cost basis, vertical, deal type, or any dimension your team needs for filtering, reporting, or pricing logic.
Custom fields are managed in the **Object Explorer**, which is the central place to view and extend the data model across all Veles objects.
***
## Built-in fields
Every product in Veles comes with these fields out of the box. Built-in fields cannot be edited or removed.
| Name | Key | Type | Description |
| - | - | - | - |
| **Name** | `name` | Text | The display name of the product. |
| **SKU** | `sku` | Text | Stock keeping unit identifier. Must be unique across your environment. |
| **Active** | `active` | Boolean | Whether the product is available for use in quotes. |
| **Description** | `description` | Text | Rich text description of the product. |
| **Category** | `product_category_id` | Reference | The [Product Category](/get-started/pricing-and-packaging/product-categories) this product belongs to. |
| **External ID** | `external_id` | Text | Identifier from an external system such as a CRM. Used to maintain the link between Veles and your CRM records. |
| **Regions** | `region_ids` | Array | Regions this product is available in. Used by [Product Filters](/get-started/pricing-and-packaging/product-filters) to control catalog visibility. |
| **Segments** | `segment_ids` | Array | Segments this product is available in. Used by [Product Filters](/get-started/pricing-and-packaging/product-filters) to control catalog visibility. |
These built-in fields cover the core product attributes. Custom fields extend the model for anything specific to your business.
***
## Adding custom fields
Navigate to **Pricebook > Object Explorer** and select **Product** from the sidebar. You'll see the built-in fields table and, below it, the **Custom Fields** section.
Click **Add Custom Field** and configure:
| Setting | Description |
| - | - |
| **Name** | The display label for the field (e.g., "Cost per User", "Target Vertical", "Implementation Tier"). |
| **Key** | The system identifier used in formulas, rules, and API references. Use lowercase with no spaces (e.g., `costperuser`, `target_vertical`). |
| **Kind** | The data type: **Text**, **Number**, **Boolean**, **Array**, or other supported types. Choose the type that matches the data you're storing. |
Click **Save** and the field is immediately available on every product in your catalog.
### Editing and deleting custom fields
Custom fields can be edited or deleted from the Object Explorer. Click **Edit** to update the name, key, or kind, or **Delete** to remove the field entirely.
Deleting a custom field removes its value from all products and any [Product Filters](/get-started/pricing-and-packaging/product-filters) or [Rules](/get-started/rules-and-approval/learn-the-basics) that reference it may stop working. Review dependencies before deleting.
***
## Pulling fields from your CRM
If you've connected a CRM ([Salesforce](/get-started/quickstart/connect-your-crm) or [HubSpot](/get-started/quickstart/connect-your-crm)), you can pull custom fields from your CRM into Veles rather than recreating them manually. This is managed through the **CRM Proposal Fields** section in the Object Explorer sidebar.
CRM-sourced fields stay synced with your CRM, so data entered or updated in Salesforce or HubSpot flows into Veles automatically. This is especially useful for fields that are already maintained by your CRM admin (e.g., product line, cost center, revenue type) -- pulling them in avoids double data entry and keeps a single source of truth.
Use CRM-sourced fields when the data already exists and is maintained in your CRM. Use manually created custom fields when the data is specific to Veles and doesn't need to live anywhere else (e.g., a pricing-specific cost basis or a Veles-only product tier).
***
## How custom fields are used
Custom fields on products flow through the platform in several ways:
### Filtering
Custom fields are the product-side target for [Product Filters](/get-started/pricing-and-packaging/product-filters). When you create a filter, you match a source field (from the user's profile or CRM) against a product field. Custom fields give you the product-side dimensions to match against.
For example, if you add a "Vertical" custom field to products and tag each product with its target industry, you can create a filter that matches the rep's assigned vertical against the product's vertical -- so a Healthcare rep only sees Healthcare products.
### Reporting
Custom field values carry through to quote lines when a product is added to a quote. This means you can slice deal data by any custom dimension you define. For example, a "Cost per User" number field lets you report on margin by comparing the quoted price against the cost basis.
### Rules and formulas
Custom fields can be referenced in [Pricing Rules](/get-started/rules-and-approval/pricing-rules), [Validation Rules](/get-started/rules-and-approval/quote-validation), and [Formula Rules](/get-started/rules-and-approval/formula-rules). For example, a pricing rule might reference a product's "Implementation Tier" field to automatically adjust the implementation fee based on the product's complexity level.
### Deal Components
Custom field values can flow from the product to the quote line via [Deal Components](/get-started/pricing-and-packaging/deal-components), carrying contextual metadata through the deal lifecycle for downstream reporting and billing.
***
## The Object Explorer
The Object Explorer isn't limited to products. It's the central place to view and extend the data model across all Veles objects. The sidebar includes:
* **Company** -- customer account fields
* **CRM Proposal Fields** -- fields pulled from your CRM for use in proposals
* **Product** -- product catalog fields (this page)
* **Option** -- pricing option fields
* **Quote Line** -- line item fields on quotes
* **User** -- user profile fields
The same pattern applies to all objects: built-in fields are fixed, and you can add custom fields to extend any object. This gives your team full control over the data model without requiring developer intervention.
For more on the Object Explorer, see the [Object Manager](/object-manager/objects/customer) documentation.
***
## What's next
Use custom fields as the product-side target for catalog visibility filters.
Full reference for product setup, including assigning custom field values.
Reference custom fields in pricing, validation, and approval rules.
Set up CRM sync to pull fields into Veles automatically.
# Product Categories
Source: https://docs.getveles.com/get-started/pricing-and-packaging/product-categories
Organize your product catalog into logical groups that control catalog navigation, reporting, and rule logic.
Categories group your products into logical families. They work like Product Families in Salesforce or Product Types in HubSpot -- simple labels that control how products are organized, filtered, and reported on across Veles.
Categories serve three purposes:
1. **Catalog navigation.** When a rep opens the product catalog during quoting, categories appear as filters so they can quickly find the right products without scrolling through the full price book.
2. **Reporting.** Categories let leadership slice revenue data by product line (e.g., total ARR from "SaaS Subscriptions" vs. "Professional Services").
3. **Rule criteria.** Categories can be used as conditions in [Pricing Rules](/get-started/rules-and-approval/pricing-rules) and [Validation Rules](/get-started/rules-and-approval/quote-validation). For example, you could create a rule that automatically adds a "Shipping" fee whenever a product from the "Hardware" category is included in a quote.
Create your category structure before importing or building products. Assigning categories during product setup is faster than going back to edit each product later.
***
## Creating a category
1. Navigate to **Admin > Price Books > Categories**.
2. Click **+ New Category**.
3. Enter a **name** for the category. Use clear, descriptive names that your reps will recognize (e.g., "SaaS Subscriptions", "Professional Services", "Hardware", "Add-ons").
4. Click **Save**.
The category is immediately available for assignment to products.
### Naming conventions
Keep category names concise and consistent. Avoid abbreviations that might confuse reps who didn't create them. Common patterns:
* By product type: "Software", "Hardware", "Services"
* By business model: "Recurring", "One-time", "Usage-based"
* By product line: "Core Platform", "Analytics Suite", "Integrations"
Choose whatever structure maps to how your team thinks about your catalog. There's no hierarchy or nesting -- categories are flat labels.
***
## Assigning categories to products
### During product creation
When creating a new product, the **Category** dropdown appears in the product setup form. Select the appropriate category before saving.
### On existing products
To add or change the category on an existing product:
1. Navigate to **Admin > Price Books > Products**.
2. Select the product you want to update.
3. Click **Edit** on the Product Details page.
4. Select a category from the dropdown and **Save**.
Each product can belong to one category. If you need to filter products across multiple dimensions (e.g., by region and by product type), use [Custom Fields and Filters](/get-started/pricing-and-packaging/product-filters) alongside categories.
***
## Using categories in rules
Categories become especially useful when combined with the [Rules Engine](/get-started/rules-and-approval/learn-the-basics). You can reference a product's category as a condition in any rule type:
**Validation rules:** Prevent certain product combinations. For example, "a quote cannot include products from both the 'Enterprise' and 'Startup' categories."
**Pricing rules:** Apply automatic adjustments based on category. For example, "apply a 5% bundle discount when a quote includes products from both 'Core Platform' and 'Analytics Suite'."
**Approval rules:** Route quotes for review based on what's being sold. For example, "require VP approval when total value from the 'Professional Services' category exceeds \$50,000."
***
## Editing and deleting categories
To rename a category, navigate to **Admin > Price Books > Categories**, select the category, and update the name. The change applies everywhere the category is referenced.
To delete a category, remove it from all assigned products first. Products that lose their category assignment will appear as uncategorized in the catalog.
If a category is referenced in any active rules, deleting it may cause those rules to stop matching. Review your rules before removing a category.
***
## What's next
Control which products reps see based on segment, region, and custom dimensions.
Add metadata to products for multi-dimensional filtering and reporting.
Full reference for product setup, pricing plans, and rep permissions.
Use categories as conditions in pricing, validation, and approval rules.
# Product Filters
Source: https://docs.getveles.com/get-started/pricing-and-packaging/product-filters
Control which products reps see during quoting by matching user attributes or CRM fields against product fields.
Product Filters control which products a rep sees when they open the catalog during quoting. Instead of showing every active product to every user, filters narrow the catalog based on who the rep is and what they're assigned to.
A filter works by matching a **source field** (an attribute on the user or a field from your CRM) against a **product field**. If the values match, the product is visible to that user. If they don't match, the product is hidden.
For example, a filter might match the user's assigned **Region** against a product's **Region** custom field. A rep assigned to "North America" would only see products tagged with "North America" in the catalog.
***
## How filters work
Every filter has three parts:
1. **Source field** -- where the filtering value comes from (the user's profile or a CRM field)
2. **Product field** -- the field on the product that the source value is compared against
3. **Match logic** -- if the source value matches the product field value, the product is visible
When a rep opens the product catalog during quoting, Veles evaluates all active filters and only shows products that pass every filter. If a product doesn't have a value set for the target field, it's excluded by default (though you can change this behavior -- see [Advanced options](#advanced-options)).
***
## Source fields
The source field determines where the filtering value comes from. Veles supports two sources:
### User fields
These are attributes stored directly on the user's profile in Veles. You configure these when [adding users](/get-started/quickstart/adding-users).
| Field | Type | Description |
| - | - | - |
| **Email** | Text | The user's email address. |
| **Job Title** | Text | The user's job title. |
| **Role** | Single Select | The user's role: Admin, Member, or Viewer. |
| **Regions** | Array | The regions assigned to the user (e.g., North America, EMEA, APAC). |
User fields are the most common source for filters. A typical setup matches the user's **Regions** against a Region field on the product.
### CRM fields
If you've connected a CRM ([Salesforce](/get-started/integrations/salesforce) or [HubSpot](/get-started/integrations/hubspot)), you can also pull source values from CRM fields. This lets you build filters based on data that lives in your CRM rather than duplicating it in Veles.
For example, if your CRM tracks which vertical a rep covers (Healthcare, FinTech, Manufacturing), you can use that CRM field as the source for a product filter without re-entering the data on each user's Veles profile.
CRM-sourced filters are especially useful for large teams where user attributes are already maintained in Salesforce or HubSpot. Instead of keeping two systems in sync, let the CRM be the source of truth and have Veles read from it at filter time.
***
## Creating a filter
1. Navigate to **Admin > Price Books > Filters**.
2. Click **+ Add Product Filter**.
3. **Name** the filter with something descriptive (e.g., "Region-based visibility" or "Vertical product matching").
4. **Select the source field.** Choose the **User** or **CRM** tab, then pick the field that provides the filtering value.
5. **Map it to a product field.** Select the corresponding field on the product that the source value should be compared against.
6. Set the **Status** to **Active**. Active filters are applied whenever users view products. Inactive filters are saved but don't affect visibility.
7. Click **Save Changes**.
***
## Advanced options
The filter builder includes two advanced settings for handling edge cases. These are optional but important for avoiding unexpected behavior in larger catalogs.
### Include products with blank values
**What it does:** When a product doesn't have the target field set at all, the filter would normally exclude it. Enabling this option lets those products pass through the filter instead.
**When to use it:** Turn this on when a blank value means "applies to everyone" rather than "not configured yet."
**Example:** You filter products by `region_ids`, but some products are global and don't have any regions assigned. Enabling this setting ensures those global products still appear for all users, while region-specific products are filtered normally.
### Default source value
**What it does:** When the source value is unavailable (e.g., a user has no region assigned), the filter is normally skipped entirely. Setting a default means the filter runs using this fallback value instead.
**When to use it:** Use this when skipping the filter for users with missing data would show too many (or too few) products. Leave it blank if skipping the filter is the right behavior for your team.
**Example:** You filter products by the user's **Region**, but new hires don't have a region assigned yet. Setting a default of `us-east` ensures they see US East products instead of seeing everything (unfiltered) or nothing.
***
## Common filter patterns
### Region-based visibility
The most common filter. Match the user's **Regions** field against a Region custom field on the product.
* **Source:** User > Regions
* **Product field:** Region
* **Result:** A rep assigned to EMEA only sees products tagged with EMEA. A rep assigned to both EMEA and APAC sees products tagged with either.
* **Tip:** Enable "Include products with blank values" so global products (no region set) appear for everyone.
### Segment-based visibility
Match the user's assigned segment against a Segment custom field on the product.
* **Source:** User > Segment (or a CRM field if segments are managed in your CRM)
* **Product field:** Segment
* **Result:** An Enterprise rep only sees Enterprise-tier products. An SMB rep only sees SMB-tier products.
### Vertical-based visibility
Use a CRM-sourced field to filter products by the rep's industry vertical.
* **Source:** CRM > Vertical (e.g., a custom field on the Salesforce User or HubSpot owner record)
* **Product field:** Vertical
* **Result:** A rep covering Healthcare only sees products relevant to Healthcare customers.
***
## How multiple filters interact
When multiple filters are active, they're evaluated together. A product must pass **all** active filters to be visible to a user.
For example, if you have both a Region filter and a Segment filter active:
* A product tagged with Region = "North America" and Segment = "Enterprise" is visible only to reps who are assigned to North America **and** Enterprise.
* A product tagged with Region = "North America" and no Segment is visible to North America reps only if "Include products with blank values" is enabled on the Segment filter.
Be careful when stacking multiple filters. Each additional filter narrows visibility further. If reps report that products are missing from their catalog, check whether the combination of active filters is too restrictive.
***
## Managing filters
### Editing a filter
Navigate to **Admin > Price Books > Product Filters** and select the filter. Update the name, source field, product field, or advanced options, then click **Save Changes**.
### Deactivating a filter
Set the filter's Status to inactive. The filter configuration is preserved but no longer applied when users view products. This is useful for testing or temporarily broadening catalog visibility.
### Deleting a filter
Remove the filter entirely from **Admin > Price Books > Product Filters**. This immediately makes all products that were previously hidden by the filter visible to users who can now see them.
***
## What's next
Define the product-side fields that filters match against.
Assign regions, segments, and other attributes that filters use as source values.
Pull CRM fields into Veles to use as filter sources.
Organize products into families for catalog navigation and rule logic.
# Units of Measure
Source: https://docs.getveles.com/get-started/pricing-and-packaging/units-of-measure
Define the inputs that drive pricing calculations: what's being counted, how it's labeled, and how it scales.
A Unit of Measure (UOM) defines what a rep is entering when they set a quantity on a quote line -- and what the buyer sees on the proposal. "Per User," "Per GB," "Per 1,000 API Calls," and "Per \$1M Transaction Volume" are all units of measure.
UOMs serve two purposes: they label the input field so reps know what they're entering, and they configure how that input drives the pricing calculation. By defining a UOM once, you can reuse it across multiple products for consistency.
***
## Attributes
Each Unit of Measure has four key settings:
| Attribute | Scope | Description |
| - | - | - |
| **Name** | Internal | Display name in the Veles admin interface (e.g., "User Seats", "API Call Volume"). |
| **Key** | System | Unique identifier used to reference this UOM in rules and pricing logic. Use lowercase with no spaces (e.g., `user_seats`, `api_calls`). |
| **Label** | Customer-facing | The text that appears on quotes and proposals. This is what the buyer sees (e.g., "Per User", "Per 1,000 API Calls"). |
| **Scale** | Both | The numerical multiplier applied to the rep's input. See [Scale](#scale). |
***
## Input kind: Quantity vs. Driver
The **Input Kind** is the most important setting on a UOM. It determines whether the input represents the number of units being sold or a metric that drives the price of a single unit.
### Quantity
The rep is entering how many of a product to sell. The total price is calculated as the rate (from the pricing tier) multiplied by this quantity.
This is the default for most products: per-seat licenses, per-unit hardware, per-hour services.
### Driver
The rep is entering a value that determines the price tier, but the order quantity is always 1. The product is sold as a single SKU whose price varies based on an external metric.
The Driver input kind corresponds to [custom lookup drivers](/get-started/pricing-and-packaging/creating-a-product#lookup-drivers) on the pricing plan. When you use a Driver UOM, set the product's quantity to 1 and mark **Quantity Editable** as off in the [rep permissions](/get-started/pricing-and-packaging/creating-a-product#rep-permissions).
***
## Scale
Scale simplifies data entry for reps working with large numbers. Instead of typing `42,500,000`, a rep enters `42.5` with the scale set to Millions. Veles handles the math internally.
| Scale | Multiplier | Rep enters | Veles interprets as |
| - | - | - | - |
| **Singles** | 1 | 50 | 50 |
| **Hundreds** | 100 | 50 | 5,000 |
| **Thousands** | 1,000 | 50 | 50,000 |
| **Millions** | 1,000,000 | 42.5 | 42,500,000 |
The scale setting affects the input field during quoting and the tier evaluation in the pricing engine. The simplified value is what the rep sees; the full value is what the calculation uses.
Match the scale to how your team naturally talks about the metric. If your sales team says "42 million in transaction volume," set the scale to Millions so they enter `42`. If they say "50,000 API calls," set it to Thousands so they enter `50`.
***
## Currency toggle
You can mark a Unit of Measure as a **currency** input. This formats the input field and all outputs as a dollar value rather than a plain number.
**When to use it:** Primarily for transactional or revenue-share products where the pricing driver is a monetary amount, like "Total Transaction Volume," "Annual Ad Spend," or "Total Contract Value."
**Effect:** The input field shows a currency symbol, and the value is formatted as currency throughout the quote and on generated documents. This makes it clear to both reps and buyers that the input represents a dollar amount, not a unit count.
Products using a currency-type UOM are typically configured as [Transactional](/get-started/pricing-and-packaging/creating-a-product#rep-permissions) in the rep permissions, which excludes them from Total ARR calculations and displays them as a rate to the buyer.
***
## Shared vs. unique UOMs
You have two strategies for managing units of measure:
**Shared UOMs** define a single unit that's reused across multiple products. For example, a "Per User" UOM can be applied to every product in your SaaS catalog. When a rep enters a quantity on any of these products, the label, input kind, and scale are all consistent.
**Unique UOMs** define a specialized unit for a single product. For example, a cloud storage product might have a "Per GB" UOM that no other product uses, or a construction analytics product might have an "Annualized Construction Volume" UOM specific to that industry vertical.
Start with shared UOMs for your most common pricing dimensions (per-user, per-license, per-month). Create unique UOMs only when a product has a genuinely distinct input that doesn't apply to anything else in the catalog.
***
## Creating a Unit of Measure
1. Navigate to **Admin > Price Books > Units of Measure**.
2. Click **+ New Unit of Measure**.
3. Enter the **Name** (internal) and a unique **Key** (system identifier).
4. Enter the **Label** that buyers will see on quotes and proposals.
5. Select the **Input Kind**: Quantity or Driver.
6. Set the **Scale** (Singles, Hundreds, Thousands, or Millions).
7. Toggle **Is Currency** if the input represents a monetary value.
8. Click **Save**.
The UOM is immediately available for selection when configuring [pricing plans](/get-started/pricing-and-packaging/creating-a-product#pricing-plans) on any product.
***
## Common examples
| UOM Name | Label | Input Kind | Scale | Currency | Used for |
| - | - | - | - | - | - |
| User Seats | Per User | Quantity | Singles | No | SaaS per-seat licensing |
| API Calls | Per 1,000 API Calls | Quantity | Thousands | No | Usage-based API products |
| Storage | Per GB | Quantity | Singles | No | Cloud storage products |
| Transaction Volume | Annual Transaction Volume | Driver | Millions | Yes | Revenue-share platform fees |
| Ad Spend | Monthly Ad Spend | Driver | Thousands | Yes | Marketing platform pricing |
| Hours | Per Hour | Quantity | Singles | No | Professional services |
***
## UOMs and Stripe import
When importing products from Stripe, unit labels come in as blank because Stripe doesn't have an equivalent concept. After import, update each product's UOM to set the correct label. See [Connect your Stripe Account](/get-started/quickstart/connect-your-stripe-account#what-to-know-about-stripe-imports) for details.
***
## What's next
Assign UOMs to products through pricing plan configuration.
Understand how UOM inputs drive tier-based pricing calculations.
Configure billing frequencies alongside your units of measure.
Use reference tables for dynamic pricing driven by UOM inputs.
# Account Setup
Source: https://docs.getveles.com/get-started/quickstart/account-setup
Configure your Veles workspace: company details, branding, billing information, payment methods, and default settings.
This guide covers the full configuration of your Veles account. All settings described here are managed in the **Admin Console**, which is accessible to users with the Admin role.
Looking for the condensed version? The [Quickstart](/get-started/quickstart/quickstart) walks through the minimum setup to get your first quote out the door.
***
## Company information
Navigate to **Admin Console > Settings > Business**.
Enter your company's **trade name** -- this is the name used in customer-facing materials. It appears on the buyer web portal, transactional emails, and generated documents (proposals, order forms, contracts).
The trade name can be different from your legal name. For example, your trade name might be "Acme" while your legal entity is "Acme Software, Inc." Both are stored separately.
***
## Brand identity
Your brand settings control the look and feel of every customer-facing output from Veles: quotes, proposals, the buyer web portal, emails, and generated PDFs.
### Logo
Upload your company logo. This is displayed on:
* The buyer-facing web portal
* Generated documents (proposals, order forms, contracts)
* Transactional emails
Use a high-resolution image with a transparent background for best results. Veles supports PNG and JPEG formats. Do not use web files as they will cause your documents to error on export.
### Favicon
Upload a favicon for the buyer web portal. This is the small icon that appears in the browser tab when a buyer opens your quote link.
### Brand color
Set your **primary brand color** by entering a HEX code (e.g., `#4F46E5`). This color is used as the accent throughout documents and emails -- buttons, headers, highlights, and other visual elements.
Veles provides a **live preview** on the right side of the settings screen so you can see how your changes affect generated documents before saving.
Choose a brand color with strong contrast against white backgrounds. Very light colors may not render well on documents and email clients.
***
## Default settings
Beyond the core configuration above, there are several account-wide defaults worth setting before your team starts quoting.
### Currencies
Veles supports multi-currency pricing. Your **base currency** is determined by your company's country (set during account creation). To add additional currencies for international deals, see [Adding Currencies](/get-started/pricing-and-packaging/adding-currencies).
### Document templates
Veles generates proposals, order forms, and contracts using customizable HTML/CSS templates. Your brand identity settings (logo, color) are automatically applied, but you can further customize layouts and content. See [Document Generation](/get-started/document-generation) for template configuration.
### Approval workflows
If your organization requires deal approvals (e.g., for discounts above a threshold), configure approval chains before your team starts quoting. Approval routing is based on the user hierarchy you set up when [adding users](/get-started/quickstart/adding-users). See [Approvals](/get-started/calculator/approvals) for configuration details.
***
## What's next
Build your product catalog manually or import from Stripe.
Add users, assign roles, and configure the org hierarchy.
Set up bi-directional sync with Salesforce or HubSpot.
Set up guardrails and approval logic before reps start quoting.
# Adding a Product
Source: https://docs.getveles.com/get-started/quickstart/adding-a-product
Add products to your Veles catalog manually or by importing from Stripe, then configure pricing plans and rep permissions.
Before your team can build a quote, you need at least one product in your catalog. Products are the building blocks of every deal in Veles -- they contain the SKU, pricing logic, and configuration that drive the quoting engine.
There are two ways to populate your catalog: importing from Stripe (fastest) or creating products manually (most control).
***
## Option A: Import from Stripe
If you've already connected your Stripe account, you can pull in your existing price book and skip most of the manual setup.
1. Navigate to **Admin > Price Books > Products**.
2. Click **Import from Stripe**.
3. Select the products you want to sync. Veles imports the SKU, name, and pricing structure for each selected product.
4. Review the imported products and make any adjustments (categories, custom fields, rep permissions).
Imported products are immediately available in the catalog. You can edit their pricing plans, add categories, or adjust permissions after import.
Stripe import requires an active Stripe connection. See [Account Setup](/get-started/quickstart/account-setup#connect-stripe) if you haven't connected Stripe yet.
***
## Option B: Create a product manually
### Step 1: Product details
Navigate to **Admin > Price Books > Products** and click the **+ New Product** button.
| Field | Required | Description |
| - | - | - |
| **Name** | Yes | The display name as it appears in the catalog and on quotes. |
| **SKU** | Yes | A unique identifier for the product. Must be unique across your entire Veles environment. Used for reporting, CRM sync, and ERP integration. |
| **Category** | No | Groups the product into a logical family (e.g., "Software", "Professional Services", "Hardware"). Categories control how products are organized in the quoting interface. |
| **Description** | No | Internal notes or customer-facing details about the product. |
| **Custom fields** | No | Organizational fields like Region, Segment, or Vertical. Used as filters during quoting so reps only see relevant products. |
| **Status** | Toggle | Set to **Active** to make the product available to reps. Inactive products are hidden from the catalog. |
Click **Save** to create the product. You'll be redirected to the Product Details page.
**Set up categories first.** If you're building a catalog with many products, create your [Product Categories](/get-started/pricing-and-packaging/product-categories) before creating products so you can assign them during setup rather than going back to edit each one.
### Step 2: Add a pricing plan
From the Product Details page, click **Add Pricing Plan**. A pricing plan defines how the product is sold and how the price is calculated.
**Currency:** Select the currency for this plan. If you sell in multiple currencies, you can add additional pricing plans later. See [Adding Currencies](/get-started/pricing-and-packaging/adding-currencies).
**Payment type:** Choose the billing structure:
* **Recurring** -- for products billed on a repeating schedule (e.g., annual license, monthly SaaS seat).
* **One-time** -- for products billed once (e.g., implementation fee, onboarding service).
**Pricing floor** (optional): Set a minimum price. This can be a fixed dollar amount or a formula. Useful for preventing reps from discounting below cost.
### Step 3: Configure components and pricing method
A pricing plan is built from one or more **components**. Most products need only one component (e.g., "Base License"), but complex products can have multiple components that are summed together.
Name your component, then select a **pricing method**:
A single fixed price regardless of quantity. The quantity defaults to 1 -- the product is either included or not.
**Best for:** Implementation fees, one-time services, fixed-price add-ons.
**Example:** A "Standard Implementation" fee of \$5,000. The price doesn't change based on other deal factors.
A single rate applied to the entire quantity, based on which tier that quantity falls into. All units are priced at the same rate.
**Best for:** Per-seat licensing, ACV-based pricing.
**Example:**
* Tier 1 (0-5 users): \$50/user
* Tier 2 (6-10 users): \$40/user
If a rep enters a quantity of **8**, the total is \*\*$320** ($40 x 8). All 8 units are priced at the Tier 2 rate.
Units are priced progressively based on the tier they fall into, like tax brackets. Each tier's units are priced at that tier's rate, and the results are summed.
**Best for:** Usage-based billing, consumption models.
**Example:**
* Tier 1 (0-5 users): \$50/user
* Tier 2 (6-10 users): \$40/user
If a rep enters a quantity of **8**, the first 5 units cost $250 (5 x $50), the remaining 3 units cost $120 (3 x $40). Total = **\$370**.
A fixed dollar amount for anything within a tier's range, regardless of the exact quantity. No per-unit multiplication.
**Best for:** Platform packages, bucket pricing (e.g., "0-50 employees" plan).
**Example:**
* Tier 1 (0-5 units): \$500 flat
* Tier 2 (6-10 units): \$800 flat
A quantity of **4** costs $500**. A quantity of **9** costs **$**800**.
Price is calculated as a percentage of the value of other products in the same pricing option.
**Best for:** Support plans, success fees, platform fees tied to deal value.
**Example:** A 10% support fee on a $100,000 deal adds $10,000.
You can set tiered percentages (e.g., 10% for deals under $100k, 7% over $100k), and optionally exclude one-time fees to calculate the percentage against recurring revenue (ARR) only.
For a detailed comparison of all pricing methods with additional examples, see [Pricing Models](/get-started/pricing-and-packaging/pricing-models).
#### Lookup drivers
The **lookup driver** defines what input drives the price calculation.
* **Quantity** (default): The number of units sold. This is what you'll use for most per-seat or per-unit products.
* **Custom drivers**: Used for transactional or consumption-based pricing. For example, "Transaction Value" or "Annualized Construction Volume" might define the price per unit without being the quantity of SKUs.
#### Input scale
Input scale simplifies data entry for reps working with large numbers. Set the scale to **Singles**, **Hundreds**, **Thousands**, or **Millions** so a rep can enter `42.5` instead of typing `42,500,000`.
### Step 4: Define pricing tiers
For any lookup-based pricing method (Volume, Graduated, or Stair-step), you'll define tiers using the boundary table. Veles uses **upper boundaries** to set ranges.
1. Enter the **upper boundary** for each tier (e.g., Tier 1 upper boundary = 5, Tier 2 upper boundary = 10).
2. Set the **price** for each tier.
3. Veles displays a **live calculation preview** as you build the table, so you can verify the math in real time.
Start with 2-3 tiers and add more as needed. You can always edit the tier structure after the product is live without affecting existing quotes.
### Step 5: Set rep permissions
At the bottom of the pricing plan, toggle the permissions that control what sales reps can modify during quoting:
| Permission | What it controls |
| - | - |
| **List Price Editable** | Allows reps to manually override the calculated list price. Use only for products without fixed pricing (legacy SKUs, unpriced items). Manual edits override automatic calculations -- to recalculate after a quantity change, the rep must clear the List Price field. |
| **Disable Discounting** | When ON, reps cannot apply discretionary discounts. Only automated rules or promotions will apply. |
| **Name Editable** | Allows reps to rename the product on customer-facing documents. The underlying SKU and system name remain unchanged for reporting. Note: when synced to a CRM or Stripe, the product name reverts to the original system name. |
| **Quantity Editable** | Allows the rep to change the unit count, even if a default quantity was set. |
| **Transactional** | Marks the SKU as billed in arrears (e.g., a percentage of transaction volume). Transactional SKUs are excluded from Total ARR calculations and displayed as a rate to the buyer. |
Products using custom pricing drivers (transaction value, construction volume, credit consumption) should typically have their quantity fixed at **1**. The driver determines the price; the quantity represents the SKU count on the order.
***
## Organizing your catalog
As your product catalog grows, use these tools to keep it navigable:
**Categories** group products into logical families (e.g., "SaaS Subscriptions", "Professional Services", "Hardware"). Categories appear as filters in the quoting interface, so reps can quickly narrow down a large catalog. Create categories at **Admin > Price Books > Categories** before adding products. See [Product Categories](/get-started/pricing-and-packaging/product-categories).
**Custom fields** like Region, Segment, or Vertical let you tag products with metadata that drives filtering and reporting. When a rep builds a quote, custom field values on the product can carry over to the quote line for granular downstream reporting.
**Filters** combine categories and custom fields to control which products a specific rep sees based on their assigned segment, region, or vertical. See [Product Filters](/get-started/pricing-and-packaging/product-filters).
***
## What's next
Deep dive into each pricing method with detailed examples and comparison tables.
Configure billing frequencies and contextual data for your products.
Upload custom datasets to drive dynamic pricing (e.g., price-by-zip-code matrices).
Define the inputs that drive pricing: per-user, per-API-call, or custom units.
# Adding Users
Source: https://docs.getveles.com/get-started/quickstart/adding-users
Add team members to Veles, assign roles and permissions, configure the org hierarchy, and control product visibility with filters.
User management in Veles is handled in the **Admin Console** under the **Access** section. Here you control who can access the platform, what they can do, and which products and data they see when building quotes.
Only users with the **Admin** role can add or manage other users.
***
## Creating a new user
Navigate to **Admin Console > Access > Users** and click **+ Add New User**.
### Personal details
| Field | Required | Description |
| - | - | - |
| **First & Last Name** | Yes | The user's display name throughout the platform. |
| **Email Address** | Yes | Their login identifier. The invitation email is sent here. |
| **Job Title** | No | Useful for internal context and reporting. |
| **Phone** | No | Optional contact info stored on the user record. |
### Manager
Select the user's direct manager from the dropdown. This field is optional but important -- it drives two things:
1. **Approval routing.** When a quote requires approval, Veles automatically identifies the rep's manager as the approver. If you don't set managers, you'll need to configure approval chains manually.
2. **Org chart.** The manager relationship builds your team's reporting structure, which you can view visually by toggling the **Org Chart** view at the top of the Users table.
Set up your managers and org hierarchy before configuring [Approval Workflows](/get-started/calculator/approvals). The approval engine uses this hierarchy to determine routing, so getting it right upfront saves you from debugging approval chains later.
### Role
Every user is assigned one of three roles that control their access level:
Admins have unrestricted access to the entire platform. This includes:
* Full access to the Admin Console (settings, integrations, price books)
* Create, edit, and delete users
* Configure pricing rules, approval workflows, and document templates
* Create and manage quotes, orders, and contracts
* View all reporting and analytics
**Who should be an Admin:** RevOps leads, deal desk managers, and the team member responsible for maintaining the Veles instance. Keep this group small.
Members are the core user role for anyone actively building quotes and working deals. They can:
* Create and edit quotes
* Add products from the catalog and configure pricing options
* Link quotes to CRM opportunities
* Send quotes to buyers via the web portal
* View their own quotes and deals
Members **cannot** access the Admin Console, change global pricing logic, edit the product catalog, or manage other users.
**Who should be a Member:** Account Executives, Sales Reps, Sales Engineers, and anyone who creates or edits quotes.
Viewers can see commercial data but cannot create or modify anything. They can:
* View quotes, orders, and contracts
* Access dashboards and reports
* Review deal details and pricing
Viewers **cannot** create quotes, edit pricing, or access admin settings.
**Who should be a Viewer:** Finance, Product, Customer Success, and any stakeholder who needs visibility into deal data without the ability to change it.
***
## Assigning filters
After setting the role, you can assign the user to one or more **filters**. Filters control which products and data a user sees when building quotes, ensuring reps only work with products relevant to their deals.
### Segments
Assign the user to customer segments like **Enterprise**, **Mid-Market**, or **SMB**. When a product is tagged with a segment, only reps assigned to that segment will see it in the catalog during quoting.
### Regions
Assign to geographical territories like **North America**, **EMEA**, or **APAC**. Region filters work the same way as segments -- products tagged with a region are only visible to reps assigned to that region.
### Custom filters
If your organization has created additional filter dimensions (e.g., **Vertical** with values like "Healthcare" or "FinTech"), you can assign users to those as well.
Filters are additive. A rep assigned to "Enterprise" and "North America" will see products that match either filter, not just products that match both. If a product has no filters set, it's visible to all reps.
***
## Managing existing users
### Editing a user
Navigate to **Admin Console > Access > Users** and click on the user you want to edit. You can update any field: name, email, job title, manager, role, or filter assignments. Changes take effect immediately.
### Changing a user's role
To change a user's role (e.g., promoting a Member to Admin), edit the user and select a new role from the dropdown. The new permissions apply on their next page load.
### Deactivating a user
When someone leaves the team or no longer needs access, deactivate their account rather than deleting it. Deactivation preserves their historical data (quotes they created, approvals they gave) while preventing further login.
If a deactivated user was a manager in the org hierarchy, their direct reports will need to be reassigned to a new manager. Otherwise, approval routing for those reports may break.
***
## The org chart
Veles builds a visual org chart from the manager relationships you define on each user. To view it, go to **Admin Console > Access > Users** and toggle the **Org Chart** view at the top of the table.
The org chart serves two purposes: it gives leadership a quick view of team structure, and it's the source of truth for approval routing. If your approval workflows use manager-based routing, the org chart is where Veles determines who approves what.
***
## What's next
Configure the approval chains that use the org hierarchy you just set up.
Sync users and deal data with Salesforce or HubSpot.
Build your product catalog so your team has something to quote.
Set up pricing guardrails before reps start building deals.
# Connect your CRM
Source: https://docs.getveles.com/get-started/quickstart/connect-your-crm
Set up bi-directional sync between Veles and your CRM so deal data flows automatically between systems.
Connecting your CRM to Veles enables bi-directional sync between your deal data and the quoting engine. Opportunities, accounts, and contacts flow into Veles, and quote data, order data, and contract data flow back -- keeping both systems in sync without manual data entry.
Veles supports two CRM integrations:
* **Salesforce** -- API-based integration with bi-directional field mapping configured through the Veles UI
* **HubSpot** -- native integration via OAuth with deal, company, and contact sync
You only need to connect one. Choose the CRM your team uses as its system of record.
CRM connection requires **Admin** access in Veles and admin-level permissions in your CRM. If you're not a Salesforce or HubSpot admin, coordinate with your CRM admin before starting.
***
## What syncs
Once connected, Veles exchanges data with your CRM across these objects:
| Veles object | CRM object | Sync direction | What flows |
| - | - | - | - |
| **Customer** | Account (SFDC) / Company (HS) | CRM → Veles | Company name, address, industry, and custom fields. |
| **Contact** | Contact (SFDC) / Contact (HS) | CRM → Veles | Name, email, title, phone. Used to populate the "Prepared For" field on quotes. |
| **Quote** | Opportunity (SFDC) / Deal (HS) | Bi-directional | Quote metadata, status, and totals sync back to the CRM record. Opportunity/deal data populates quote context. |
| **Order** | Order (SFDC) / Deal (HS) | Veles → CRM | When a quote converts to an order, the committed deal data is pushed to the CRM. |
| **Contract** | Contract (SFDC) / Deal (HS) | Veles → CRM | Active contract details, including entitlements and renewal dates. |
Veles pulls account and contact data from your CRM, but the CRM remains the system of record for those objects. Edits to customer or contact info should be made in the CRM -- they'll sync to Veles automatically.
***
## Salesforce
Veles connects to Salesforce via API and provides a field mapping UI that lets you define exactly how data flows between the two systems. There's no managed package to install -- you authorize the connection in Veles, map your fields, and data starts syncing.
### Prerequisites
* Salesforce admin credentials with API access
* Veles admin access
### Setup
1. In Veles, navigate to **Admin Console > Integrations > Salesforce**.
2. Click **Connect to Salesforce**. You'll be redirected to the Salesforce login page.
3. Log in with your Salesforce admin credentials and authorize Veles to access your org.
4. Once authorized, the connection status in Veles will show **Active**.
### Field mapping
After connecting, you'll configure how data maps between Salesforce fields and Veles fields using the integration UI. This is where you define which Salesforce fields correspond to which Veles fields, and how data transforms as it moves between systems.
Navigate to **Admin Console > Integrations > Salesforce > Field Mapping** to open the mapping interface. From here you can:
* **Map standard fields** -- link Salesforce Opportunity, Account, and Contact fields to their Veles counterparts (Quote, Customer, Contact).
* **Map custom fields** -- any custom fields in your Salesforce org can be mapped to custom fields in Veles, so your team's specific data points carry through the quoting process.
* **Set transformation rules** -- define how values are handled during sync. Veles supports direct mapping (value copies as-is), formula-based transformations (e.g., calculating a value from multiple source fields), and static values (a fixed value applied regardless of source).
Veles ships with sensible defaults for standard fields. Review these first, then extend the mappings for any custom fields your org uses.
If you have specific integration needs, feel free to reach out to us and we can work with your team to ensure a smooth implementation.
If you're migrating from Salesforce CPQ (Steelbricks), Veles includes a guide for [translating your existing rules](/get-started/rules-and-approval/translating-sfdc-rules-to-veles) to the Veles format. Review it before setting up field mappings to avoid duplicating work.
***
## HubSpot
Veles integrates with HubSpot natively through OAuth. No package installation or custom objects required -- Veles connects directly to HubSpot's API to sync deal, company, and contact data.
### Prerequisites
* HubSpot admin or super admin credentials
* Veles admin access
* A HubSpot plan that supports API access (Professional or Enterprise for most features)
### Setup
1. In Veles, navigate to **Admin Console > Integrations > HubSpot**.
2. Click **Connect to HubSpot**. You'll be redirected to HubSpot's authorization page.
3. Log in and authorize Veles to access your HubSpot account.
4. Select which HubSpot properties you want to sync with Veles.
5. Once authorized, the connection status in Veles will show **Active**.
### Property mapping
After connecting, configure which HubSpot deal properties map to Veles quote and order fields. Navigate to **Admin Console > Integrations > HubSpot > Property Mapping** to review and customize the mappings.
Veles maps to HubSpot's standard objects:
* **Companies** → Veles Customers
* **Contacts** → Veles Contacts
* **Deals** → Veles Quotes (and syncs back order/contract data to the same deal)
Custom deal properties in HubSpot can be mapped to custom fields in Veles, ensuring your team's specific data points carry through the quoting process.
***
## After connecting
Once your CRM connection is active, a few things happen automatically:
**Quotes pull CRM context.** When a rep creates a new quote, they can link it to a CRM opportunity or deal. The quote's Context Block (proposal name, customer info, stakeholder details) can be auto-populated from the CRM record.
**Changes sync in real time.** When a quote is updated in Veles, the changes are reflected in the CRM. When a deal is updated in the CRM, the linked data updates in Veles.
**Orders and contracts write back.** When a quote is approved and converted to an order, and subsequently a contract, that data is pushed to the CRM -- creating the audit trail your finance and RevOps teams need.
***
## Troubleshooting
### Sync not working
If data isn't flowing between Veles and your CRM:
1. Check the connection status at **Admin Console > Integrations**. If it shows anything other than **Active**, try disconnecting and reconnecting.
2. Review the sync log in Veles at **Admin Console > Integrations > \[CRM] > Sync Log** for error details.
3. Verify that the user who authorized the connection still has active admin credentials in the CRM. Expired or revoked permissions will break the sync.
### Field mapping errors
If specific fields aren't syncing correctly:
1. Confirm the field mapping exists at **Admin Console > Integrations > \[CRM] > Field Mapping**.
2. Check that the field types are compatible (e.g., a Salesforce picklist mapping to a Veles text field may not behave as expected).
3. For formula-type mappings, verify the formula syntax in the mapping configuration.
If you're stuck, reach out to the Veles team at [**hi@getveles.com**](mailto:hi@getveles.com) with the specific error message or sync behavior you're seeing.
***
## What's next
Now that your CRM is connected, build a quote linked to a live opportunity.
Add billing and payment collection to your deal flow.
Migrating from Salesforce CPQ? Translate your existing rules to Veles.
Set up pricing guardrails now that your data is flowing.
# Connect your Stripe Account
Source: https://docs.getveles.com/get-started/quickstart/connect-your-stripe-account
Connect Stripe to Veles to import your product catalog, collect payments, and orchestrate billing from committed orders.
Connecting Stripe to Veles unlocks two capabilities:
1. **Product catalog import.** Pull your existing Stripe products and pricing into Veles so you can start quoting immediately without rebuilding your price book from scratch.
2. **Payment and billing orchestration.** When a quote is approved and converted to an order, Veles can create invoices, process charges, and sync payment status through your Stripe account automatically.
The connection uses Stripe's OAuth flow -- no API keys or webhooks to configure manually.
Stripe is optional. You can use Veles for quoting and contract management without connecting Stripe. But if your team collects payment through Stripe, connecting it closes the loop from quote to cash.
***
## Prerequisites
* A Stripe account with admin or owner access
* Veles admin access
***
## Connecting Stripe
1. In Veles, navigate to **Admin Console > Integrations > Stripe**.
2. Click **Connect**. You'll be redirected to Stripe's login page.
3. Enter your Stripe account credentials and click **Continue**.
4. Authorize Veles to access your Stripe account.
5. Once complete, the Stripe status in Veles will show **Active**.
That's it. The connection is live and Veles can now read from and write to your Stripe account.
***
## Importing your product catalog
Once Stripe is connected, you can import your existing products and pricing into the Veles catalog.
1. Navigate to **Admin > Price Books > Products**.
2. Click **Import from Stripe**.
3. Select the products you want to import. Veles pulls in the product name, SKU, and pricing structure for each selected product.
4. Review the imported products in your catalog.
Imported products are immediately available for reps to use in quotes. After import, you can edit any product to add Veles-specific configuration like categories, custom fields, pricing floors, or rep permissions.
### What to know about Stripe imports
**Pricing structures map automatically.** Stripe's pricing models (flat, tiered, per-unit, package) map to the corresponding Veles pricing methods. Review the imported pricing plans to confirm they match your expectations.
**Unit labels import as blank.** Stripe doesn't have a "label" concept for units -- it defaults everything to generic "units." After importing, you'll need to update the unit label for each product in Veles (e.g., changing "units" to "seats", "API calls", or "GB"). Navigate to the product's pricing plan and update the label in the component configuration.
**Categories and custom fields aren't imported.** Stripe doesn't have equivalents for Veles categories or custom fields. You'll need to assign these manually after import if you want to organize the imported products for filtering and reporting.
If you have a large Stripe catalog, set up your [Product Categories](/get-started/pricing-and-packaging/product-categories) in Veles first, then assign them in bulk after import rather than editing products one at a time.
***
## Payment and billing
With Stripe connected, Veles orchestrates payment actions on your Stripe account as deals progress through the lifecycle.
### What Veles handles automatically
**Invoice creation.** When a quote is approved and converted to an order, Veles can create the corresponding invoice in Stripe based on the order's line items, quantities, and pricing.
**Payment processing.** Charges are processed through your Stripe account using the customer's payment method on file.
**Status sync.** Payment status (paid, pending, failed) syncs back to Veles so your team has visibility into collection without leaving the platform.
### Payment methods
Veles supports three payment methods through Stripe, which you can enable or disable in your account settings:
* **Card payments** -- debit or credit cards
* **Direct debit** -- SEPA (EU), ACH (US), or Bacs (UK) depending on the customer's region
* **Bank transfer** -- offline wire payments using bank account details displayed on invoices
To configure which methods are available and to add bank account details for wire transfers, see [Account Setup > Payment Setup](/get-started/quickstart/account-setup#payment-setup).
***
## Managing the connection
### Checking connection status
Navigate to **Admin Console > Integrations > Stripe** at any time to check the connection status. A healthy connection shows **Active**.
### Disconnecting Stripe
If you need to disconnect (e.g., switching Stripe accounts), go to **Admin Console > Integrations > Stripe** and click **Disconnect**. This stops all sync and billing orchestration immediately.
Disconnecting Stripe does not delete products that were previously imported into Veles. Those products remain in your catalog and can still be used in quotes. However, new orders will no longer trigger invoicing in Stripe until you reconnect.
### Reconnecting or switching accounts
To connect a different Stripe account, disconnect the current one first, then follow the setup steps above with the new account's credentials.
***
## Troubleshooting
### Connection shows inactive or failed
1. Verify that the Stripe user who authorized the connection still has admin access. If their permissions were revoked or their account was removed, the connection will break.
2. Try disconnecting and reconnecting from **Admin Console > Integrations > Stripe**.
3. Check Stripe's [status page](https://status.stripe.com) to rule out a Stripe-side outage.
### Imported products missing pricing
If products import without pricing plans attached, they may have been archived or had no active prices in Stripe. Check the product in your Stripe dashboard to confirm it has at least one active price before re-importing.
### Invoices not creating from orders
1. Confirm the Stripe connection is **Active**.
2. Verify the order was fully committed (not still in draft or pending approval).
3. Check that the customer has a valid payment method on file in Stripe if auto-charge is enabled.
If you're stuck, reach out to the Veles team at [**hi@getveles.com**](mailto:hi@getveles.com) with the specific error or behavior you're seeing.
***
## What's next
Import from Stripe or create products manually.
Configure bank accounts and payment methods for invoicing.
Set up bi-directional sync with Salesforce or HubSpot.
Build a quote using your imported product catalog.
# Quickstart
Source: https://docs.getveles.com/get-started/quickstart/quickstart
Go from a new Veles account to your first quote in under 30 minutes.
This guide walks you through the five steps to go from a new Veles account to a live quote. You'll set up your workspace, add a product, invite your team, connect your CRM, and create your first quote.
**Already have a Stripe catalog?** You can skip the manual product setup and import your existing price book directly from Stripe. See [Step 3](#step-3-add-your-first-product) for details.
## Prerequisites
You'll need admin access to your Veles account. If you don't have an account yet, [sign up at app.getveles.com](https://app.getveles.com).
If you plan to connect integrations during this quickstart, have your login credentials ready for any of the following: Salesforce, HubSpot, or Stripe.
***
## Step 1: Configure your account
After signing in for the first time, head to the **Admin Console** to set up your workspace.
### Company information
Enter your company's **trade name** (the name used in customer-facing materials). This appears on quotes, proposals, and transactional emails.
### Brand identity
Customize how your quotes and documents look:
1. Upload your **company logo** -- this appears on quotes, proposals, and generated documents.
2. Upload a **favicon** for the buyer-facing web portal.
3. Set your **primary brand color** (HEX code). This is used as the accent color on documents and emails.
Veles shows a live preview on the right side of the screen as you make changes.
***
## Step 2: Connect Stripe (optional)
If you use Stripe for billing and payment collection, connect it now. This unlocks two things: the ability to import your existing product catalog (saving you from manual data entry), and the ability to push committed orders to Stripe for invoicing.
1. In the Admin Console, go to **Integrations > Stripe**.
2. Click **Connect**. You'll be redirected to Stripe's login page.
3. Enter your Stripe credentials and authorize the connection.
4. Once complete, the Stripe status in Veles will show **Active**.
No API keys or webhooks to configure -- the connection is handled through Stripe's OAuth flow.
[Full Stripe integration guide →](/get-started/integrations/stripe)
***
## Step 3: Add your first product
Before anyone can build a quote, you need at least one product in your catalog. There are two ways to do this:
### Option A: Import from Stripe (fastest)
If you connected Stripe in the previous step, you can pull in your existing price book automatically. Go to **Admin > Price Books > Import from Stripe** and select the products you want to sync. SKUs and pricing structures will be imported directly.
### Option B: Create a product manually
1. Go to **Admin > Price Books > Products** and click **+ New Product**.
2. Enter a **Product Name** and a unique **SKU**.
3. Optionally assign a **Category** to organize the product in your catalog.
4. Set the product **Status** to **Active** so it's available to sales reps.
5. Click **Save**.
### Add a pricing plan
Once the product is created, you'll be on the Product Details page. Click **Add Pricing Plan** to define how it's priced:
1. **Currency:** Set the pricing currency.
2. **Payment type:** Choose **Recurring** (e.g., annual license) or **One-time** (e.g., implementation fee).
3. **Pricing method:** Select how the price is calculated:
| Method | How it works |
| - | - |
| **Flat Fee** | Fixed price regardless of quantity. |
| **Volume Lookup** | All units priced at the tier reached. |
| **Graduated Lookup** | Units priced progressively by tier. |
| **Stair-step Lookup** | Price increases in defined blocks. |
| **Percentage Of** | Calculated as a % of another value. |
4. Define your **pricing tiers** using the boundary table. Veles uses upper boundaries to set ranges and shows a live calculation preview as you build.
5. Configure **rep permissions** at the bottom of the plan: whether reps can edit list price, apply discounts, change quantities, or rename the product on customer-facing documents.
For your first product, start simple: a flat-fee recurring product with a single pricing tier. You can always add complexity later. See the full [Creating a Product](/get-started/pricing-and-packaging/creating-a-product) guide for advanced configuration.
***
## Step 4: Invite your team
Go to **Admin Console > Access > Users** and click **+ Add New User**.
For each team member, provide:
1. **Name and email** (required). The email becomes their login.
2. **Manager** (optional). Setting this enables approval routing -- the manager is automatically flagged as the approver for that user's quotes.
3. **Role:**
| Role | Access |
| - | - |
| **Admin** | Full access to Admin Console, price books, settings, and all quotes. |
| **Member** | Can create and edit quotes, link CRM opportunities, and present pricing. Cannot change global pricing or settings. |
| **Viewer** | Read-only access to quotes and dashboards. |
4. **Filters** (optional). Assign the user to segments (Enterprise, Mid-Market, SMB), regions (NA, EMEA, APAC), or custom verticals. Filters control which products and data a rep sees when building quotes.
Once added, the user receives an email invitation to join the platform. If you assigned a manager, the user is automatically placed in the org chart and included in relevant approval chains.
You can view a visual org chart of your team's reporting structure by clicking the **Org Chart** toggle at the top of the Users table.
***
## Step 5: Connect your CRM
Connecting your CRM lets Veles sync deal data bi-directionally -- pulling in opportunities, accounts, and contacts, and pushing back quote and order data as deals progress.
Veles integrates with Salesforce through a managed package that supports bi-directional sync. Quotes, orders, and contracts map to your existing Salesforce objects.
1. In the Admin Console, go to **Integrations > Salesforce**.
2. Follow the guided setup to install the Veles managed package in your Salesforce org.
3. Authorize the connection and configure field mappings.
[Full Salesforce setup guide →](/get-started/integrations/salesforce)
Veles integrates natively with HubSpot CRM, syncing deals, companies, and contacts.
1. In the Admin Console, go to **Integrations > HubSpot**.
2. Click **Connect** and authorize Veles in your HubSpot account.
3. Configure which deal properties sync between the two platforms.
[Full HubSpot setup guide →](/get-started/integrations/hubspot)
***
## Step 6: Create your first quote
Now that you have a product, a team, and a connected CRM, you're ready to build your first quote.
1. From the main dashboard, click **+ New Quote**.
2. **Context block:** Fill in the proposal name (e.g., "Acme Corp -- Annual License"), select the **Prepared By** (you) and **Prepared For** (customer contact), and set the **Issued On** and **Valid Through** dates.
3. **Add a Pricing Option block.** This opens the Veles Calculator where you select products from your catalog, set quantities, and configure deal terms (contract length, payment schedule, ramp schedule).
4. **Add a Terms block** (optional). Insert predefined legal language or deal-specific terms directly into the proposal.
5. **Add a Text block** (optional). Use this for executive summaries, implementation scope, or other narrative content.
6. **Preview** the quote to see exactly what the buyer will see.
7. **Send** via the web portal, or generate a PDF document.
Quotes support multiple **Pricing Options** on a single proposal (e.g., Option A: 1-year term, Option B: 3-year term). Add additional Pricing Option blocks to give your buyer choices without creating separate quotes.
***
## What's next
You've got the basics running. Here's where to go from here depending on what you need:
Set up tiered, volume, usage-based, and ramp pricing structures.
Build pricing guardrails, validation rules, and approval workflows.
Track active contracts, handle amendments, and automate renewals.
Customize proposal and contract templates with your branding.
# Formula Rules
Source: https://docs.getveles.com/get-started/rules-and-approval/formula-rules
Build complex pricing and validation logic using the Veles formula engine: variables, control flow, list processing, and Data Sheet lookups.
Formula Rules are the most flexible rule type in Veles. They use a custom expression language (similar to Excel or SQL) to evaluate conditions and calculate values that go beyond what the standard rule builder can express.
Use Formula Rules when your logic involves multiple variables, conditional branching, list aggregation, or lookups against [Data Sheets](/get-started/pricing-and-packaging/data-sheets). If you can express it as a formula, you can build it as a rule.
Formula Rules are a power-user feature. For straightforward guardrails (discount caps, required products, price floors), [Quote Validation](/get-started/rules-and-approval/quote-validation), [Row Validation](/get-started/rules-and-approval/untitled-page), and [Pricing Rules](/get-started/rules-and-approval/pricing-rules) are simpler to configure. Use Formula Rules when those standard kinds can't express the logic you need.
***
## When to use Formula Rules
Formula Rules are the right choice when:
* The condition involves **multiple variables combined** (e.g., TCV > \$500k AND term \< 24 months AND segment = Enterprise)
* You need **conditional branching** based on segment, region, or product tier (CASE/IF logic)
* The logic requires **aggregating across line items** (e.g., sum the price of all "Enterprise" tier products)
* You need to **look up values from a Data Sheet** at evaluation time (VLOOKUP)
* The calculation involves **date or duration math** (e.g., contract length thresholds)
***
## Creating a Formula Rule
1. Navigate to **Admin Console > Price Books > Rules**.
2. Click **Create New Rule**.
3. Set the **Kind** to **Formula Validation**.
4. Enter a **Name** and **Description**.
5. Set the **Status** to Active.
6. Click **Save**, then open the formula editor to write your expression.
The formula editor provides syntax highlighting and validation. The formula must evaluate to a boolean (`true`/`false`) for validation rules, or a numeric value for pricing adjustments.
***
## Language basics
### Data types
| Type | Syntax | Examples |
| - | - | - |
| **Numbers** | Integers, decimals, scientific notation, hex | `100`, `15.5`, `1e-3`, `0x1A` |
| **Strings** | Single or double quotes | `'Enterprise'`, `"USD"` |
| **Booleans** | Lowercase keywords | `true`, `false` |
| **Null** | Keyword | `null` |
| **Arrays** | Braces | `{1, 2, 3}` |
| **Dates** | DD-MM-YYYY format | `22-01-2026` |
| **Durations** | Duration keyword | `duration(5, days)`, `duration(12, months)` |
### Operators
Evaluated in order of precedence (highest first):
| Category | Operators | Description | | |
| - | - | - | - | - |
| **Unary** | `+`, `-`, `%` | Positive/negative signs and percentage (e.g., `50%` = 0.5) | | |
| **Power** | `^` | Exponentiation | | |
| **Multiplicative** | `*`, `/` | Multiplication and division | | |
| **Additive** | `+`, `-` | Addition and subtraction | | |
| **Relational** | `<`, `<=`, `>`, `>=`, `=`, `!=`, `<>` | Comparisons (return `true`/`false`) | | |
| **Logical** | `&&`, \` | | \` | AND, OR |
Use parentheses to override precedence when needed: `(a + b) * c`.
***
## Variables
Variables reference real-time data from the quote being built. They're organized by scope.
### Quote-level variables
| Variable | Type | Description |
| - | - | - |
| `quote.segment` | String | The segment name (e.g., "Enterprise", "SMB"). |
### Option-level variables
| Variable | Type | Description |
| - | - | - |
| `option.frequency` | Integer | Billing cycles per year. 1 = annual, 4 = quarterly, 12 = monthly. |
| `option.currency_code` | String | 3-letter currency code (e.g., "USD", "EUR"). |
| `option.term_length` | Integer | Contract length in months. |
| `option.product_skus` | List | Array of all SKUs in the option. |
| `option.promotion_count` | Integer | Number of promotions applied. |
### Phase-level variables
| Variable | Type | Description |
| - | - | - |
| `phase.total` | Numeric | Net price after discounts (annualized). |
| `phase.discount` | Numeric | Overall discount percentage (0-100). |
| `phase.list_price` | Numeric | Total price before discounts. |
| `phase.year` | Integer | Current year in a multi-year deal (1-indexed). |
| `phase.lines` | List | Array of line item objects. Used for advanced filtering and aggregation. |
***
## Control flow
### IF function
For simple true/false branching:
```text theme={null}
if(condition, true_value, false_value)
```
**Example:** Return a different discount cap based on billing frequency:
```text theme={null}
if(option.frequency = 1, 25, 15)
```
This returns 25 (%) for annual billing and 15 (%) for everything else.
### CASE expression
For multi-branch logic, use CASE. It evaluates conditions sequentially and returns the first match:
```text theme={null}
CASE
WHEN quote.segment = "Enterprise" THEN 0.20
WHEN quote.segment = "Mid-Market" THEN 0.10
ELSE 0.05
END
```
This returns the maximum allowed discount based on the customer's segment.
***
## List processing
One of the most powerful features of the formula engine is the ability to filter, transform, and aggregate lists of line items.
### FILTER
Returns a subset of a list based on a condition:
```text theme={null}
FILTER(phase.lines, line, line.category = "Software")
```
This returns only the Software line items from the current Phase.
### MAP
Transforms every item in a list:
```text theme={null}
MAP(phase.lines, item, item.price)
```
This extracts the price from each line item, producing a list of numbers.
### SUM
Aggregates a list of numbers:
```text theme={null}
SUM({100, 200, 300})
```
Returns `600`.
### Chaining: FILTER + MAP + SUM
The real power comes from chaining these together. For example, summing the price of all Enterprise-tier products in a Phase:
```text theme={null}
SUM(
MAP(
FILTER(phase.lines, line, line.product.custom_attributes.tier = "enterprise"),
item,
item.price
)
)
```
This filters to Enterprise-tier lines, extracts their prices, and sums the result.
***
## Data Sheet lookups
Use `VLOOKUP` to query [Data Sheets](/get-started/pricing-and-packaging/data-sheets) from within a formula:
```text theme={null}
vlookup(sheet_name, lookup_column, lookup_value, return_column)
```
**Example:** Look up the maximum discount for the customer's segment from a `Discount_Thresholds` Data Sheet:
```text theme={null}
vlookup("Discount_Thresholds", "Segment", quote.segment, "Max_Discount")
```
If the Data Sheet has a row where Segment = "Enterprise" and Max\_Discount = 25, this returns `25`.
You can then use the looked-up value in a condition:
```text theme={null}
phase.discount <= vlookup("Discount_Thresholds", "Segment", quote.segment, "Max_Discount")
```
This formula evaluates to `true` when the discount is within the segment's allowed maximum, and `false` when it exceeds it.
***
## Function library
### Math and logic
| Function | Usage | Description |
| - | - | - |
| `abs(n)` | `abs(-42)` → `42` | Absolute value. |
| `round(n, digits)` | `round(3.456, 2)` → `3.46` | Round to decimal places. |
| `sqrt(n)` | `sqrt(16)` → `4` | Square root. |
| `min(a, b, ...)` | `min(10, 20, 5)` → `5` | Minimum value. |
| `max(a, b, ...)` | `max(10, 20, 5)` → `20` | Maximum value. |
| `avg(list)` | `avg({10, 20, 30})` → `20` | Average of a list. |
### String manipulation
| Function | Usage | Description |
| - | - | - |
| `concat(a, b, ...)` | `concat("Hello", " ", "World")` → `"Hello World"` | Join strings. |
| `contains(text, search)` | `contains("Enterprise", "Enter")` → `true` | Check if text contains a substring. |
| `left(text, n)` | `left("Enterprise", 3)` → `"Ent"` | Extract from the left. |
| `right(text, n)` | `right("Enterprise", 5)` → `"prise"` | Extract from the right. |
| `substitute(text, old, new)` | `substitute("Hello World", "World", "Veles")` | Replace text. |
### Date and duration
| Function | Usage | Description |
| - | - | - |
| `duration(n, unit)` | `duration(12, months)` | Create a duration for comparison. |
**Example:** Check if the contract term meets a minimum threshold:
```text theme={null}
option.term_length >= duration(12, months)
```
***
## End-to-end examples
### Segment-based discount validation
Validate that the discount doesn't exceed the maximum for the customer's segment, using a Data Sheet lookup:
```text theme={null}
phase.discount <= vlookup("Discount_Thresholds", "Segment", quote.segment, "Max_Discount")
```
* **Action if false:** Warn, "Discount exceeds the maximum for this segment. Requires approval."
* **Approval:** Tier 2: Deal Desk
### Multi-variable deal gate
Require VP approval when a deal has high value, short term, and deep discount:
```text theme={null}
NOT (phase.total > 500000 && option.term_length < 24 && phase.discount > 15)
```
* **Action if false:** Warn, "Large short-term deal with significant discount. Requires VP review."
* **Approval:** Tier 3: VP of Sales
### Year-over-year ramp validation
In a multi-year deal, ensure Year 2 pricing is not lower than Year 1:
```text theme={null}
if(phase.year = 1, true, phase.total >= phase.list_price * 0.95)
```
* **Action if false:** Error, "Year 2+ pricing cannot be more than 5% below list price."
### Enterprise product concentration
Warn when Enterprise-tier products represent more than 80% of the deal value (over-concentration risk):
```text theme={null}
SUM(MAP(FILTER(phase.lines, line, line.product.custom_attributes.tier = "enterprise"), item, item.price)) / phase.total <= 0.80
```
* **Action if false:** Warn, "Enterprise products represent more than 80% of deal value. Review product mix."
***
## Tips
**Start with validation rules, graduate to formulas.** If you can express the logic with the standard [Quote Validation](/get-started/rules-and-approval/quote-validation) or [Row Validation](/get-started/rules-and-approval/untitled-page) builder, do that. Formula Rules are more powerful but harder to debug and maintain. Use them when the standard builder genuinely can't handle the logic.
**Use VLOOKUP instead of hard-coding.** Any time you're tempted to put a specific number in a formula (a threshold, a rate, a cap), consider putting it in a [Data Sheet](/get-started/pricing-and-packaging/data-sheets) and looking it up with VLOOKUP. This makes the formula reusable across segments and easier to update.
**Test with edge cases.** Formulas can produce unexpected results with null values, empty lists, or zero-division scenarios. Test with quotes that have one line item, zero discount, and unusual product combinations.
**Document your formulas.** Use the rule's Description field to explain the business logic in plain language. A formula like `SUM(MAP(FILTER(...)))` is opaque without context. The description should say what it does in business terms.
***
## What's next
Build the reference tables that VLOOKUP queries against.
Overview of the rules engine and simpler rule kinds.
Automatic price adjustments without formula syntax.
Map Salesforce CPQ rules to the Veles formula engine.
# Getting Started with Rules
Source: https://docs.getveles.com/get-started/rules-and-approval/learn-the-basics
Understand the rules engine in Veles: how to build pricing guardrails, validation logic, and approval triggers that govern your quoting process.
Rules are the enforcement layer of your deal desk. They automate pricing adjustments, prevent invalid configurations, enforce discount guardrails, and trigger approval workflows -- all in real time as reps build quotes.
Every rule follows the same pattern: **if** a condition is met on a quote, **then** take an action. The condition can evaluate anything from the total deal discount to a specific product's quantity. The action can display a warning, block the quote from saving, adjust pricing automatically, or route the deal for approval.
Rules are configured by admins in the **Admin Console > Price Books > Rules** and apply automatically during quoting. Reps don't need to know the rules exist -- they see the results as alerts, price adjustments, or approval requirements on their quotes.
***
## Rule kinds
Every rule has a **kind** that determines where it evaluates and what it can do. There are four kinds:
| Kind | Where it evaluates | What it does | Use case |
| - | - | - | - |
| [**Quote Validation**](/get-started/rules-and-approval/quote-validation) | The entire Pricing Option | Validates deal-level conditions and can warn, block, or require approval. | "Discount cannot exceed 25% on any option." |
| [**Pricing Rule**](/get-started/rules-and-approval/pricing-rules) | Line items or the option | Automatically adjusts pricing based on conditions. | "Apply 5% bundle discount when Platform and Analytics are both present." |
| [**Row Validation**](/get-started/rules-and-approval/untitled-page) | Individual line items | Validates line-level conditions and can warn, block, or require approval. | "Discount on this SKU cannot exceed 10%." |
| [**Formula Rule**](/get-started/rules-and-approval/formula-rules) | Custom scope | Evaluates complex logic using the formula engine. | "If TCV exceeds \$500k and term is less than 2 years, require VP approval." |
Choose the kind based on what you're trying to enforce. Quote Validation and Row Validation are the most common starting points. Pricing Rules are for automated adjustments. Formula Rules are for complex multi-variable logic.
***
## Creating a rule
Navigate to **Admin Console > Price Books > Rules** and click **Create New Rule**.
### Rule details
Every rule starts with four fields:
| Field | Description |
| - | - |
| **Name** | A clear, descriptive name (e.g., "Enterprise Discount Limit", "Require Shipping on Hardware"). |
| **Description** | An explanation of what the rule does and why, for other admins. |
| **Status** | **Active** or **Inactive**. Only active rules are evaluated during quoting. |
| **Kind** | The rule type: Quote Validation, Pricing Rule, Row Validation, or Formula Rule. |
Click **Save** to create the rule, then build the logic.
***
## Building rule sets
A rule's logic is defined through one or more **Rule Sets**. Each Rule Set is an "if/then" block consisting of a **Scope**, one or more **conditions** (Facts + Operators), and an **Action**.
Click **New Rule Set** to start building.
### Scope
The scope determines what the rule is evaluating: the whole **Option** (deal-level) or a specific **Row** (line-item-level).
### Facts
Facts are the data points available for building conditions. The available facts depend on the scope:
| Fact | What it evaluates |
| - | - |
| **Billing Frequency** | The billing cadence selected on the option. |
| **Currency Code** | The currency of the option. |
| **Discount %** | The overall discount percentage on the option. |
| **Recurring Discount %** | The discount percentage on recurring items only. |
| **List Price** | The total list price before adjustments. |
| **Final Rate** | The final rate after all adjustments. |
| **Product Count** | The number of distinct products on the option. |
| **Promotion Count** | The number of promotions applied. |
| **Year** | The year of the commitment (for multi-year deals). |
| **Total** | The total deal value. |
| **Recurring Total** | The total recurring value. |
| **One-time Total** | The total one-time value. |
| Fact | What it evaluates |
| - | - |
| **Product SKU** | The SKU of the line item. |
| **Product ID** | The internal product identifier. |
| **Product Name** | The display name of the product. |
| **Row Discount** | The discount percentage on this specific line. |
| **Category** | The [Product Category](/get-started/pricing-and-packaging/product-categories) of the line item. |
| **Row Total** | The total value of this line. |
| **Final Rate** | The final per-unit rate on this line. |
| **Total** | The line's total value. |
| **Recurring Total** | The recurring portion of this line. |
| **One-time Total** | The one-time portion of this line. |
| **Unit of Measure** | The [UOM](/get-started/pricing-and-packaging/units-of-measure) assigned to this product. |
### Operators
Compare facts against values using standard operators:
| Operator | Usage |
| - | - |
| **Equals** / **Not Equals** | Exact match or exclusion. |
| **Is Greater Than or Equal To** | Numeric threshold (inclusive). |
| **Is Less Than** | Numeric upper bound. |
| **Is In** / **Is None Of** | Match against a list of values (e.g., "SKU is in \[PLATFORM-001, ANALYTICS-001]"). |
### Multiple conditions
You can add multiple conditions to a single Rule Set (all must be true for the action to fire), or create **sub-conditions** that target the same row for more granular control.
**Example:** A rule that triggers when the discount is greater than 20% **and** the billing frequency is monthly **and** the product category is "Enterprise."
***
## Actions
When a Rule Set's conditions are met, the system takes an action. Actions have two components: a **message** and a **severity**.
### Message
A custom text message displayed to the rep on the quote. Write clear, actionable messages that explain what's wrong and what needs to happen.
**Good:** "Discount exceeds 20% on Enterprise products. Requires VP approval." **Bad:** "Rule violated."
### Severity
| Severity | Behavior |
| - | - |
| **Warn** | Flags a warning on the quote. The rep can see the alert but can still save and continue editing. The warning must be resolved (typically through approval) before publishing. |
| **Error** | Blocks the rep from saving or moving forward until the condition is resolved. Use for hard constraints that should never be violated (e.g., selling below cost). |
Start with **Warn** severity for most rules. This lets reps continue building the deal while surfacing the issue. Reserve **Error** severity for non-negotiable constraints where the deal configuration is fundamentally invalid.
***
## Approval triggers
Rules can require formal approval before the quote can be published.
1. Toggle **Requires Approver** on the Rule Set's action.
2. Select the **Approval Tier** from your predefined tiers (configured in [Approvals](/get-started/calculator/approvals)).
When the rule fires, the Publish button on the quote changes to **Request Approval**, and the deal is routed to the appropriate tier. The quote cannot be published until the approver signs off.
**Example setup:**
| Rule | Condition | Severity | Approval tier |
| - | - | - | - |
| Moderate discount | Discount 10-20% | Warn | Tier 1: Sales Manager |
| Large discount | Discount > 20% | Warn | Tier 2: VP of Sales |
| Below-cost pricing | Net price \< cost | Error | (blocks entirely) |
| Non-standard terms | Payment terms > Net-30 | Warn | Tier 3: Finance |
***
## Common rule patterns
### Maximum discount limit
* **Kind:** Quote Validation
* **Scope:** Option
* **Fact:** Discount %
* **Operator:** Is Greater Than or Equal To
* **Value:** 25
* **Action:** Warn, "Deal discount exceeds 25%. Requires Deal Desk approval."
* **Approval:** Tier 2 (Deal Desk)
### Product-specific discount cap
* **Kind:** Row Validation
* **Scope:** Row
* **Condition 1:** Product SKU equals `PLATFORM-001`
* **Condition 2:** Row Discount is Greater Than or Equal To 15
* **Action:** Warn, "Platform discount exceeds 15%. Requires manager approval."
* **Approval:** Tier 1 (Sales Manager)
### Required product bundling
* **Kind:** Quote Validation
* **Scope:** Option
* **Condition 1:** Category "Hardware" product count > 0
* **Condition 2:** Category "Shipping" product count equals 0
* **Action:** Error, "Hardware products require a Shipping line item."
### Multi-product bundle discount
* **Kind:** Pricing Rule
* **Scope:** Option
* **Condition:** Product Count is Greater Than or Equal To 3
* **Action:** Apply 5% automatic discount to all recurring line items.
***
## How rules connect to the rest of the platform
Rules don't operate in isolation. They reference and interact with multiple parts of the Veles configuration:
[**Product Categories**](/get-started/pricing-and-packaging/product-categories) can be used as conditions. Rules can fire based on which product families are present on a quote.
[**Data Sheets**](/get-started/pricing-and-packaging/data-sheets) can provide the reference values for rule conditions. A discount threshold data sheet keyed by customer segment allows different limits for Enterprise vs. SMB deals.
[**Custom Fields**](/get-started/pricing-and-packaging/product) on products and quote lines can be evaluated in rule conditions, enabling rules based on region, vertical, or other metadata.
[**Approval Tiers**](/get-started/calculator/approvals) are the escalation targets when rules require sign-off. The tier system and the org hierarchy determine who reviews the deal.
[**Quote Lines**](/get-started/calculator/quote-line) display rule alerts directly on the affected line item, giving reps immediate visibility into which lines triggered which rules.
***
## The workflow at a glance
Name it, describe it, set the kind, and activate it.
Choose the scope, select facts, set operators, and define the condition.
Write the message, set the severity (Warn or Error), and optionally enable approval routing with a specific tier.
Build a test quote that triggers the rule. Verify the alert appears, the message is clear, and the approval routes correctly.
***
## What's next
Rules that evaluate the entire Pricing Option.
Rules that automatically adjust pricing based on conditions.
Rules that evaluate individual line items.
Complex multi-variable logic using the formula engine.
Configure the approval tiers that rules route to.
Migrating from Salesforce CPQ? Map your existing rules to Veles.
# Pricing Rules
Source: https://docs.getveles.com/get-started/rules-and-approval/pricing-rules
Automatically adjust pricing based on deal conditions: bundle discounts, volume incentives, currency adjustments, and data-sheet-driven markups.
Pricing Rules automatically adjust the price on a quote without requiring manual intervention from the rep. Unlike [Quote Validation](/get-started/rules-and-approval/quote-validation) and [Row Validation](/get-started/rules-and-approval/untitled-page) rules (which warn or block), Pricing Rules change the numbers directly.
When a Pricing Rule fires, it produces a **System Adjustment** on the affected line items. This adjustment appears in the [pricing waterfall](/get-started/calculator/quote-line#the-pricing-waterfall) between the List Price and the System Price, giving both the rep and deal desk full visibility into what changed and why.
```text theme={null}
List Price (from price book)
↓
System Adjustment ← Pricing Rules apply here
↓
System Price (post-automation, pre-rep)
↓
Rep Discount (manual)
↓
Net Price
```
Pricing Rules run automatically as reps build quotes. The rep doesn't configure them -- they see the results as adjustments on the line items.
***
## When to use Pricing Rules
Pricing Rules are the right kind when:
* You want to **automatically discount or mark up** prices based on deal conditions
* The adjustment should happen **without rep intervention** (the system applies it)
* The logic depends on **what's on the deal** (product combinations, deal size, currency, category)
* You want the adjustment to be **visible and traceable** in the pricing waterfall (not hidden)
For rules that validate and block/warn without changing the price, use [Quote Validation](/get-started/rules-and-approval/quote-validation) or [Row Validation](/get-started/rules-and-approval/untitled-page). For complex multi-variable calculations, use [Formula Rules](/get-started/rules-and-approval/formula-rules).
***
## Creating a Pricing Rule
1. Navigate to **Admin Console > Price Books > Rules**.
2. Click **Create New Rule**.
3. Set the **Kind** to **Pricing Rule**.
4. Enter a **Name** and **Description**.
5. Set the **Status** to Active.
6. Click **Save**, then click **New Rule Set** to build the logic.
***
## Building the rule set
### Scope
Pricing Rules can evaluate at two levels:
* **Option** -- the rule looks at deal-level metrics (total value, product count, currency) and applies adjustments across line items.
* **Row** -- the rule looks at individual line items and applies adjustments to specific products.
### Available facts
| Fact | What it evaluates | Example use |
| - | - | - |
| **Product Count** | Number of distinct products on the option. | Apply bundle discount when 3+ products are present. |
| **Total** | Total deal value. | Apply volume incentive on large deals. |
| **Recurring Total** | Total recurring value. | Adjust pricing when ARR exceeds a threshold. |
| **One-time Total** | Total one-time value. | Discount services when bundled with recurring products. |
| **Currency Code** | The currency of the option. | Apply currency-specific markup for international deals. |
| **Billing Frequency** | The billing cadence. | Adjust pricing for monthly vs. annual billing. |
| **Discount %** | Overall discount percentage. | Cap or adjust the system discount based on deal-level discount. |
| **Year** | The year of the commitment. | Apply different rates for Year 1 vs. Year 2 in ramp deals. |
| Fact | What it evaluates | Example use |
| - | - | - |
| **Product SKU** | The SKU on this line. | Apply a specific adjustment to one product. |
| **Product Name** | The display name. | Target products by naming pattern. |
| **Category** | The [Product Category](/get-started/pricing-and-packaging/product-categories). | Apply category-wide adjustments. |
| **Row Total** | The line's total value. | Adjust lines above a certain value. |
| **Final Rate** | The per-unit rate. | Adjust the rate based on thresholds. |
| **Unit of Measure** | The [UOM](/get-started/pricing-and-packaging/units-of-measure). | Target consumption-based products differently. |
### Operators
Same operators as other rule types: Equals, Not Equals, Is Greater Than or Equal To, Is Less Than, Is In, Is None Of.
***
## Actions: the adjustment
When a Pricing Rule's conditions are met, the action is a **price adjustment** rather than a message. The adjustment modifies the System Adjustment column on affected line items.
### Adjustment types
| Type | What it does | Example |
| - | - | - |
| **Percentage discount** | Reduces the price by a percentage. | -5% bundle discount on all recurring lines. |
| **Percentage markup** | Increases the price by a percentage. | +8% currency adjustment for EUR deals. |
| **Fixed amount discount** | Reduces the price by a dollar amount. | -\$500 on the implementation fee when bundled. |
| **Fixed amount markup** | Increases the price by a dollar amount. | +\$1,000 surcharge for expedited onboarding. |
### Adjustment scope
You can control which line items the adjustment applies to:
* **All lines** -- the adjustment is applied to every line item on the option.
* **Recurring lines only** -- only recurring products are affected (one-time fees are excluded).
* **One-time lines only** -- only one-time products are affected.
* **Specific lines** -- target lines matching a specific SKU, category, or other row-level fact.
***
## Pricing Rules and Data Sheets
For dynamic adjustments that vary by customer attribute, region, or other external data, Pricing Rules can reference [Data Sheets](/get-started/pricing-and-packaging/data-sheets).
Instead of hard-coding a percentage into the rule, the rule looks up the adjustment value from a Data Sheet at quoting time. This means you can change the adjustment by updating the Data Sheet without editing the rule itself.
**Example:** A currency adjustment rule that looks up the markup percentage from an `FX_Adjustments` Data Sheet based on the deal's currency code. EUR gets +8%, GBP gets +5%, JPY gets +12%. When rates change, you update the Data Sheet -- the rule itself stays the same.
***
## Examples
### Multi-product bundle discount
Automatically discount when a customer buys multiple products together.
| Setting | Value |
| - | - |
| **Name** | 3+ Product Bundle Discount |
| **Kind** | Pricing Rule |
| **Scope** | Option |
| **Condition** | Product Count ≥ 3 |
| **Action** | -5% on all recurring lines |
When a rep adds a third product to the option, the 5% discount appears automatically as a System Adjustment on every recurring line item.
### Currency markup
Adjust pricing for international deals to account for currency-specific costs.
| Setting | Value |
| - | - |
| **Name** | EUR Currency Adjustment |
| **Kind** | Pricing Rule |
| **Scope** | Option |
| **Condition** | Currency Code equals EUR |
| **Action** | +8% on all lines |
All line items on EUR-denominated deals receive an automatic 8% markup. The rep sees the adjustment in the System Adjustment column but doesn't need to apply it manually.
### Annual billing incentive
Offer a discount for customers who choose annual over monthly billing.
| Setting | Value |
| - | - |
| **Name** | Annual Billing Discount |
| **Kind** | Pricing Rule |
| **Scope** | Option |
| **Condition** | Billing Frequency equals Annual |
| **Action** | -10% on recurring lines only |
Customers paying annually get a 10% discount on recurring line items. Monthly customers pay the full rate. The rep sees the incentive applied automatically when they select annual billing.
### Category-specific adjustment
Apply a margin-protection markup to a low-margin product category.
| Setting | Value |
| - | - |
| **Name** | Hardware Margin Protection |
| **Kind** | Pricing Rule |
| **Scope** | Row |
| **Condition** | Category equals "Hardware" |
| **Action** | +3% on matching lines |
Every Hardware product receives an automatic 3% markup. Software and Services products are unaffected.
### Volume incentive on large deals
Reward large commitments with an automatic discount.
| Setting | Value |
| - | - |
| **Name** | Enterprise Volume Incentive |
| **Kind** | Pricing Rule |
| **Scope** | Option |
| **Condition** | Recurring Total ≥ 100000 |
| **Action** | -3% on all recurring lines |
Deals with \$100k+ in recurring revenue receive a 3% automatic discount. The rep sees it applied to every recurring line item, and can apply additional discretionary discounts on top.
### Data-sheet-driven regional adjustment
Use a Data Sheet to vary the adjustment by region.
| Setting | Value |
| - | - |
| **Name** | Regional Pricing Adjustment |
| **Kind** | Pricing Rule |
| **Scope** | Option |
| **Condition** | Currency Code is not equal to USD |
| **Action** | Apply markup from `Regional_Adjustments` Data Sheet, keyed by Currency Code |
The Data Sheet contains the markup for each currency. The rule looks up the value at quoting time and applies it. No hard-coded percentages in the rule.
***
## How Pricing Rules interact with rep discounts
Pricing Rules and rep discounts operate in different stages of the [pricing waterfall](/get-started/calculator/quote-line#the-pricing-waterfall):
1. **List Price** is calculated from the price book.
2. **System Adjustment** is applied by Pricing Rules (automatic).
3. **System Price** = List Price + System Adjustment.
4. **Rep Discount** is applied manually by the rep.
5. **Net Price** = System Price - Rep Discount.
This means the rep's discount is applied *after* the Pricing Rule adjustment. If a Pricing Rule applies a -5% bundle discount and the rep adds a -10% discretionary discount, the total discount stacks (though [Validation Rules](/get-started/rules-and-approval/quote-validation) may flag the combined discount if it exceeds a threshold).
The System Adjustment column gives full transparency into what the system changed versus what the rep changed. Deal desk and approvers can see both adjustments independently.
***
## Tips
**Make adjustments visible.** The whole point of the System Adjustment column is transparency. Don't use Pricing Rules to hide discounts -- use them to systematize discounts that your organization has already decided to offer.
**Combine with Validation Rules.** A Pricing Rule might automatically apply a -5% bundle discount, but a Quote Validation Rule should still enforce that the total discount (system + rep) doesn't exceed your maximum threshold.
**Use Data Sheets for variable adjustments.** If the adjustment varies by region, customer segment, or product tier, put the values in a [Data Sheet](/get-started/pricing-and-packaging/data-sheets) rather than creating separate rules for each variation.
**Test stacking behavior.** Multiple Pricing Rules can fire on the same quote. Make sure the combined adjustments produce the expected result. Build a test quote that triggers multiple rules and verify the System Adjustment totals.
***
## What's next
Enforce deal-level constraints that warn or block.
Enforce line-item-level constraints.
Complex multi-variable pricing logic.
Reference tables for dynamic, data-driven adjustments.
# Quote Validation Rules
Source: https://docs.getveles.com/get-started/rules-and-approval/quote-validation
Enforce deal-level guardrails that evaluate the entire Pricing Option: discount limits, required products, billing constraints, and approval triggers.
Quote Validation Rules evaluate the entire [Pricing Option](/get-started/calculator/quote-options) as a whole. They're designed for "big picture" guardrails -- constraints that apply to the overall deal structure rather than individual line items.
Use Quote Validation Rules when the condition depends on aggregated deal metrics (total discount, TCV, product count, recurring vs. one-time split) or when the constraint is about the deal composition (required products, billing frequency restrictions, minimum deal sizes).
For rules that evaluate individual line items, use [Row Validation Rules](/get-started/rules-and-approval/untitled-page) instead.
***
## When to use Quote Validation
Quote Validation is the right kind when:
* The condition involves **deal-level totals** (total discount %, TCV, recurring total, product count)
* You need to enforce a constraint about **what's on the deal** (e.g., certain products must always appear together)
* The rule applies regardless of which specific line item triggered it
* The approval or block should apply to the **entire option**, not a single line
***
## Creating a Quote Validation Rule
1. Navigate to **Admin Console > Price Books > Rules**.
2. Click **Create New Rule**.
3. Set the **Kind** to **Quote Validation**.
4. Enter a **Name** and **Description**.
5. Set the **Status** to Active.
6. Click **Save**, then click **New Rule Set** to build the logic.
***
## Building the rule set
### Scope
For Quote Validation rules, the scope is always **Option** -- the rule evaluates the Pricing Option as a whole.
### Available facts
These are the data points you can build conditions against:
| Fact | What it evaluates | Example condition |
| - | - | - |
| **Discount %** | The overall discount percentage across all line items. | Discount % is greater than or equal to 25 |
| **Recurring Discount %** | The discount on recurring items only (excludes one-time fees). | Recurring Discount % is greater than 20 |
| **Total** | The total deal value after all adjustments. | Total is less than 5000 |
| **Recurring Total** | The total recurring value (ARR). | Recurring Total is less than 10000 |
| **One-time Total** | The total one-time value (services, setup fees). | One-time Total is greater than or equal to 50000 |
| **List Price** | The total list price before any adjustments or discounts. | List Price is greater than or equal to 100000 |
| **Final Rate** | The final blended rate across the option. | Final Rate is less than 30 |
| **Product Count** | The number of distinct products on the option. | Product Count equals 1 |
| **Promotion Count** | The number of promotions applied. | Promotion Count is greater than or equal to 2 |
| **Billing Frequency** | The billing cadence selected. | Billing Frequency equals Monthly |
| **Currency Code** | The currency of the option. | Currency Code equals EUR |
| **Year** | The year of the commitment (for multi-year deals). | Year equals 1 |
### Operators
| Operator | Usage |
| - | - |
| **Equals** / **Not Equals** | Exact match. "Billing Frequency equals Annual." |
| **Is Greater Than or Equal To** | Numeric threshold. "Discount % ≥ 20." |
| **Is Less Than** | Numeric upper bound. "Total \< 5000." |
| **Is In** / **Is None Of** | Match against a list. "Currency Code is in \[USD, CAD]." |
### Combining conditions
Add multiple conditions to a single Rule Set. All conditions must be true for the action to fire.
**Example:** A rule that triggers only when the discount exceeds 20% **and** the billing frequency is monthly **and** the deal is in EUR:
* Condition 1: Discount % ≥ 20
* Condition 2: Billing Frequency equals Monthly
* Condition 3: Currency Code equals EUR
***
## Actions
When the conditions are met, configure what happens:
### Message
Write the text the rep sees on the quote. Be specific about what's wrong and what needs to happen.
**Good examples:**
* "Deal discount exceeds 25%. Requires VP of Sales approval before publishing."
* "Monthly billing is not available for deals under \$10,000 ARR. Switch to annual billing or increase the deal size."
* "A Support product is required when the recurring total exceeds \$50,000."
### Severity
| Severity | What it does |
| - | - |
| **Warn** | Displays an alert on the Pricing Option. The rep can continue building the quote but cannot publish until the warning is resolved (typically through approval). |
| **Error** | Blocks the rep from saving. The deal configuration must be changed to resolve the error. No approval path -- the condition itself must be fixed. |
### Approval routing
Toggle **Requires Approver** and select an [Approval Tier](/get-started/calculator/approvals) to route the deal for formal review. When triggered, the Publish button changes to Request Approval and the deal is routed to the appropriate tier.
***
## Examples
### Maximum discount limit
Prevent reps from offering more than 25% off without deal desk review.
| Setting | Value |
| - | - |
| **Name** | Maximum Discount Limit |
| **Kind** | Quote Validation |
| **Scope** | Option |
| **Condition** | Discount % ≥ 25 |
| **Severity** | Warn |
| **Message** | "Deal discount exceeds 25%. Requires Deal Desk approval." |
| **Approval** | Tier 2: Deal Desk |
### Minimum deal size
Block deals below a minimum ARR threshold.
| Setting | Value |
| - | - |
| **Name** | Minimum Deal Size |
| **Kind** | Quote Validation |
| **Scope** | Option |
| **Condition** | Recurring Total \< 10000 |
| **Severity** | Error |
| **Message** | "Recurring total is below the \$10,000 minimum. Add products or adjust quantities." |
| **Approval** | None (Error blocks the deal) |
### Billing frequency restriction
Require annual billing for deals under a certain size.
| Setting | Value |
| - | - |
| **Name** | Monthly Billing Restriction |
| **Kind** | Quote Validation |
| **Scope** | Option |
| **Conditions** | Billing Frequency equals Monthly **AND** Recurring Total \< 25000 |
| **Severity** | Error |
| **Message** | "Monthly billing is only available for deals with \$25,000+ ARR. Switch to annual billing." |
| **Approval** | None |
### Required product bundling
Ensure that certain products always appear together.
| Setting | Value |
| - | - |
| **Name** | Require Support on Large Deals |
| **Kind** | Quote Validation |
| **Scope** | Option |
| **Conditions** | Recurring Total ≥ 50000 **AND** Product Count for Category "Support" equals 0 |
| **Severity** | Warn |
| **Message** | "Deals over \$50,000 ARR require a Support product. Add Premium or Standard Support." |
| **Approval** | Tier 1: Sales Manager (if rep wants to override) |
### Tiered discount approvals
Route deals to different approvers based on how deep the discount goes.
This requires **two separate rules**, each targeting a different threshold:
**Rule 1: Moderate discount**
| Setting | Value |
| - | - |
| **Condition** | Discount % ≥ 15 AND Discount % \< 25 |
| **Severity** | Warn |
| **Approval** | Tier 1: Sales Manager |
**Rule 2: Large discount**
| Setting | Value |
| - | - |
| **Condition** | Discount % ≥ 25 |
| **Severity** | Warn |
| **Approval** | Tier 2: VP of Sales |
Both rules can be active simultaneously. A 20% discount triggers Rule 1 (manager approval). A 30% discount triggers both, requiring sign-off from both tiers.
***
## Tips for effective Quote Validation Rules
**Start with discount limits.** This is the highest-impact rule for most organizations and the easiest to configure. Set a reasonable threshold, wire it to an approval tier, and iterate from there.
**Use Error severity sparingly.** Errors block the rep entirely. Reserve them for hard constraints (minimum deal size, incompatible billing configurations) where the deal fundamentally can't proceed. For everything else, Warn + Approval gives the rep a path forward.
**Write actionable messages.** The message should tell the rep what's wrong and what to do about it. "Rule violated" is useless. "Deal discount exceeds 25%. Requires Deal Desk approval before publishing" tells them exactly where they stand.
**Test before activating.** Build a test quote that deliberately triggers the rule. Verify the alert appears on the Pricing Option, the message is clear, and the approval routes to the right tier.
***
## What's next
Automatically adjust pricing based on deal conditions.
Enforce guardrails at the individual line item level.
Configure the approval tiers that validation rules route to.
Overview of the rules engine: kinds, scopes, facts, and operators.
# Row Validation Rules
Source: https://docs.getveles.com/get-started/rules-and-approval/rwo-validation
Enforce line-item-level guardrails that evaluate individual products on a quote: discount caps, price floors, quantity minimums, and product-specific approvals.
Row Validation Rules evaluate individual [Quote Lines](/get-started/calculator/quote-line) -- single products on a Pricing Option. Unlike [Quote Validation Rules](/get-started/rules-and-approval/quote-validation), which look at the deal as a whole, Row Validation targets specific products or line items and surfaces feedback directly on the affected row.
The primary advantage is **granularity**. When a Row Validation rule fires, the alert appears on the exact line item that triggered it. The rep doesn't have to search through a long quote to figure out which product has a problem -- the issue is flagged right where it occurs.
Use Row Validation Rules when the condition is about a specific product's pricing, discount, quantity, or category -- not the overall deal structure.
***
## When to use Row Validation
Row Validation is the right kind when:
* The condition applies to a **specific product or SKU** (not the deal total)
* You need to enforce a **per-line discount cap** or **price floor**
* The rule should fire for a **specific product category** regardless of what else is on the deal
* You want the alert to appear **on the line item itself** for immediate clarity
* The constraint involves **quantity minimums** or **unit-level pricing** for a particular product
For deal-level constraints (total discount, TCV thresholds, required product combinations), use [Quote Validation Rules](/get-started/rules-and-approval/quote-validation) instead.
***
## Creating a Row Validation Rule
1. Navigate to **Admin Console > Price Books > Rules**.
2. Click **Create New Rule**.
3. Set the **Kind** to **Row Validation**.
4. Enter a **Name** and **Description**.
5. Set the **Status** to Active.
6. Click **Save**, then click **New Rule Set** to build the logic.
***
## Building the rule set
### Scope
For Row Validation rules, the scope is **Row** -- the rule evaluates each line item individually. If a quote has 5 line items, the rule is checked against each of the 5 independently.
### Available facts
These are the data points you can build conditions against for each line item:
| Fact | What it evaluates | Example condition |
| - | - | - |
| **Product SKU** | The SKU of the product on this line. | Product SKU equals `PLATFORM-001` |
| **Product ID** | The internal product identifier. | Product ID equals `prod_abc123` |
| **Product Name** | The display name of the product. | Product Name contains "Integration" |
| **Row Discount** | The discount percentage applied to this specific line. | Row Discount ≥ 15 |
| **Category** | The [Product Category](/get-started/pricing-and-packaging/product-categories) of the line item. | Category equals "Professional Services" |
| **Row Total** | The total value of this line after adjustments. | Row Total \< 500 |
| **Final Rate** | The final per-unit rate on this line. | Final Rate \< 25 |
| **Total** | The line's total value. | Total ≥ 100000 |
| **Recurring Total** | The recurring portion of this line's value. | Recurring Total \< 1000 |
| **One-time Total** | The one-time portion of this line's value. | One-time Total ≥ 50000 |
| **Unit of Measure** | The [UOM](/get-started/pricing-and-packaging/units-of-measure) assigned to this product. | Unit of Measure equals "Per User" |
### Operators
| Operator | Usage |
| - | - |
| **Equals** / **Not Equals** | Exact match. "Product SKU equals PLATFORM-001." |
| **Is Greater Than or Equal To** | Numeric threshold. "Row Discount ≥ 15." |
| **Is Less Than** | Numeric upper bound. "Final Rate \< 25." |
| **Is In** / **Is None Of** | Match against a list. "Category is in \[Hardware, Equipment]." |
| **Contains** | Partial text match. "Product Name contains Integration." |
### Combining conditions
Add multiple conditions to target a specific product with a specific constraint. All conditions must be true for the action to fire.
**Example:** A rule that triggers only on the Platform product when its discount exceeds 15%:
* Condition 1: Product SKU equals `PLATFORM-001`
* Condition 2: Row Discount ≥ 15
Without the SKU condition, the discount rule would fire on every line item. Adding the SKU condition scopes it to one product.
***
## Actions
### Message
The message appears directly on the affected line item. Write messages that are specific to the product and the problem, since the rep is looking at the exact row.
**Good examples:**
* "Platform discount exceeds 15%. Requires Sales VP approval."
* "This custom integration requires an engineering scoping call before the quote is sent."
* "Minimum order quantity for this product is 10 units."
* "This product cannot be sold below \$500/unit."
### Severity
| Severity | What it does |
| - | - |
| **Warn** | Displays a warning icon on the line item. The rep can continue editing but cannot publish until the warning is resolved (through approval or by changing the line). |
| **Error** | Blocks the rep from saving. The line item must be corrected before the quote can be saved. |
### Approval routing
Toggle **Requires Approver** and select an [Approval Tier](/get-started/calculator/approvals). When the row rule fires, the deal is routed for approval at the specified tier. The alert on the line item shows which tier needs to sign off.
***
## Examples
### Per-product discount cap
Limit the discount on a high-margin product that reps tend to over-discount.
| Setting | Value |
| - | - |
| **Name** | Platform Discount Cap |
| **Kind** | Row Validation |
| **Scope** | Row |
| **Conditions** | Product SKU equals `PLATFORM-001` **AND** Row Discount ≥ 15 |
| **Severity** | Warn |
| **Message** | "Platform discount exceeds 15%. Requires VP approval." |
| **Approval** | Tier 2: VP of Sales |
### Price floor
Prevent a product from being sold below cost.
| Setting | Value |
| - | - |
| **Name** | Analytics Price Floor |
| **Kind** | Row Validation |
| **Scope** | Row |
| **Conditions** | Product SKU equals `ANALYTICS-001` **AND** Final Rate \< 25 |
| **Severity** | Error |
| **Message** | "Analytics cannot be sold below \$25/user. This is below the cost floor." |
| **Approval** | None (Error blocks the deal) |
### Quantity minimum
Enforce a minimum order quantity for a specific product.
| Setting | Value |
| - | - |
| **Name** | Hardware Minimum Order |
| **Kind** | Row Validation |
| **Scope** | Row |
| **Conditions** | Category equals "Hardware" **AND** Quantity \< 10 |
| **Severity** | Error |
| **Message** | "Hardware products must be purchased in quantities of 10 or more." |
| **Approval** | None |
### Engineering review flag
Flag products that need technical review before the deal is sent to the buyer.
| Setting | Value |
| - | - |
| **Name** | Integration Engineering Review |
| **Kind** | Row Validation |
| **Scope** | Row |
| **Conditions** | Product Name contains "Integration" |
| **Severity** | Warn |
| **Message** | "This integration requires an engineering scoping call. Attach the vetting form to the opportunity before publishing." |
| **Approval** | Tier 2: Deal Desk |
### Category-wide discount limit
Apply a discount cap to an entire product category rather than individual SKUs.
| Setting | Value |
| - | - |
| **Name** | Services Discount Limit |
| **Kind** | Row Validation |
| **Scope** | Row |
| **Conditions** | Category equals "Professional Services" **AND** Row Discount ≥ 10 |
| **Severity** | Warn |
| **Message** | "Professional Services discount exceeds 10%. Requires manager approval." |
| **Approval** | Tier 1: Sales Manager |
***
## The rep experience
When a Row Validation rule fires on a line item:
1. A **warning or error icon** appears directly on the affected row in the Calculator.
2. Clicking or hovering on the icon displays the custom message.
3. If severity is **Warn**, the rep can continue building the quote but cannot publish until the issue is resolved (either by fixing the line or getting approval).
4. If severity is **Error**, the rep must fix the line item (adjust price, discount, or quantity) before the quote can be saved.
5. If an approval is required, the line-level alert shows which tier needs to sign off.
Because the alert is on the specific row, the rep knows exactly which product needs attention. For quotes with many line items, this is significantly clearer than a deal-level alert that says "something on this quote needs review."
***
## Row Validation vs. Quote Validation
| | Row Validation | Quote Validation |
| - | - | - |
| **Evaluates** | Individual line items | The entire Pricing Option |
| **Alert location** | On the specific row | On the option header |
| **Best for** | Per-product constraints (discount caps, price floors, MOQ) | Deal-level constraints (total discount, TCV, required products) |
| **Scoping** | Can target specific SKUs, categories, or product names | Evaluates aggregate metrics across all lines |
| **When to use** | "This product can't be discounted more than 15%" | "The total deal discount can't exceed 25%" |
You can (and should) use both kinds together. Row Validation handles product-specific guardrails. Quote Validation handles deal-level guardrails. They complement each other.
***
## What's next
Deal-level rules that evaluate the entire Pricing Option.
Automatically adjust pricing based on conditions.
Complex multi-variable logic using the formula engine.
Overview of the rules engine: kinds, scopes, facts, and operators.
# Translating SFDC Rules to Veles
Source: https://docs.getveles.com/get-started/rules-and-approval/translating-sfdc-rules-to-veles
Migrate your Salesforce CPQ rules to Veles: understand how SFDC rule types map to Veles, review your existing rules, and build equivalents.
If you're migrating from Salesforce CPQ (formerly Steelbricks), your existing rule logic doesn't need to be rebuilt from scratch. Veles provides tooling to review your Salesforce CPQ rules directly in the Veles interface and a clear mapping between the two systems' rule architectures.
This guide walks through how Salesforce CPQ rule types translate to Veles rule types, how to use the CPQ Configuration view to audit your existing rules, and common patterns you'll encounter during migration.
***
## The CPQ Configuration view
When your Salesforce instance is [connected](/get-started/quickstart/connect-your-crm), Veles can read your existing Salesforce CPQ rules and display them in a **CPQ Configuration** tab. This view shows the original SFDC rule details alongside the Veles rule configuration, so you can review and translate rules without switching between systems.
For each imported rule, the CPQ Configuration tab shows:
| Field | Description |
| - | - |
| **Rule Name** | The original Salesforce CPQ rule name. |
| **Rule ID** | The Salesforce record ID for reference. |
| **Active** | Whether the rule is active in Salesforce. |
| **Conditions Met** | The condition logic (All, Any, or Custom). |
| **Error Message** | The message displayed when the rule fires. |
| **Evaluation Event** | When the rule evaluates (Save, Calculate, Always). |
| **Evaluation Order** | The numeric order in which rules are processed. |
| **Scope** | Quote or Calculator. |
| **Type** | The SFDC rule type (Validation, Alert, Selection, Filter). |
The condition rows show the full SFDC condition structure: the tested object, tested field, operator, filter type, and filter value for each condition in the rule.
A **View in CPQ** button links back to the original rule in Salesforce for side-by-side comparison.
***
## How SFDC rule types map to Veles
Salesforce CPQ has a different rule taxonomy than Veles. Here's how the major rule types translate:
### Product Rules
Salesforce CPQ Product Rules enforce constraints on product configuration and selection. They come in several subtypes:
| SFDC Product Rule type | Veles equivalent | Notes |
| - | - | - |
| **Validation** (Error/Warning on quote) | [Quote Validation Rule](/get-started/rules-and-approval/quote-validation) or [Row Validation Rule](/get-started/rules-and-approval/untitled-page) | Use Quote Validation for deal-level checks. Use Row Validation for line-item checks. Veles separates these into two kinds; SFDC combines them under Product Rules with scope. |
| **Selection** (auto-add/remove products) | [Pricing Rule](/get-started/rules-and-approval/pricing-rules) with product logic | Veles Pricing Rules can automate product-level adjustments. For complex auto-add logic, use [Formula Rules](/get-started/rules-and-approval/formula-rules). |
| **Filter** (restrict product selection) | [Product Filters](/get-started/pricing-and-packaging/product-filters) | Veles handles product visibility through the filter system on the price book, not through rules. |
| **Alert** (display message without blocking) | Quote or Row Validation with **Warn** severity | In Veles, the severity level (Warn vs. Error) controls whether the rule blocks or just alerts. |
### Price Rules
Salesforce CPQ Price Rules automatically adjust field values on quote lines based on conditions. They're the closest equivalent to Veles [Pricing Rules](/get-started/rules-and-approval/pricing-rules).
| SFDC Price Rule concept | Veles equivalent |
| - | - |
| Price condition (the "if") | Pricing Rule condition (scope + facts + operators) |
| Price action (the "then") | Pricing Rule adjustment (percentage or fixed amount) |
| Lookup-based pricing | [Data Sheet](/get-started/pricing-and-packaging/data-sheets) + VLOOKUP in a [Formula Rule](/get-started/rules-and-approval/formula-rules) |
### Approval Rules
Salesforce CPQ uses Advanced Approvals (or standard Salesforce approvals) to route deals. Veles handles this through the [Approvals](/get-started/calculator/approvals) system with tier-based routing.
| SFDC Approval concept | Veles equivalent |
| - | - |
| Approval rule conditions | Any rule kind with **Requires Approver** toggled on |
| Approval chain / steps | [Approval Tiers](/get-started/calculator/approvals) (Tier 1 → Tier 2 → Tier 3) |
| Approver assignment | Org hierarchy-based routing via [manager relationships](/get-started/quickstart/adding-users#manager) |
***
## Key structural differences
Understanding these differences will help you translate rules more effectively:
### Scope is separated, not embedded
In Salesforce CPQ, a single Product Rule can have conditions that evaluate at the quote level or the line level, determined by the Tested Object and scope fields. In Veles, this is split into distinct rule kinds: [Quote Validation](/get-started/rules-and-approval/quote-validation) for deal-level and [Row Validation](/get-started/rules-and-approval/untitled-page) for line-level. You may need to split one SFDC rule into two Veles rules.
### Condition logic is explicit
SFDC CPQ uses "Conditions Met" (All, Any, Custom) to control how multiple conditions are combined. In Veles, conditions within a single Rule Set are always AND-ed (all must be true). For OR logic, create multiple Rule Sets on the same rule -- each Rule Set is evaluated independently.
### Evaluation order is simplified
SFDC CPQ uses explicit Evaluation Order numbers (100, 200, 800, etc.) to control which rules run first. Veles evaluates all active rules simultaneously against the current quote state. If you have rules with order-dependent logic in SFDC (where Rule A's output affects Rule B's input), you may need to restructure them as a single [Formula Rule](/get-started/rules-and-approval/formula-rules) in Veles.
### Error messages are per-rule, not per-condition
In SFDC CPQ, the error message is set at the Product Rule level and fires when the condition set is met. Veles works the same way -- the message is set on the Rule Set action and displays when conditions are met. This maps directly.
### Lookup-based rules use Data Sheets
SFDC CPQ Price Rules can look up values from custom objects or related records. In Veles, this is handled through [Data Sheets](/get-started/pricing-and-packaging/data-sheets) -- reference tables that rules and formulas can query via VLOOKUP. If your SFDC rules reference custom objects for pricing logic, migrate that data into Data Sheets.
***
## The translation process
Review all active Product Rules, Price Rules, and Approval Rules in your Salesforce CPQ instance. Use the CPQ Configuration tab in Veles to see them in one place. For each rule, note the type, conditions, actions, and business purpose.
Map each SFDC rule to its Veles equivalent using the tables above. Flag any rules that need to be split (one SFDC rule → two Veles rules) or restructured (order-dependent logic → single Formula Rule).
If your SFDC rules reference custom objects, picklist values, or related records for pricing logic, migrate that data into [Data Sheets](/get-started/pricing-and-packaging/data-sheets). Set up [Product Categories](/get-started/pricing-and-packaging/product-categories) and [Custom Fields](/get-started/pricing-and-packaging/product) in Veles to match the dimensions your SFDC rules evaluate against.
Create each rule in Veles using the appropriate kind. Configure the scope, conditions, actions, severity, and approval routing. Reference Data Sheets where SFDC rules used lookups.
Build test quotes that trigger each rule. Compare the behavior against the same scenario in your SFDC CPQ environment. Verify that the alert messages, blocking behavior, and approval routing match your expectations.
Once validated, activate the Veles rules and deactivate the corresponding SFDC CPQ rules. Keep the SFDC rules in an inactive state initially (rather than deleting) so you can reference them if issues arise.
***
## Common translation patterns
### SFDC Validation → Veles Quote Validation
An SFDC Product Rule of type Validation with scope Quote that checks whether the total discount exceeds a threshold.
**In Salesforce CPQ:**
* Type: Validation
* Scope: Quote
* Condition: `SBQQ__NetPrice__c` related, discount threshold
* Error Message: "Discount exceeds maximum."
**In Veles:**
* Kind: [Quote Validation](/get-started/rules-and-approval/quote-validation)
* Scope: Option
* Fact: Discount %
* Operator: Is Greater Than or Equal To
* Severity: Warn
* Message: "Discount exceeds maximum. Requires approval."
* Approval: Tier configured
### SFDC Line-level Validation → Veles Row Validation
An SFDC Product Rule that validates a condition on specific quote lines (e.g., minimum quantity for a SKU).
**In Salesforce CPQ:**
* Type: Validation
* Scope: Quote (but condition tests `SBQQ__QuoteLine__c` fields)
* Condition: Product-specific, quantity threshold
**In Veles:**
* Kind: [Row Validation](/get-started/rules-and-approval/untitled-page)
* Scope: Row
* Conditions: Product SKU equals target **AND** quantity threshold
* Severity: Error
Note the scope difference: SFDC may use Quote scope with line-level tested fields. Veles separates this cleanly into Row Validation.
### SFDC Price Rule → Veles Pricing Rule
An SFDC Price Rule that adjusts the net price based on a condition (e.g., bundle discount when multiple products are present).
**In Salesforce CPQ:**
* Price Condition: Product count or specific SKU presence
* Price Action: Set discount or adjust target field
**In Veles:**
* Kind: [Pricing Rule](/get-started/rules-and-approval/pricing-rules)
* Scope: Option
* Condition: Product Count ≥ threshold
* Action: Percentage discount on matching lines
### SFDC Lookup Price Rule → Veles Formula Rule + Data Sheet
An SFDC Price Rule that uses a Summary Variable or custom object lookup to determine the adjustment.
**In Salesforce CPQ:**
* Summary Variable calculates aggregate value
* Price Action references the summary
**In Veles:**
* Migrate the lookup data into a [Data Sheet](/get-started/pricing-and-packaging/data-sheets)
* Build a [Formula Rule](/get-started/rules-and-approval/formula-rules) that uses VLOOKUP to query the Data Sheet
* Apply the looked-up value as the condition threshold or adjustment amount
***
## What doesn't translate directly
Some Salesforce CPQ features don't have a 1:1 equivalent in Veles and require a different approach:
**Twin Fields.** SFDC CPQ uses twin fields (`SBQQ__` custom fields) on quote and quote line objects. Veles uses its own field model. Map SFDC twin fields to the appropriate Veles [facts](/get-started/rules-and-approval/learn-the-basics#available-facts) (for rules) or [custom fields](/get-started/pricing-and-packaging/product) (for data).
**Summary Variables.** SFDC CPQ Summary Variables aggregate values across quote lines. In Veles, use the list processing functions (FILTER, MAP, SUM) in [Formula Rules](/get-started/rules-and-approval/formula-rules) to replicate this behavior.
**Product Selection rules (auto-add).** SFDC CPQ can automatically add or remove products from a quote. Veles doesn't auto-add products via rules. Required product bundling is handled through validation rules that warn or block when a required product is missing, prompting the rep to add it manually.
**Configuration Attributes.** SFDC CPQ Configuration Attributes (for guided selling) don't have a direct equivalent. In Veles, product configuration is handled through the pricing plan, [custom fields](/get-started/pricing-and-packaging/product), and the [Calculator](/get-started/calculator/quote-options) interface.
***
## Tips for migration
**Don't translate 1:1 blindly.** SFDC CPQ rules often accumulate over years and include workarounds for platform limitations. Use the migration as an opportunity to simplify. Ask "what business outcome does this rule enforce?" and build the simplest Veles rule that achieves it.
**Consolidate where possible.** Multiple SFDC rules that enforce related logic (e.g., three rules for different discount thresholds) might map to a single Veles rule with tiered approvals, or a single Formula Rule with CASE logic.
**Prioritize by impact.** Start with the rules that affect the most quotes: discount limits, required products, billing restrictions. Translate edge-case rules last.
**Keep SFDC rules inactive, not deleted.** During the transition period, deactivate SFDC rules rather than deleting them. If a Veles rule doesn't behave as expected, you can reactivate the SFDC rule while you debug.
***
## What's next
Overview of the Veles rules engine.
Build complex logic for rules that don't map to simple kinds.
Migrate SFDC lookup data into Veles reference tables.
Set up the Salesforce connection to access the CPQ Configuration view.
# MCP Server
Source: https://docs.getveles.com/get-started/veles-mcp
Connect Veles to AI assistants like Claude, Cursor, and Windsurf using the Model Context Protocol.
The Veles MCP Server is currently in **beta**. Tools, schemas, and behavior may change as we iterate. We'd love your feedback — reach out at [founders@getveles.com](mailto:founders@getveles.com).
## What is MCP?
The [Model Context Protocol (MCP)](https://modelcontextprotocol.io) is an open standard that lets AI assistants connect to external tools and data sources. Think of it like a USB-C port for AI — a single, standardized way to plug models into the systems they need to do real work.
Veles exposes an MCP server that gives AI assistants direct access to your proposals, quotes, products, pricing rules, and approval workflows. This means you can use natural language to build quotes, check deal status, look up pricing, and manage approvals — all without leaving your AI assistant.
### Why it matters
Instead of switching between tabs, copying data, and manually entering line items, your AI assistant can talk directly to Veles. A sales rep using Claude can say *"Create a new proposal for Acme Corp with our Growth plan at 100 seats"* and the assistant will handle it end-to-end through the MCP server.
## Getting started
### Connect in Claude
The fastest way to get started is through Claude's built-in connector:
In [Claude](https://claude.ai), navigate to **Settings** → **Connectors** (or click the connectors icon in the chat input).
Find **Veles** in the connector directory and click **Connect**.
Sign in with your Veles account to grant Claude access. You'll see a permissions screen showing which tools are available.
That's it. Claude now has access to your Veles workspace. Try asking: *"List my open proposals"* or *"What products do we have?"*
### Connect in other MCP clients
For AI tools that support remote MCP servers (Cursor, Windsurf, Claude Code, OpenAI Agents, etc.), point your client at:
```
https://app.getveles.com/mcp
```
The server uses OAuth for authentication. Your MCP client will handle the auth flow automatically when you first connect.
### Tool permissions
Once connected, you'll see two categories of tools:
* **Read-only tools** — Always allowed by default. These fetch data from Veles without making any changes.
* **Write tools** — Require explicit approval (or custom permission settings) before the AI assistant can execute them.
You can adjust these permissions at any time in your MCP client's settings.
## Tools
The Veles MCP Server exposes 22 tools organized across four areas: proposals, quotes, products and pricing, and approvals.
### Proposals
Proposals (also called opportunities or deals) are the top-level container for a deal in Veles.
| Tool | Type | Description |
| - | - | - |
| `list_proposals` | Read | List proposals in your Veles workspace. Filter by status, owner, or search term. |
| `get_proposal` | Read | Get a single proposal with all of its quotes and metadata. |
| `create_proposal` | Write | Create a new proposal (opportunity or deal). |
| `update_proposal` | Write | Update a proposal's metadata — name, status, quote type, contract, or primary option. |
| `list_proposal_versions` | Read | List version snapshots for a proposal. Useful for tracking changes over time. |
| `get_proposal_version` | Read | Get a specific version snapshot of a proposal, including all option pricing details. |
| `list_salesforce_opportunities` | Read | List opportunities from Salesforce CRM. Helpful when creating proposals from existing CRM data. |
### Quotes
Quotes (also called options or scenarios) live inside a proposal and represent a specific pricing configuration.
| Tool | Type | Description |
| - | - | - |
| `list_quotes` | Read | List quotes across proposals. |
| `get_quote` | Read | Get a quote with its phases, line items, pricing, and configuration details. |
| `create_quote` | Write | Add a new quote (option) to an existing proposal. |
| `update_quote` | Write | Update a quote's configuration, pricing, and line items. |
| `clone_quote` | Write | Duplicate an existing quote as a starting point for a new option. Great for creating A/B pricing scenarios. |
### Products & pricing
Products (SKUs) and pricing rules define what you sell and the guardrails around how you sell it.
| Tool | Type | Description |
| - | - | - |
| `list_products` | Read | List products visible within a proposal's context. |
| `get_product` | Read | Get a product (SKU) with its plans, charges, and pricing tiers. |
| `list_pricing_rules` | Read | Get active pricing rules, discount guardrails, and validation logic. |
### Approvals
The approval workflow lets you route proposals through your organization's review process.
| Tool | Type | Description |
| - | - | - |
| `list_pending_approvals` | Read | List proposals awaiting your approval. |
| `get_approval_status` | Read | Check where a proposal sits in the approval chain. |
| `submit_for_approval` | Write | Submit a proposal's quotes into the approval workflow. |
| `review_approval` | Write | Approve, reject, or pass items to the next step in the approval chain. |
| `comment_on_approval` | Write | Leave a comment on a proposal's approval discussion. |
| `reassign_approval` | Write | Reassign the current approver (ball-in-court) on a pending approval package. |
| `retract_approval` | Write | Retract a pending approval package, cancelling the approval request. |
## Example prompts
Once connected, try these prompts with your AI assistant to see the MCP server in action:
* *"List all my open proposals."*
* *"Show me the details on the Acme Corp proposal."*
* *"What products are available for this deal?"*
* *"Create a new quote on the Acme proposal with our Enterprise plan."*
* *"Clone Quote A and increase the seat count to 200."*
* *"What pricing rules apply to this deal?"*
* *"Submit the Acme proposal for approval."*
* *"What approvals are waiting on me?"*
## FAQ
Any MCP-compatible client works with the Veles MCP Server. This includes Claude (via the built-in connector), Cursor, Windsurf, Claude Code, and any tool that supports remote MCP servers over Streamable HTTP.
The MCP server uses OAuth authentication and respects the same role-based access controls as the Veles web app. Your AI assistant can only access data that your Veles user account has permission to see. No data is stored by the AI assistant between sessions.
Yes, but only if you allow it. Write tools (creating proposals, updating quotes, submitting approvals) require explicit permission in your MCP client's settings. By default, most clients will prompt you for confirmation before executing write actions.
The MCP server returns structured error messages that your AI assistant can interpret and explain. Common issues include missing required fields, permission errors, or invalid references. The assistant will typically ask you to clarify or correct the input.
No. The MCP server is a complementary interface. It's great for quick lookups, bulk operations, and workflows where you're already working in an AI assistant. Complex visual tasks like drag-and-drop quote building are still best done in the Veles app.
# What is Veles?
Source: https://docs.getveles.com/get-started/whatisveles
Understand the problem Veles solves, the core data model, and how it fits into your revenue stack.
Veles is a CPQ (Configure, Price, Quote) platform for B2B SaaS companies. It manages the full commercial lifecycle of a deal: product catalog, pricing logic, quoting, order execution, contract management, and renewals.
Most revenue teams run this process across a patchwork of spreadsheets, CRM fields, Slack threads, and disconnected documents. Pricing strategy lives in one place, the quote lives in another, approvals happen over chat, and by the time a deal closes, Finance is reverse-engineering what was actually sold. Veles replaces that patchwork with a single system where every pricing decision, discount, and contract term is structured, governed, and connected to what comes next.
## The deal lifecycle in Veles
Every deal in Veles moves through three distinct layers, each with increasing commercial finality. This is the core mental model, and it maps to the three primary objects in the platform:
This is where deals are modeled. A Quote contains the products, pricing, terms, discount logic, and ramp schedules for a deal. Quotes support multiple pricing options (e.g., Option A: 1-year term vs. Option B: 3-year term) and can be structured into **Phases** -- sequential time periods that define when specific commercial terms apply (e.g., Year 1 pricing vs. Year 2 pricing in a ramp deal).
Quotes are mutable by design. They can be iterated on, sent through approval workflows, shared with buyers via a web portal, and revised until both sides agree. This is intentional: quotes do not trigger billing, provisioning, or revenue recognition. The system tolerates full mutability at this layer because no operational systems depend on it.
When a Quote is accepted and promoted, it becomes an Order. Promotion is the inflection point where commercial modeling becomes a binding obligation. The system locks the Quote, materializes the final pricing into immutable execution fields, and enables downstream processes like billing and provisioning.
Orders are immutable once activated. Every Order has a commercial classification -- New Business, Amendment, Renewal, or Cancellation -- which determines how it affects the Contract. The Order is authoritative for transactional history: it records exactly what was committed and when.
The Contract represents what a customer is actually entitled to right now. It is not a snapshot of a single deal -- it is the accumulated result of every Order activated over time.
When a New Business Order activates, it creates the Contract. When an Amendment Order adds seats or products, the Contract is incrementally updated. When a Renewal Order applies an uplift, the Contract reflects the new terms. The Contract is never overwritten wholesale -- it is mutated prospectively, preserving the history of every prior commitment.
Each layer has structural parity. Quotes contain Quote Phases and Quote Lines. When promoted, these become Order Phases and Order Lines, which in turn produce Contract Phases and Contract Lines. This parallel structure ensures that every commitment interval and line item is tracked cleanly from negotiation through execution.
This three-layer model keeps your data clean. Pricing experimentation on quotes never affects entitlements. Financial systems operate on immutable order data. And amendments preserve historical pricing -- they modify the contract prospectively without recomputing the past.
## Core modules
Veles is organized into modules that can be adopted incrementally. You don't need to rip out your existing stack to start.
### Pricing & product catalog
Define your products with support for flat-rate, tiered, volume, usage-based, and ramp pricing models. Organize with categories and filters. Support multiple currencies. Changes to pricing logic propagate across the entire platform instantly.
[Learn more →](/get-started/pricing-and-packaging/overview)
### Quoting engine (Calculator)
Build quotes with multiple pricing options, custom line items, block structures, and term configurations. Route quotes through configurable approval chains. Share interactive quotes with buyers through a branded web portal.
[Learn more →](/get-started/calculator/quote-options)
### Rules & approvals
Configure pricing guardrails, validation rules, formula-driven fields, and approval workflows without writing code. If you're migrating from Salesforce CPQ, Veles includes a guide for translating your existing rules.
[Learn more →](/get-started/rules-and-approval/learn-the-basics)
### Contract management
Track active contracts as a living ledger. Handle mid-term amendments, co-termination of add-ons, proration, and automated renewals with configurable uplift policies and generation windows.
[Learn more →](/get-started/contract-management/overview)
### Document generation
Auto-generate proposals, order forms, and contracts from quote data using customizable HTML/CSS templates. Brand every output with your colors, typography, and logos.
[Learn more →](/get-started/document-generation)
## AI and the MCP server
Veles is built with an AI-native architecture. The platform exposes a native [MCP (Model Context Protocol)](https://modelcontextprotocol.io) server, which means AI agents and LLMs can interact with your CPQ data programmatically -- reading products, creating quotes, updating line items, and executing pricing logic through structured tool calls.
This is not a chatbot bolted onto an existing UI. The MCP server gives agents the same access to Veles data that a human user has, which means you can build workflows like:
* An agent that takes a call transcript and generates a draft quote with the right products and pricing
* A workflow that monitors renewal dates and pre-builds renewal quotes with configurable uplift
* A pipeline that chains Veles with your CRM and document tools to go from discovery call to signed proposal with minimal manual intervention
If you're building AI-powered sales workflows, the MCP server is the integration point.
## How Veles fits in your stack
Veles sits between your CRM and your billing/finance systems. It's the layer where pricing decisions get made, quotes get structured, and commercial terms get locked down before anything flows to invoicing or revenue recognition.
```text theme={null}
CRM (Salesforce / HubSpot)
↓ Opportunity data
Veles
Quote → Order → Contract
↓ Committed order data
Billing (Stripe) / ERP (NetSuite)
```
Veles integrates bi-directionally with Salesforce and HubSpot, and connects to Stripe for billing and payment collection. Additional integrations include Gong, Google Drive, Calendly, and Loom.
[See all integrations →](/get-started/integrations/hubspot)
## Security and access control
Veles supports SAML 2.0 SSO (Okta, Azure AD), encrypts data at rest (AES-256) and in transit (TLS 1.2+), and offers single-tenant architecture for Enterprise deployments. Access is managed through role-based permissions: Admins have full configuration access, Members can create and edit quotes, and Viewers get read-only access to commercial data.
## What to read next
Set up your account, add your first product, connect your CRM, and generate a quote.
Understand the pricing structures Veles supports: flat, tiered, volume, usage, and ramp.
Configure the guardrails and approval logic that govern your quoting process.
Connect Veles to Salesforce, HubSpot, Stripe, Gong, and more.
# Order Overview
Source: https://docs.getveles.com/orders/order
Understand how Orders work in Veles: the executable commitment layer between quoting and contract management.
An Order in Veles represents a binding commercial commitment. It is the result of [promoting](/get-started/calculator/quote-options#from-quote-to-order-promotion) an accepted Quote, and it serves as the bridge between the pricing negotiation (the Quote) and the durable commercial state (the [Contract](/get-started/contract-management/overview)).
Unlike Quotes, which are mutable simulation objects, Orders are immutable once activated. They contain fully resolved commercial values -- final prices, quantities, discounts, and service dates -- that no longer depend on the pricing engine, rules, or price book. If the price book changes tomorrow, existing Orders are unaffected.
Orders are authoritative for transactional history: what was committed, when, and by whom.
***
## What an Order contains
| Field | Description |
| - | - |
| **Account** | The customer this Order applies to. |
| **Commercial classification** | The type of transaction: **New Business**, **Amendment**, **Renewal**, or **Cancellation**. Determines how the Order affects the Contract. |
| **Effective date** | When the commercial commitment takes effect. |
| **Billing status** | Current state of billing orchestration for this Order. |
| **Activation state** | Whether the Order is pending or activated. Contract mutation and billing only occur upon activation. |
| **Governing Contract** | Reference to the existing Contract (for amendments and renewals). Null for new business Orders that create a new Contract. |
| **Originating Quote** | Reference to the Quote that was promoted to create this Order. |
***
## The object model
Orders mirror the same three-level structure as Quotes and Contracts:
```text theme={null}
Order
└─ Order Phases (commitment intervals)
└─ Order Lines (product-level obligations)
```
Each [Order Phase](/orders/order-phase) defines a contiguous time period with specific commercial terms. Each [Order Line](/orders/order-line) within a Phase defines the product, quantity, price, and billing details for that interval.
This structural parity with Quotes and Contracts means nothing is lost in translation as a deal moves through the lifecycle:
```text theme={null}
Quote → Order → Contract
QuotePhase → OrderPhase → ContractPhase
QuoteLine → OrderLine → ContractLine
```
***
## How an Order is created
Orders are created through **promotion** -- the discrete system event that transitions a Quote from a modeling artifact to an executable transaction. When a Quote is promoted:
1. The Quote is locked to prevent further modification.
2. A new Order is created, linked to the originating Account and (if applicable) an existing Contract.
3. Each Quote Phase becomes an Order Phase with the same service boundaries.
4. Each Quote Line becomes an Order Line with materialized final values.
5. Downstream processes (billing, CRM sync, contract mutation) are enabled.
The transformation from Quote Line to Order Line is not a simple copy. The system stamps final commercial values into immutable fields. At the moment of promotion, pricing ceases to be dynamic and becomes authoritative.
***
## Order creation vs. activation
These are two distinct events with different downstream effects.
**Order creation** happens when a Quote is promoted. The Order exists but may be in a **pending** state while additional steps are completed:
* Signature confirmation
* Finance approval
* Payment confirmation
* Compliance review
**Order activation** is what triggers the actual downstream impact: contract mutation, billing orchestration, and provisioning. Until the Order is activated, the Contract remains unchanged.
```text theme={null}
Quote promoted → Order created (pending)
↓
Signature / Finance / Payment gates
↓
Order activated → Contract updated + Billing triggered
```
The separation between creation and activation ensures that commercial commitments are not recorded in the Contract until all required confirmations are complete. An Order can sit in pending state for as long as the approval process requires.
***
## Commercial classifications
Every Order has a commercial classification that determines how it affects the associated Contract.
### New Business
No prior Contract exists. When activated, the Order creates a new Contract. Each Order Line produces Contract Lines that define the initial entitlement: active quantity, contracted price, service boundaries, billing cadence, and renewal behavior.
### Amendment
The Order references an existing Contract and modifies it incrementally. Amendments can increase or decrease quantities, add new products, adjust service periods, or extend the term. The Contract is not rewritten -- it is updated prospectively. Previously contracted pricing is preserved as the baseline.
See [Contracted price preservation](/get-started/contract-management/overview#contracted-price-preservation) for details on how amendments handle pricing.
### Renewal
The Order extends or replaces expiring Contract Lines. Renewals may update pricing (with uplift), quantities, or terms while preserving the historical record of prior commitment periods in previous Contract Phases.
### Cancellation
The Order terminates active Contract Lines. Cancellation Orders record the effective date of termination and any associated financial adjustments.
***
## After activation: what each layer is authoritative for
Once an Order is activated and the Contract is updated, each object in the lifecycle serves a specific purpose:
| Object | Authoritative for | Mutability after execution |
| - | - | - |
| **Quote** | Historical negotiation artifact. How pricing was modeled and what options were presented. | Locked at promotion. Read-only. |
| **Order** | Transactional history. What was committed, the exact terms, and when. | Immutable after activation. |
| **Contract** | Current entitlement state. What the customer is entitled to right now. | Updated only through new Orders. |
Edits to a Quote after promotion do not cascade to Orders or Contracts. Any changes to an executed commitment require a new Order through the amendment process.
***
## What's next
Commitment intervals that define when specific commercial terms apply.
The product-level obligations within each Phase: prices, quantities, and billing.
How activated Orders create and mutate Contracts.
The promotion workflow that creates Orders from Quotes.
# Order Line
Source: https://docs.getveles.com/orders/order-line
Understand Order Lines: the immutable, executable units of commercial obligation that drive billing and contract mutation.
An Order Line is the executable unit of commercial obligation within an Order. It represents a single product at a specific quantity and finalized price within an [Order Phase](/orders/order-phase). Order Lines are the result of promoting [Quote Lines](/get-started/calculator/quote-line) -- they contain the same data but in a form that is no longer dynamic or recalculable.
When the pricing engine runs during quoting, it produces calculated values (list price, system adjustments, discounts, net price). At promotion, those calculated values are materialized into immutable fields on the Order Line. The Order Line does not reference the pricing engine, the price book, or any rules. It is a self-contained record of what was committed.
***
## What an Order Line contains
| Field | Description |
| - | - |
| **Product** | The SKU from the price book. Identifies what was sold. |
| **Final quantity** | The committed number of units (or driver value). No longer editable. |
| **Final net price** | The price after all adjustments and discounts. Authoritative for billing and revenue. |
| **Discount amount** | The total discount applied, preserved for audit and reporting. |
| **Billing frequency** | How this line is billed: monthly, quarterly, annual, or one-time. |
| **Service period** | Start and end dates, inherited from the parent Order Phase. |
| **Revenue categorization** | Classification for revenue recognition (new, expansion, renewal, etc.). |
| **Contract impact instructions** | How this line should affect the Contract at activation: create a new Contract Line, modify an existing one, or replace an expiring one. |
| **Parent Order Phase** | The Phase this line belongs to. |
***
## How Order Lines are created
Order Lines are produced during [promotion](/get-started/calculator/quote-options#from-quote-to-order-promotion). Each Quote Line is transformed into an Order Line through a process that materializes the final commercial values:
| Quote Line | → | Order Line |
| - | - | - |
| Calculated net price (dynamic) | → | Final net price (immutable) |
| Calculated quantity | → | Final quantity |
| Applied discount % | → | Discount amount |
| Billing frequency | → | Billing frequency |
| Phase association | → | Order Phase association |
| Product reference | → | Product reference |
The transformation is not a simple copy. The Quote Line's pricing depends on the pricing engine -- tier lookups, rule adjustments, data sheet references, and formula evaluations. The Order Line contains the resolved output of all that logic, flattened into fixed values.
After promotion, the Order Line is the authoritative record. If the price book is updated, if pricing rules change, if data sheets are modified -- none of it affects existing Order Lines.
***
## Immutability
Order Lines are designed to be immutable once the Order is activated. This is a deliberate architectural choice that preserves financial integrity:
* **Billing systems** operate on the Order Line's final net price. If that price could change retroactively, invoices would be unreliable.
* **Revenue recognition** depends on stable, committed values. Mutable Order Lines would make rev rec impossible to audit.
* **Contract state** is derived from Order Lines. If Order Lines could change, the Contract would be indeterminate.
The only way to change a commercial commitment after an Order is activated is through a new Order -- an [amendment](/get-started/contract-management/overview#amendment), [renewal](/get-started/contract-management/overview#renewal), or [cancellation](/get-started/orders/overview#commercial-classifications). This ensures a complete, auditable trail of every change.
***
## Order Lines and Contract Lines
When an Order is [activated](/get-started/orders/overview#order-creation-vs-activation), each Order Line produces a **Contract Line** on the associated Contract. The behavior depends on the Order's commercial classification and the contract impact instructions on the line:
**New Business.** The Order Line creates a new Contract Line defining the initial entitlement: active quantity, contracted price, service boundaries, billing cadence.
**Amendment -- add product.** The Order Line creates a new Contract Line for a product that wasn't on the Contract before.
**Amendment -- modify existing.** The Order Line adjusts an existing Contract Line: increasing quantity, changing the price prospectively, or extending the service period. The [contracted price](/get-started/contract-management/overview#contracted-price-preservation) from the prior commitment is preserved as the baseline.
**Renewal.** The Order Line replaces an expiring Contract Line with a new one that may have updated pricing, quantity, or terms.
```text theme={null}
OrderLine (activated)
↓
ContractLine (created or modified)
↓
Entitlement state updated
```
***
## Order Lines and billing
If [Stripe](/get-started/quickstart/connect-your-stripe-account) is connected, activated Order Lines drive billing orchestration:
* **Recurring lines** generate invoices according to their billing frequency (monthly, quarterly, annual).
* **One-time lines** generate a single invoice at activation.
* **Transactional lines** (flagged as transactional on the product) are billed in arrears based on actual usage.
The Order Line's final net price is what appears on the invoice. Stripe receives the committed values directly -- there is no recalculation at billing time.
***
## Custom fields
Like other Veles objects, Order Lines can carry custom field values. Custom fields defined on [Quote Lines](/get-started/calculator/quote-line) propagate to Order Lines at promotion, and from Order Lines to Contract Lines at activation.
This means deal-specific metadata (implementation priority, customer configuration notes, cost basis) flows through the entire lifecycle without manual re-entry.
***
## What's next
The commitment intervals that Order Lines belong to.
The full Order object: classifications, activation, and creation.
How Order Lines create and mutate Contract Lines.
The simulation-layer lines that Order Lines are promoted from.
# Order Phase
Source: https://docs.getveles.com/orders/order-phase
Understand Order Phases: the binding commitment intervals that carry forward from Quote Phases and produce Contract Phases.
An Order Phase is a binding commitment interval within an Order. It defines a contiguous time period during which a specific set of commercial terms applies. Order Phases are the execution-layer counterpart of [Quote Phases](/get-started/calculator/quote-phase) -- they carry the same structure forward but with a critical difference: the dates and terms are no longer negotiable. They are contractually enforceable.
***
## How Order Phases are created
Order Phases are not created manually. They are produced automatically during [promotion](/get-started/calculator/quote-options#from-quote-to-order-promotion) when a Quote becomes an Order. Each Quote Phase becomes an Order Phase with the same service boundaries:
```text theme={null}
QuotePhase (Year 1: Jan-Dec 2026) → OrderPhase (Year 1: Jan-Dec 2026)
QuotePhase (Year 2: Jan-Dec 2027) → OrderPhase (Year 2: Jan-Dec 2027)
QuotePhase (Year 3: Jan-Dec 2028) → OrderPhase (Year 3: Jan-Dec 2028)
```
At the moment of promotion, the commitment schedule defined on the Quote becomes authoritative. The start and end dates are no longer modeling constructs -- they are binding execution intervals embedded in the Order.
***
## What an Order Phase contains
| Field | Description |
| - | - |
| **Start date** | When this commitment interval begins. Inherited from the originating Quote Phase and locked at promotion. |
| **End date** | When this commitment interval ends. |
| **Order Lines** | The product-level obligations for this interval. See [Order Lines](/orders/order-line). |
| **Parent Order** | The Order this Phase belongs to. |
***
## Structure rules
Order Phases follow the same structural rules as Quote Phases:
**Sequential.** Phases are ordered chronologically. Phase 2 starts after Phase 1 ends.
**Non-overlapping.** No two Phases within the same Order cover the same time period.
**Complete coverage.** Together, the Phases span the full duration of the commercial commitment from the Order's effective start date to its end date.
Because these rules are enforced at the Quote level before promotion, the resulting Order structure is always internally consistent. Downstream Contract updates can operate deterministically: each Order Phase defines a clear commitment window, and each Order Line within that Phase defines the product-level obligations for that window.
***
## Order Phases and the Contract
When an Order is [activated](/get-started/orders/overview#order-creation-vs-activation), each Order Phase produces a **Contract Phase** on the associated Contract.
```text theme={null}
OrderPhase → ContractPhase
OrderLine → ContractLine
```
The behavior depends on the Order's [commercial classification](/get-started/orders/overview#commercial-classifications):
**New Business.** Each Order Phase creates a new Contract Phase. The Contract's commitment schedule is established from scratch.
**Amendment.** New or modified Order Phases are appended to the existing Contract or adjust future Contract Phases. Previously executed Phases on the Contract remain intact. Only future commitment windows are affected.
**Renewal.** Order Phases replace expiring Contract Phases with new ones that may contain updated pricing, quantities, or terms. The historical record of prior Phases is preserved.
***
## Example: multi-year ramp
A 3-year ramp deal promoted from Quote to Order to Contract:
**At promotion (Quote → Order):**
| Quote Phase | → | Order Phase |
| - | - | - |
| Year 1: 50 seats × \$40/user | → | Year 1: 50 seats × \$40/user (locked) |
| Year 2: 75 seats × \$45/user | → | Year 2: 75 seats × \$45/user (locked) |
| Year 3: 100 seats × \$50/user | → | Year 3: 100 seats × \$50/user (locked) |
**At activation (Order → Contract):**
Each Order Phase produces a Contract Phase with identical terms. The Contract now contains the full 3-year commitment schedule as durable commercial state.
**Mid-term amendment:**
If the customer wants to add an Analytics product starting in Year 2, an amendment Quote creates new Quote Lines in the Year 2 and Year 3 Phases. At promotion, these become new Order Lines in the corresponding Order Phases. At activation, the Contract's Year 2 and Year 3 Phases are updated to include the new product. The Year 1 Phase (already executed) is untouched.
***
## What's next
The product-level obligations within each Phase.
The full Order object: classifications, activation, and lifecycle.
How Phases are modeled during the quoting process.
How Order Phases create and mutate Contract Phases.