Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Adobe Summit is happening now. Discover what's next in customer experience.

DTM: Element Exists Trigger doesn\'t always fire rule


Level 2

Any idea why DTM won't fire more than once for me on the "Element Exists" rule? There is a span element that pops up whenever I want this rule to fire, and DTM's own notifications detects its existence, but for some reason the rule won't fire after the first time.

I've tried every combination of Bubbling options I can think of.

Take a look at my console notifications:


The part highlighted in Red is the part I want to fire each time. See how the same sequence later stops with DTM saying to me: "yep, it's there..."

Thanks for your help!

3 Replies


Level 10

Hi There,

Thanks for reaching out to Adobe Community.

Please accept my apologies for the inconvenience caused. I would request you to kindly go through the below troubleshooting article and see if that helps:



Level 2

It did not help. That document is very generic, and the inconsistencies it addresses are those where the code doesn't have time to fire (such as when you're capturing data on a click). There is no click here, we're just looking for the rule to fire when the element exists. It happens the first time it's detected, and then when it's detected again, it does not happen.




Is there a url where we can see this happening ?



Level 2

The dev site in question is password-protected, so I'll have to let you in personally if you want to take a look. It might take me a little while to recreate the problem, since I had to find another way around, but my preference would be to use a rule that DTM could fire reliably. (The way I'm doing it now is hard-coding the function right inside the custom javascript of DTM, which is the opposite direction I wanted to go.)

Feel free to give me a call, and I can walk you through it. Search through your email archive for "cscribner"; I know I sent you an email that has my phone number in it.


Level 5

Going from something on Search Discovery's FAQ, it looks like the elementexists may only fire when an element enters the DOM (otherwise, the rule would probably just firing over and over since it continues to exist). It's hard to tell without seeing your code, but if the .errorflag element is already in the DOM from the first trigger, maybe that could prevent it from triggering the rule again?

Could you also maybe approach it the other way and make whatever is triggering the error span to appear also kick a direct rule call (_satellite.track)? 


Level 2

Mike, I wish I understood what the Direct Rules were for. I can't find any documentation on it, or sufficient explanation of when or why it should be used. Can you be my sensei? I would love to learn what you know.

The most important problem I'm facing from DTM is that I want to trigger events *not* by what the user does (clicks, hovers, etc), but rather by what my site is showing the user. So much of the experience changes dynamically on the pages that the URL is no good to me. I've been using a lot of Element Exists rules, but they don't fire as reliably as I need them to, and so I've been resorting to my own set of jQuery listeners.

So what I'm really looking for is a way to send something to the page that will trigger my DTM events. I can tell my developers to populate data layer variables in a certain scenario, but that doesn't necessarily trigger anything on DTM's side, so the data just sits there unsent. 


Level 5

Yes, that's exactly what the direct calls do.

In the above case, your javascript/jquery creating the <span> would  make a call: something like _satellite.track('xyz'). In DTM, create a direct rule and for the condition put xyz and fill out the adobe analytics portion of the screen like you would with any other rule. As you stated, you can pass in values for your props by having a data layer (just make sure to set your values before making the track call).

The training video gives a little background:


Level 2

Mike, Thank you so much for pointing me to this. Let me tell you what kind of trouble you just caused: I just completed the most hectic week of my life, because we switched 180 degrees from an Event-Based Rule implementation to a Direct Call Rule implementation. It was *absolutely* the right thing to do, and I'm so grateful for you turning me onto it. 

I even wrote a blog post about that switch, and why I'll never go back to Event-Based rules in any TMS. There's a shout-out to you in it (I didn't call you out by name, but I will if you want).