How to Automatically Communicate With Prospects When a Group Joining Request Is Rejected in GoHighLevel

Every private community collects a pile of join requests it will never approve. Some are spam, some are competitors, and some are genuinely interested people who simply picked the wrong group. In most accounts all three get the same treatment, which is silence. The request sits in a tab, an admin clicks Decline, and the person on the other side hears nothing at all. They do not know they were turned down, they do not know why, and they have no idea what they could have joined instead.

GoHighLevel closes that gap with the Group Joining Request Rejected trigger. It is one of four newer Communities triggers, and it fires the moment a community admin declines somebody's request to join a group. That single event is enough to start a workflow, which means a rejection can send a considered message, tag the contact, alert a team member and offer a different way in, without anyone writing an email by hand.

What the Group Joining Request Rejected trigger does

HighLevel's description inside the trigger panel is refreshingly plain. It fires when a community admin declines a contact's request to join a group. The help documentation words it the same way, describing the event as a join request for a community group being rejected. HighLevel positions the trigger as the way to keep rejected applicants on a structured follow up path, whether that means a friendly decline, a pointer to other resources, or an internal notification to a moderator or a sales rep.

It lives in the Communities category of the trigger picker, next to Group post created, Group comment created, Member registered for group event and the leaderboard level trigger. All four of the newer ones share the same shape and all four require a Group filter, so once you have built one of these workflows the rest go together quickly.

What actually counts as a rejection

This is worth being precise about, because the trigger reacts to one specific action. Open a community group, go to the Members tab and the member states are split into Active, Admins, Contributors, Requested and Banned. The Requested tab holds everyone waiting on a decision, showing when they applied and how long ago that was. Open the menu on a pending row, hover Request, and you get Approve and Decline.

Decline is the event. It is an admin decision, not a request that quietly expired and not somebody changing their mind, and that distinction should shape the message you write. A person who was actively turned down deserves a different tone from one whose application was simply never looked at. A workflow can also do the rejecting, which is where this trigger starts to earn its place at scale, and we come back to that shortly.

Setting the trigger up

Go to Automation, open Workflows and click Create Workflow. Start from scratch and name the workflow after the outcome rather than the mechanism, something like Mastermind Application Declined. You will be grateful for that once the list has forty entries in it.

In the builder, click Add New Trigger and type community into the search box, or scroll to the Communities category. Choose Group joining request rejected and the configuration panel opens on the right. Rename it in the Workflow Trigger Name field, then set the filter.Group is the required one, and the row follows the familiar field, operator, value pattern, with the operator set to Is and the value being the group you want to watch. Add filters lets you stack further conditions. Click Save Trigger and the trigger is live on the canvas.

Why the Group filter is not a formality

HighLevel makes Group mandatory on all four of these triggers, and the reason is practical rather than technical. A free community, a paid mastermind and a private client space are three different conversations, and a rejection from each one calls for a different message. Point a single workflow at everything and the person turned away from the beginners group receives the note you wrote for your highest tier programme.

The documented pattern is one workflow per group, or selecting several groups on one trigger where that is supported. Either way, make it a decision rather than a default. If two groups genuinely deserve the same wording, let them share a workflow. If they do not, split them and accept the extra ten minutes of setup.

Screen the request before you ever reject it

The rejection trigger is only half the picture. Its natural partner is Requested to join group, the trigger that fires when somebody applies in the first place. That one carries a second class of filter which makes the whole system smarter: membership question responses. Once you pick a group, every membership question configured on it appears as its own filter field, so the workflow can branch on what people actually wrote when they applied.

Those answers stay available for the rest of the workflow, not just at the trigger, and that opens the door to automatic screening. HighLevel documents passing the responses into a GPT workflow action with a prompt asking whether the answers look genuine or like spam, then running an If/Else on the result. Genuine applications get approved and added to the group. Borderline ones get flagged for a human to look at. Obvious spam gets rejected on the spot.

Two things are worth weighing before you build that. The GPT step is marked as a premium action that carries an additional charge for every execution, so it sits more comfortably on a group taking a handful of requests a day than one taking hundreds. And an automated rejection is still a rejection, which is exactly why the pairing works: the screening workflow makes the call, and the Group Joining Request Rejected workflow supplies the manners.

What to actually send when the answer is no

The trigger is only the doorway. What matters is the short, honest sequence behind it. A few things earn their place in almost every decline workflow:

• One clear message saying the request was declined, written as a decision rather than dressed up as a technical glitch.

• A reason where you can give one, even a general one, because a line like this group is reserved for existing clients answers the question better than silence ever will.

• An alternative that is genuinely open to them, whether that is a free group, a newsletter, a public channel or a waiting list.

• A tag such as Community Join Request Declined, so the contact can be segmented and kept out of member only campaigns.

• An internal notification or a task when the applicant is a real prospect and the decision deserves a human follow up.

• A single check in later, and only if the door is genuinely open to them at some point in the future.

Keep it short. A decline sequence that runs for six weeks is not nurture, it is nagging, and it will spend all the goodwill the polite message just bought you. One honest note at the moment of rejection, and at most one gentle follow up later, is usually the right amount.

Test it before you publish

HighLevel's own setup guide ends with the step most people skip. Use a test contact or a second member account, submit a real join request to the group, then decline it from the Requested tab and watch what happens. Confirm the contact is added to the workflow run, confirm the email or SMS actually goes out, and confirm the tag lands on the right record. Only then move the workflow from Draft to Publish.

It is also worth reading your decline message back as though you were the person receiving it, because the same words land very differently depending on why the request was refused. Spam does not need an explanation. A serious prospect who applied to the wrong group very much does, and that is the case the workflow should be written for.

Frequently Asked Questions

Does the trigger fire if a request expires or the person withdraws it?
The trigger is described as firing when a community admin declines a contact's request to join a group, so an explicit decline is the event it listens for. Requests that sit untouched are a different problem, and they are better handled with a regular review of the Requested tab than by assuming this trigger will catch them.

Can one workflow cover every group in my community?
Group is a required filter, so you have to name at least one. HighLevel's guidance is to select multiple groups where that is supported, or to build a separate workflow for each group. Separate workflows usually read better anyway, since the message that suits a free community rarely suits a paid one.

Can a workflow reject a request on its own, without an admin?
Yes. The Requested to join group trigger can branch on membership question answers, including through a GPT action that judges whether a submission looks like spam, and it can reject on that basis. Pair the two triggers and the full cycle, screening and messaging, runs without anybody opening the Members tab.

Does this work in public groups as well as private ones?
The Communities triggers respond to activity inside groups regardless of visibility, as long as the group is managed through HighLevel Communities. In practice join requests matter most in private groups, because that is where approval is required before somebody gets in.

Need Expert Help with GoHighLevel?

New to GoHighLevel and ready to get started? Buy your GoHighLevel account here and launch with confidence.

Already know what you need and want our team to handle everything, from complete setup and customization to funnels, workflows, automations, CRM, and pipelines? Click here.