How to Build an Approval Workflow in GoHighLevel

01The $15,000 Deal Nobody Actually Approved

A salesperson builds a proposal for a $15,000 project. Without checking with anyone, they apply a 30% discount, promise a delivery date operations was never consulted about, and send it. Finance never reviewed the pricing. Operations never confirmed they could actually deliver on that timeline. Management never signed off on the discount at all. The customer signs it. Now the business has to deliver a project that barely breaks even, on a schedule that strains the team delivering it, because nobody's decision-making process had a checkpoint anywhere in it.

This happens constantly in growing businesses for a simple reason: they automate the sales process itself, quotes, emails, follow-up, but forget to automate the internal decision-making that's supposed to sit alongside it. A GoHighLevel approval workflow closes that gap, giving the business a structured checkpoint before a discount, a refund, a contract, a marketing campaign, or an onboarding step moves forward unchecked. This guide covers building that system properly, and, just as importantly, being precise about what GoHighLevel actually provides natively for this versus what has to be assembled from its underlying workflow tools.

This is fundamentally a trust-and-control tradeoff, and it's worth naming that tension directly rather than pretending approval gates are free. Every checkpoint added slows the specific decision it's gating, even when it works exactly as intended. The businesses that get real value from approval workflows are the ones that apply them narrowly, to the decisions genuinely carrying enough financial, legal, or reputational risk to justify the friction, rather than gating routine work a trusted employee should simply be allowed to handle on their own judgment.

02The Complete Approval System Architecture

The core pattern repeats across every use case in this guide: an Employee Creates a Request, the Workflow Starts, and a check runs for whether Approval Is Required. If not, the process simply continues. If so, the Approver gets Notified, they Review the Request, and they either Approve or Reject it. An approval continues the automation forward; a rejection notifies the employee and typically requires revision before it can be resubmitted.

Before building any of this, it's worth being direct about one thing: GoHighLevel does not include a single, general-purpose "Approval" object with a native approve or reject button that works out of the box across sales, finance, HR, and operations the way a dedicated approval-process module in some other CRM platforms does. The one place GoHighLevel does offer a genuinely native, purpose-built approve/reject interface is its Social Planner, covered specifically in Section 13. For every other business process covered in this guide, quotes, discounts, refunds, contracts, onboarding, HR requests, the approval mechanism has to be assembled from GoHighLevel's existing workflow building blocks: If/Else conditions, Wait steps, Internal Notifications, Tasks, custom fields, and tags. This is entirely buildable and, done well, works reliably; it just isn't a single pre-built feature waiting to be turned on.

03Section 1: What an Approval Workflow Actually Is

It's worth distinguishing several related concepts that get blurred together constantly. A notification simply informs someone something happened; it requires no action and blocks nothing. A task assigns someone a specific piece of work with an expectation it gets done, but doesn't inherently gate anything downstream from happening. A review is someone looking something over, which may or may not result in a formal decision. An authorization is the actual granted permission for something to proceed. An escalation is what happens when a decision doesn't get made in a reasonable window. An approval workflow specifically combines several of these: it gates a process from continuing until a defined authorization happens, tracks that a real decision was made rather than assuming silence means approval, and escalates if that decision doesn't happen in time.

This is meaningfully different from simply emailing a manager and hoping they reply before the proposal goes out anyway. An email with no gate, no tracked status, and no escalation is a notification wearing an approval's clothing; the sales rep can, and often will, send the proposal regardless of whether the manager ever actually responded.

04Section 2: Identify the Business Processes That Actually Need Approval

In Sales: large quotes, discounts beyond a normal threshold, custom or non-standard pricing, and enterprise-scale proposals. In Finance: refunds, credits issued to a customer account, payment plans that deviate from the standard terms, and formal write-offs. In Marketing: campaign launches, email and SMS sends to the full list, new landing pages going live, and ad creative before it spends real budget. In Customer Success: marking onboarding genuinely complete, exceptions made for a VIP account, and service upgrades outside the standard package. In HR: vacation requests, equipment requests, and training approvals. In Operations: vendor purchases, formal project kickoff, and budget approvals. In Legal: contracts, NDAs, and compliance-sensitive documents.

No two businesses will need identical rules here, and building a list this broad on day one is almost certainly the wrong move; the goal of this section is identifying which of these genuinely apply to your specific business, not implementing all of them simultaneously.

05Section 3: Map the Approval Process Before Building Anything

