If you are trying to block a HubSpot quote from being published until someone approves it, the tier you are on decides how much of that you can build natively. Advanced Approvals, the feature that supports multi step approval chains, requires Revenue Hub Enterprise. Standard Approvals, a single approval rule, is available on Revenue Hub Professional.
That distinction sounds simple until you try to enforce a real business rule, such as blocking a quote when a line item's price falls below that specific product's floor price, across a catalog where every product has a different floor. This post walks through what each tier actually supports, the workaround that makes a per product rule possible on Professional, and one specific limitation we found only by testing it live, not by reading documentation.
The short answer, which tier do you need
If your approval logic is a single condition, someone above a certain deal size, a specific product category, one discount threshold, Standard Approvals on Professional is enough. If you need multiple approvers in sequence, different logic per step, or conditional routing such as legal only being involved after a sales manager approves, you need Advanced Approvals, which requires Revenue Hub Enterprise. Neither tier, on its own, lets a condition compare one property to a different property that varies per record, which is the gap this post focuses on.
What Advanced Approvals actually requires
Advanced Approvals is built for organizations that need multi step approval chains with sequential routing and dynamic logic. A common example is a sales manager approving first, with legal only entering the chain once the sales manager has signed off. This tier of functionality sits behind Revenue Hub Enterprise. Standard and advanced approvals cannot run at the same time in one account, you choose one model for your whole approvals setup.
What Standard Approvals gives you on Professional
Standard Approvals lets you configure one approval rule based on quote properties, line items, or deal details, and you choose whether all assigned approvers must approve or whether any single approver is enough. This is a real, usable feature, not a stripped down placeholder. The limitation is scope, one rule, not a chain, and the rule's condition builder compares a property to a value you type in, not to another property on the same or a related record.
Why a static condition builder cannot enforce a per product floor price
Here is where teams get stuck. Say you want a rule that reads, block this quote if a line item's price is below that product's floor price. The condition builder lets you filter on a line item's unit price using operators like is less than, but only against a static number you enter once. If every product in your catalog has its own floor price, a single typed number cannot represent that rule for the whole catalog. You would need a separate rule per product, which does not scale past a handful of items, let alone a catalog with tens of thousands of SKUs.
The workaround, a workflow computed approval flag
The fix is to move the comparison logic out of the condition builder and into a workflow. A quote based workflow with a custom code action can read the quote's associated line items through the CRM API, look up each line item's product to get its floor price, compare that to the quoted price, and write the result to a boolean property on the quote, something like requires approval, true or false. The Standard Approvals rule then does the simple part, it checks whether that one property is true, and blocks the quote if so.
This pattern works because the hard part, per product comparison across a large catalog, happens in code where it belongs, and the approval rule itself stays a single, static condition, exactly what Standard Approvals is built to handle. We built and tested this end to end, a line item quoted below its product's floor price correctly set the flag to true and blocked publish, and raising the price back above the floor correctly cleared the flag on the workflow's next run.
The limitation nobody mentions, editor autosave can revert the flag
This is the part that only shows up once you test the full editing flow, not just the workflow in isolation. We ran a controlled test using the CRM API's property history, which records every write to a property along with a timestamp and a source. The sequence looked like this.
A line item was quoted below floor, the workflow correctly set the approval flag to true. The price was then raised above floor, and the workflow correctly re ran and set the flag back to false, confirmed by timestamp. Then, an unrelated field was edited and saved in the quote editor, not the price, not the approval flag itself. That save flipped the approval flag back to true. The property history showed this write came from the quote editor's own save path, not from the workflow, meaning it was not a re run of our automation and not a manual click on the checkbox.
The likely explanation, the quote editor loads the approval property into its own frontend state when the page opens, and any later save in that same editing session resubmits its cached copy of the quote, overwriting whatever the workflow wrote in the meantime. That means the flag can drift out of sync with reality during a normal editing session, not just at the moment someone clicks submit for approval.
The practical effect, floor price detection itself is fully automatic and reliable, the workflow always computes the right value when it runs. What is not reliable on Professional is whether that correct value is still on the record by the time a rep actually submits the quote for approval, because routine editing in the quote UI can revert it behind the scenes. This is a real platform behavior, not a mistake in the workflow's own logic, and it is worth testing directly in your own portal before treating a workaround like this as production ready.
Which approach fits your team
If your approval need is one rule and your team can adopt a simple habit, such as refreshing the quote editor before submitting for approval, Professional plus a workflow computed flag is a workable, tested path, and it avoids an Enterprise upgrade. If your approval need genuinely requires multiple sequential approvers with different logic per step, or if the editor autosave behavior described above is not an acceptable risk for your process, Advanced Approvals on Revenue Hub Enterprise is the more direct, more reliable path, because its condition evaluation is not dependent on a workflow written property surviving an editing session.
Frequently asked questions
Does HubSpot Standard Approvals support comparing one property to another property. No, the condition builder compares a property to a static value you type in, not to another property on the same or a related record. A workflow with a custom code action is the way to compute a dynamic comparison and hand the result to Standard Approvals as a single boolean property.
What HubSpot plan do I need for Advanced Approvals. Revenue Hub Enterprise. Standard and advanced approvals are mutually exclusive within one account.
Can a workflow reliably keep a custom approval property accurate on Professional. The workflow itself computes the correct value every time it runs. Whether that value stays on the record through a normal editing session is a separate question, our testing found the quote editor's own autosave can revert a workflow written property, worth verifying in your own portal before relying on it.
