Alright. So the deal tags are really, really fun now, and they support a limit of eighty. And this is distributed across all custom object pipelines and your ticket pipeline. So it's not just deal tags.

It's now called as color tags. So whenever you're consuming more in one one object, it's gonna be, you know, taken out from other. So plan ahead when you're building out, but this gives us a lot of flexibility overall. Now when we're building out the, the tags, you see there is a very major limitation.

If you read the knowledge base, you'll see. You cannot currently set criteria based on stay your status properties, which are, I think, one of the most important properties when you're building out a deal tag. You want you want your tags to appear on certain stages and not appear on system certain stages. So that is a, like, a major limitation and we can check this out.

So if I search for stage, you'll see all of the, stage properties, but, you cannot see the main stage property. So that's a limitation. For ticket, this will be status and for, custom objects, it will be a pipeline stages. So how do we go around that and still, you know, leverage the build tags at full capacity?

So, simple solution is you build a workflow. So I'm gonna do this and, let's see. I'll so first, you'll build a properties. It will be called as deal stage and then for tags.

Then, I will use my custom group. So basically, the description I'll add it. So it's internal use only, used to be trigger tags. Basically, we'll be using drop down select.

And I'm gonna just rename it stage one, stage two, stage three. Now you need to write all of these stage names. So if you have multiple pipelines, then write the pipeline name and the stage name. Get creative because it's an internal property, so you can you you don't have to write full names of your pipeline if it's, like, lengthy.

So feel free to do so if I it's like a, onboarding pipeline. So I'll do, like, onboarding and then stage one, stage two. So you need to include all of these stages. This is like a one time cumbersome step, but you need to do it.

But I'm just keeping it at four properties just for, you know, showcasing you. It's done. Now, we will create a workflow. So we'll go to work flows and then we'll create a workflow from scratch and use a deal based workflow.

We'll name this. I'll fill this information and be back. So, yeah, it's it's, based on whenever, a deal stage updates, we just need to update this property correctly. So next. And, we'll use the criteria enrollment. You can use event this as well but I like this more for some reason I don't know. We will use stage.

View stage is known and then save.

Ensure that reenrollment is enabled in this. This is very important. Now we will use I've built it for one pipeline and, you you can get the rest. Rest. Just this is just to showcase the concept. So I will do if then, and I will do or. So I will do one and I'll use page.

Is any of, let's say, I wanna do approval pipeline for example.

So approval pipeline. So, yeah, sign up, pending approval and one. So there are only three stages in the pipeline. So let's do that one.

Let me pause and be back. Now, considering that consider that I only have one pipeline because I have a lot, so I don't wanna build that, like, large workflow. But you will have to build a large workflow and you have to do, like, a nested if then, I recommend you keep this clean and, you know, start with the most used part pipeline first and then the less less used than that. So if you have, like, done for our first pipeline, do it for another pipeline in here, same thing.

So you can, do it right here, clone it, and then do the same thing for all of these pages of the pipeline. So I have done it. So sign up, and then pending approval and one. So what we will do is now set up property.

Now I've simplified the workflow, but I explained the logic. So basically, I'm using one pipeline. As you only have multiple, so you'll have to, you know, figure out the workflow more complex. If you need help, feel free to ping me and I can, you know, help you get that set up.

But basically, whenever a stage is updated, it's gonna check here which stage it is in right now. And then we are gonna set a custom property. It's called, new stage for tags. You can call it, tags internal or something like that.

You can be as creative as you want. No hard feelings. And once you are done mapping all of your stage to the, internal tag property, internal usage property that you'll be using for tag trigger, Then you add in the net net branch, add yourself a notification that, hey. If for some reason someone in your team adds a new stage and, that is not accounted for.

For. So in the non met, you can catch all of those deals. So as soon as someone moves the deal to a stage that is not known to our workflow and maybe it was a new stage. So will send you a notification, hey.

Did you add a new stage? Maybe you need to update the workflow. So it it will, you know, be relevant and scalable. So once you do that, then, you know, we can do a refresh of this.

And then I can use this property, deal stage for tags is any of these. So even though I cannot use the native property, but with this workaround, which is scalable, I can still use this. So hopefully, this solution makes sense to you. And if you need, any help or need help setting this up for your specific use case, feel free to ping me.

Happy to chat through that and consult you. Thank you.