For every process identified in Section 2, document who's actually allowed to submit a request, who's authorized to approve it, the specific criteria that determine whether approval is even required in the first place, the maximum time a decision should reasonably take, the escalation path if that time is exceeded, a defined fallback approver if the primary one is unavailable, and what the final recorded decision actually looks like. A simple structure to follow: Request, into Department, into Approval Level, into Manager, into Director if the manager's own authority doesn't cover it, into Approved, into the process Continuing. Writing this out for each process before touching the workflow builder is what prevents building an approval chain that technically works but doesn't reflect how the business actually wants decisions made.

This mapping exercise works best as a short conversation with whoever actually owns the risk each approval is meant to protect against, finance for anything touching margin or refunds, legal or operations for anything touching contracts and delivery commitments, rather than a single person's best guess at what the rules probably should be. A workflow built to someone's assumption of the correct threshold, rather than the actual figure the business has agreed on, tends to either block legitimate business or quietly let through exactly the exception it was built to catch.

06Section 4: Deciding When Approval Is Actually Required

Set specific, concrete thresholds rather than vague guidance: quotes over a defined dollar amount, a discount above a defined percentage, a refund above a defined amount, any genuinely custom pricing outside the standard catalog, any new vendor relationship, a marketing campaign above a certain reach or spend, a customer flagged as high-risk for any reason, or an enterprise-scale contract. These thresholds need to be decided and agreed on by the people actually responsible for the business outcome they're protecting, margin, compliance, brand risk, before any automation gets built around them; a threshold pulled out of thin air by whoever happens to be building the workflow tends to either block too much routine business or fail to catch the exceptions that actually matter.

07Section 5: Using If/Else Logic to Gate the Process

GoHighLevel's native If/Else workflow action is the actual mechanism deciding whether a given request needs approval at all. A simple example: If Quote Value is greater than a defined threshold, route into Manager Approval; otherwise, Continue the workflow uninterrupted. The same logical pattern applies identically across every use case in this guide, discounts, refunds, budget requests, customer tier changes, service level exceptions, just with a different field being evaluated and a different threshold. Building this condition correctly, checking the exact field the actual business rule depends on rather than a loosely related one, is what determines whether the automation reliably catches the cases that genuinely need review.

08Section 6: Building Internal Notifications

Whoever the approver is, manager, finance, operations, the sales director, the owner, needs to actually be notified the moment their decision is required, not discover it later by happening to check somewhere. GoHighLevel's Internal Notification workflow action can reach a designated user by email, in-app notification, or SMS, and, through a connected integration, route to Slack or Microsoft Teams for a team that centralizes communication there. Layering more than one channel for anything genuinely time-sensitive, rather than relying on a single notification type someone might miss, meaningfully improves the odds the request actually gets seen before it becomes overdue.

09Section 7: Creating Approval Tasks

Alongside the notification itself, create an actual Task assigned to the approver: a due date reflecting how quickly this decision genuinely needs to happen, a priority level reflecting its actual urgency, a clear description of exactly what's being requested and why, a link to whatever supporting information, the quote, the refund reason, the contract, the approver needs to actually make an informed decision, and a stated decision deadline. A task with a real deadline sitting in someone's queue is considerably harder to quietly forget than a notification that scrolls past in an inbox; this is precisely what prevents approvals from being forgotten entirely rather than simply delayed.

10Section 8: Approval Status Tracking

Track every request through a defined, standardized status field: Pending Approval, Under Review, Approved, Rejected, Changes Requested, Escalated, Expired, or Cancelled. Every request deserves exactly one current status at any given time, stored as a structured custom field on the contact or opportunity, not scattered across email threads or someone's memory of a verbal conversation. This status field is also what powers the reporting covered in Section 18 and what an If/Else condition elsewhere in the workflow checks to decide whether the underlying process, sending the proposal, issuing the refund, publishing the campaign, is actually cleared to continue.

Since GoHighLevel doesn't provide a dedicated one-click approve or reject button for this general case, the actual mechanism for updating this status field needs to be decided deliberately: a common, workable pattern has the approver click a link inside their notification leading to a simple form with Approve or Reject options, submitting which triggers a workflow that updates the status field directly. Other businesses have the approver reply to an SMS or email with a specific keyword captured as a conversation reply, or simply update the field or apply a tag manually inside the contact record itself. None of these is inherently better than the others; the right choice depends on how comfortable the specific approver is navigating the CRM directly versus preferring a simpler, single-click external link.

11Section 9: Building Escalation Rules

