> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getveles.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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/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.