HubSpot Deal Approvals: Define Decisions, Owners and Exceptions

An approval process should answer a specific question: who can authorize this commercial decision, based on which evidence? Adding names to a chain without answering that question usually adds waiting time.

The July 2026 HubSpot roundup raised the limit on deal pipeline approvals to up to ten approvers per pipeline (Sales Hub Enterprise). More capacity is useful only when the decision rights are explicit.

Define the approval trigger

Start with the decision that requires review: a commercial exception, unusual scope, an unsupported commitment or a particular risk threshold. Record why a deal needs approval and what information the approver must inspect.

Keep ordinary stage progression separate from exceptional authorization. If every routine deal requires the same senior intervention, examine whether the underlying operating policy is clear enough.

Distinguish decision-makers from contributors

A person who supplies information is not necessarily an approver. Finance may verify a calculation; delivery may confirm feasibility; a commercial owner may authorize the final exception. Document the role of each participant.

For each required decision, record the accountable role, expected response time and substitute when the usual owner is unavailable. Confirm how the account’s approval feature supports the intended structure before translating it into configuration.

Keep the evidence with the deal

An illustrative approval record might contain the requested exception, business reason, affected amount or scope, relevant attachment and decision outcome. The implementation should make that context available without forcing the approver to search several message threads.

Decide what happens when material terms change after approval. A previous decision may no longer cover the revised deal. Preserve a traceable history and define when another review is required.

Design rejection and timeout paths

HubSpot gives an approver three outcomes; map your policy to them. Request changes is the path for an incomplete request: the approver comments, the owner updates the deal and replies so it can be approved. Reject is terminal: a rejected deal can only move to a closed lost stage, so reserve it for decisions you do not expect to be reworked. For an unavailable approver, the ‘Any’ setting lets a single assigned approver decide. If an assigned approver has lost approval permission or been deactivated, the process will not start; HubSpot shows a Restart option on the deal, and restarting an approval requires Super Admin permissions. HubSpot’s documentation describes notifications when approval is requested and decided, but no reminder or escalation, so a delayed decision should be surfaced by a saved view or workflow on the ‘Latest approval status’ property.

A reminder you build can draw attention to a request; it cannot resolve an unclear decision or a missing mandate.

Test actual behavior, including integrations

Review HubSpot’s deal approvals documentation for prerequisites and exemptions: approvals need Sales Hub Enterprise and a Super Admin to configure, can be limited to deals matching criteria, cannot be bypassed and also apply to stage changes made by workflows or the API. Deals already in a stage when approvals are switched on, and moves straight to closed lost, are exempt. Then test the relevant roles and update paths in the account rather than assuming your reading of the rule.

Use one standard request, a rejected request, a changed deal and an unavailable approver. HubSpot’s ‘Latest approval status’ only distinguishes Pending approval, Approval not needed, Approved and Rejected; if you need to separate waiting for evidence (changes requested) from waiting for a decision, record it in a property of your own. That makes approval time useful to discuss with the team.

Continue with pipeline review controls and global versus local CRM rules.