A workable escalation sequence: Pending Approval, into a Wait of roughly 24 hours, into a Reminder if still pending, into a further Wait, into Manager Escalation if still nothing, into a final Wait, into Executive Approval if the decision genuinely can't wait any longer. This needs to account for business hours specifically, using the same Wait-step time-window capability covered in this site's guide to automatic lead reassignment, so an approval request submitted late Friday doesn't silently escalate over an entire weekend nobody's actually working. It also needs a genuine backup approver defined for whenever the primary approver is on vacation or otherwise unavailable, rather than an approval request simply stalling indefinitely because the one person authorized to act on it happens to be out.

12Section 10: A Quote Approval Workflow, Walked Through

Sales Rep, into Quote Created, into a check for whether it crosses the defined Price Threshold, into Approval if it does, into the Approved status, into the Proposal actually being Sent. For businesses needing more than one approval tier, a lower threshold routing to a sales manager and a considerably higher one requiring a director or owner's sign-off, chain multiple If/Else conditions in sequence, each checking progressively higher thresholds and routing to the appropriately senior approver rather than sending every quote, regardless of size, to the most senior person available.

13Section 11: A Discount Approval Workflow

A tiered hierarchy is the standard pattern here: a discount up to roughly 10% might route to a Sales Manager, one up to 20% might require a Director, and anything beyond that, 35% or more, might require the Owner directly. The specific breakpoints should reflect the business's own actual margin structure, not a generic template; a business with thin margins might set its highest unreviewed threshold considerably lower than one with more room to work with.

14Section 12: A Refund Approval Workflow

Small, routine refunds below a defined threshold can often process without any approval gate at all, since requiring sign-off on every minor refund creates friction without meaningfully protecting the business. Larger refunds, subscription cancellation refunds specifically, partial refunds, and anything touching a chargeback deserve their own distinct review path, since a chargeback in particular often carries downstream payment-processor consequences worth a manager's direct attention rather than routine, automatic handling.

15Section 13: The One Place GoHighLevel Does Have Native Approval Buttons: Marketing

GoHighLevel's Social Planner includes a genuinely native, purpose-built approval flow: a team member creates a post, submits it for approval, and a designated approver sees it inside the Content > Approval tab with the actual ability to View, Approve, Reject with a comment, or directly Edit the post before approving it. Once approved, the post schedules automatically; once rejected, it moves to a Failed status the original creator can revise and resubmit. This extends to bulk approval for larger campaigns via CSV import, and, more recently, an external link approval flow letting a designated approver, including a client who doesn't have a login to the account at all, approve or reject content directly from an email link without needing to log into GoHighLevel.

This is worth highlighting specifically because it's the one clear counterexample to the general rule stated earlier in this guide: it's a genuinely native approve/reject button system, not something assembled from workflow primitives. For email campaigns, SMS campaigns, landing pages, ad creative, and other marketing assets outside Social Planner's specific scope, review still needs to be built the same way as every other approval process in this guide, an If/Else gate, a notification, a task, and a tracked status field, since that native button experience is currently specific to social content.

16Section 14: A Contract Approval Workflow

A contract often genuinely needs sequential review rather than a single approver: legal review for enforceability and required clauses, pricing review confirming the terms match what was actually approved upstream, operations review confirming the business can genuinely deliver against what's being promised, and management review as a final sign-off, before the document ever reaches the customer for signature. Sequencing these deliberately, rather than sending the same document to all reviewers simultaneously and hoping they coordinate, avoids the common failure of a legal edit and a pricing edit conflicting because neither reviewer saw the other's change.

17Section 15: Approval Gating Customer Onboarding

Prevent onboarding from formally beginning until the contract is genuinely signed, any required deposit has actually been received, internal approval has been granted where the engagement needed it, and any required documents from the customer's side have actually come in. This protects the business operationally: a project team beginning real work before payment has cleared, or before a contract has actually been countersigned, creates real financial and legal exposure that a simple gating condition, checked before the onboarding workflow's first step fires, entirely prevents.

18Section 16: Multi-Level Approvals

For genuinely significant decisions, Request, into Manager, into Director, into Finance, into Executive, into finally Approved, chaining several sequential approval gates is appropriate. This should be reserved specifically for decisions that actually warrant that level of scrutiny, an enterprise contract, a major write-off, a significant budget commitment, rather than applied by default to routine requests; a business that requires four layers of sign-off for a small, ordinary discount will simply train its team to route around the approval system entirely rather than tolerate the friction.

19Section 17: Where AI Genuinely Helps, and Where It Should Never Decide

