Divyam Bhadoria it seems what he is meaning here is the ability to use the Contact Updated trigger as an example...inside the trigger, currently, you can filter by "has tag". The problem here is that often, we are looking for people who do not have a particular tag.

In this case, for example, we might want someone who has the tag "client" and also does not have the tag "web design". This would show me all clients who are not web design clients for upsells and cross-sales if I am working on building an email or sms automation.

There are dozens of use cases for being able to filter in any trigger (and most filterable actions) for "has tag" OR "does not have tag" AND then being able to add additional filters to that to stack similar to the AND/OR use in conditional logic.

David Hall I totally get the usecase when the trigger is contact created.

My curiosity is in knowing whats the usecase if we add this to "Contact tag " trigger. Where currently you have Tag added and Tag removed as filter options.

How will adding a Has tag and doesnt have tag work with the above two tag added and tag removed filter options ?

whats the usecase for that ?

Divyam Bhadoria great question! Let's think through this just a minute.

We do loads of advanced automation regularly doing things like stacked workflows. It's rare that, when we are creating things, that any workflow is straightforward or not connected to something else. That being said...

Let's hypothetically say I am an HVAC company that offers additional services. I have a new appointment with a potential customer (Larry) for an estimate. I go out, complete an estimate. Larry approves the estimate and the system generates an invoice. Let's assume in this case, we cleaned his duct work and that work is completed. I look at the unit and it is 15 years old. (That's old...)

Invoice gets paid and that converts Larry from Lead into Customer in the system and adds customer tag. However, I am going to need to talk to Larry at some point relatively soon about replacing that unit, but not yet since it is working fine for now.

I'm tracking the duct cleaning, the fact that he is a customer, and the fact that his unit is 15 years old at this point. But there are other options: a 90 day labor warranty on any work we do as well as an annual maintenance plan. The labor warranty is free with paid work, but the maintenance plan has a cost to it.

In this scenario, I might want to trigger an automation that would flow into a "it's time to replace your unit" ascension workflow when the labor warranty is added if the unit is over a certain age, BUT NOT if Larry is a current maintenance plan member because those conversations would happen in person when the tech comes out for the maintenance.

I can get a LOT more advanced with this, and we often do, using conditional logic to move from one place to another, but it would simplify things greatly to say the trigger in this case is labor warranty added, but DOES NOT have maintenance agreement tag.

In our own case, we have loads of scenarios where a person flows through workflows and we use conditional logic to filter them out if they have or do not have certain tags for upsells and cross-sales. We have some upcoming Christmas promotions that will make offers based on what a person has AND doesn't have at the same time.

The value here is in multiple cases:

This is not something that someone who is creating very basic/novice workflows would utilize regularly, but is definitely something that can help with more advanced flows.

Divyam Bhadoria — this feature is really needed and the use case is simple to understand.

Let's say you have a Contact Tag trigger that fires when a newsletter segment tag is added to a contact like "newsletter-cold" for example. You want that workflow to run — but only if the contact also has an "email-opt-in" tag already on their record. Because if they don't have the opt-in tag, you don't have their consent, and the workflow should never fire for them at all.

Right now there's no way to enforce that at the trigger level. So what ends up happening is every contact who gets that newsletter tag added — even if it was added by mistake or without consent — enters the workflow. Then you have to build multiple if/else branches at the top of the workflow just to immediately exit the contacts who shouldn't be there. It works, but it adds unnecessary complexity, wastes workflow executions, and makes what should be a simple build feel much harder than it needs to be.

The fix is straightforward: when configuring a Contact Tag trigger, allow an optional secondary filter — "Contact Also Has Tag" — with equals/not equals operators. Same functionality you already built for the Contact Created trigger. If the contact doesn't have the required tag at the moment the trigger fires, the workflow never starts. Clean cutoff at the head, no workaround needed.

The Contact Created trigger already supports this. Extending it to the Contact Tag trigger would make the behavior consistent across GHL and unlock a huge number of consent-gated and permission-based automation patterns in a way that's simple and user-friendly for everyone building in the platform.

Divyam Bhadoria I think you might have covered this but for extra clarity, it's important that "has any of" filter in case case of multiselect tags

Divyam Bhadoria Your solution might work as long as we could do the filter as "Tag not equal to" without having to do a "Tag equal to".

here's a use case i can think of. Let's say a sales rep is working with a contact to try and sell them Products A, B, and C. On the call he's able to sell them A and B which puts a tag for A and a tag for B on the contact record. he dispositions the call and there are triggers on 3 different workflows that will get triggered. A workflow for Product A, another one for product B, and the third for Product C. Each workflow would have a filter to make sure the contact doesn't have the tag associated to that product. The contact will then ONLY be added to whichever workflow they didn't purchase on the call so we can start dripping content to try and get them to buy later.

Yes this we will add, it will act as "OR" condition between multiselect tags

Matt Ingebrigtsen Yeah, you will be able to choose the operators without any dependency to add another operator