AI is genuinely useful for summarizing a lengthy quote into its key terms, summarizing the stated reason behind a refund request, pulling together a customer's relevant history for context, highlighting anything that looks like a genuine risk worth the approver's specific attention, generating a concise executive summary for a senior approver who doesn't have time to read the full request, drafting a manager briefing, and generating structured approval notes an approver can quickly scan rather than reconstructing the full context themselves.

A reusable prompt structure worth adapting: instruct the AI that it's an approval-summary assistant, given the specific request details, relevant CRM history, and the business's defined approval criteria, to produce a concise summary covering what's being requested, the key numbers involved, any risk factors worth flagging, and how the request compares against the business's stated thresholds, explicitly instructing it never to render an approval or rejection decision itself, only to summarize and flag. This distinction matters enormously: AI should never be given the actual authority to approve or reject a request on the business's behalf. The decision itself, with its real financial, legal, and relationship consequences, belongs to a human accountable for it; AI's role here stops at making that human's decision faster and better-informed, not at making the decision itself.

20Section 18: Build the Approval Dashboard

Track requests currently pending approval, average approval time from submission to decision, the count and rate of rejected requests, approved requests, where bottlenecks are actually forming, whether workload across multiple approvers is genuinely balanced, SLA compliance against whatever decision-time targets the business has set, and broader trends over time, whether discount requests are rising, whether a particular approver is consistently the slowest link in the chain. This is what turns "we have an approval process" into something a business can actually manage and improve, rather than a workflow built once and never revisited.

21Section 19: Common Mistakes

Approving everything without exception defeats the entire purpose of having a gate at all, while approving virtually nothing, requiring sign-off on decisions too routine to genuinely need it, trains the team to quietly route around the system instead. Too many required approvers on a single request slows decisions without adding proportional protection. No escalation path, no real deadlines, and no clear ownership of who's actually responsible for a pending decision all leave requests to stall indefinitely. No reporting means nobody can tell whether the system is actually working or just adding friction. No documentation of the rules themselves leaves the whole system dependent on whoever originally built it remembering the logic correctly. No testing before launch, and no defined fallback approver for when the primary one is unavailable, both create real gaps the first time they're actually needed. And relying on approvals through email alone, with no tracked status, no gate on the underlying process, and no escalation, reproduces exactly the ungoverned situation this entire guide exists to fix.

22Section 20: An Implementation Roadmap

Phase 1 identifies which specific business processes genuinely need an approval gate, rather than attempting every possible one at once. Phase 2 maps each identified process in full detail: who submits, who approves, the actual criteria, and the escalation path. Phase 3 builds the underlying If/Else logic determining when approval is actually triggered. Phase 4 builds the notification layer reaching the right approver through the right channel. Phase 5 builds the task layer giving that approver something concrete and deadline-bound to act on.

Phase 6 builds escalation for anything that goes unanswered past a reasonable window, including genuine business-hours awareness and a defined backup approver. Phase 7 builds the reporting layer covered in Section 18. Phase 8 is ongoing optimization: reviewing actual approval times, rejection rates, and bottlenecks regularly, and adjusting thresholds and approver assignments based on what the real data shows rather than what seemed reasonable when the system was first designed.

23The Bigger Picture

Every growing business eventually reaches a point where letting every employee approve everything themselves stops being sustainable. Left unmanaged, that shows up as discounts that quietly erode margin, refunds issued with no real oversight, pricing mistakes that reach a customer before anyone catches them, contracts sent before anyone confirmed the business could actually deliver on them, marketing published with an error nobody reviewed, and onboarding starting before payment ever cleared.

The businesses that scale well aren't the ones that automate every single decision away from human judgment; they're the ones that automate the process surrounding the decision, making sure the right person reviews the right thing at the right moment, with a clear, tracked record of what was decided and why, without slowing the business down more than the actual risk being managed genuinely justifies.

24How We Help

Designing an approval system that actually protects the business without becoming its own source of friction, correctly scoped thresholds, the right approvers, real escalation, and honest reporting, takes more careful process design than a single If/Else condition bolted onto an existing workflow. New Motion IT works with agencies, home service businesses, SaaS companies, and growing multi-location businesses to design and implement complete approval systems inside GoHighLevel.

A GoHighLevel Workflow & Approval Audit reviews the business's sales, refund, marketing, contract, and internal approval processes, escalation logic, and reporting, and results in a governance system that reduces costly mistakes and protects profitability without adding unnecessary friction to the decisions that don't actually need it.