How to prevent direct call rule from firing twice?

[aagk123]

How to prevent direct call rule from firing twice?

[aagk123]

I tried max frequency in condition and the rule stooped working completely. I used s.abort in the custom code it stopped other rules from firing.

[Jennifer_Dungan]

What sort of trigger is being used?

Also the "max frequency" condition should have worked (and not caused a complete failure)... could you maybe share some screen shots of the condition you tried?

While fixing it with Launch is technically feasible (this is where I would be recommending the Max Frequency), I am curious if there is another root cause that would explain the double trigger.

[aagk123]

This is the trigger 

I know its firing 2 times in console but max frequency didn't work in this place. Does max frequency controls frequency for only one direct call firing? Can we write some custom code in set variable section like 

if(event.detail.value == "Selected Company From Search By Company Page")
{
linkName = "Connect Payroll:Provider Selected:"+event.detail.value.company;

}

I tried the above code and it didnt work as well.

[Jennifer_Dungan · Accepted solution]

When you say you tried this code:

if(event.detail.value == "Selected Company From Search By Company Page")
{
linkName = "Connect Payroll:Provider Selected:"+event.detail.value.company;
}

Do you mean as a "custom code" trigger?

This isn't how you listen for a JS custom event, so that's probably why it didn't work.

I have never used the "Direct Call" method for our events, I've always used custom code event listeners like so:

window.addEventListener('atomic-transact-interaction', function (event) {
  if(event.detail.value == "Selected Company From Search By Company Page")
  {
     linkName = "Connect Payroll:Provider Selected:"+event.detail.value.company;
     trigger();   
  }
}, false);

Basically, I listen for the event "atomic-transact-interaction", then look into the event.details for some criteria... if it matches, I use the "trigger();" call, this is what actually allows the custom code to move forward to run the rule.

I've not tried setting linkName directly here, but it should work... if not, you may need to set it to a temp variable that you can read in the rule. I  generally add the entire event.details into a variable so that I can extract multiple pieces of info to use inside my actions.. and when I am done and the beacon has been sent, I will clear that temp variable.

Now, for the Max Frequency, you didn't really answer how you configured it.. but since this event seems like a generic event used for multiple different items, so this may be why the "max frequency" isn't working.... this may be loading first on the page load, then for something else, then this behaviour which is triggering twice...

But if you are using Max Frequency based on the "Page View" 

This is probably your issue, as this event has likely already fired on the page.... 

Try a Max Frequency based on time:

This still may not work depending on how many atomic-transact-interaction events are being fired on your site.... 

Again, the best solution is to log a ticket with your developers that they need to stop triggering this twice.

[aagk123]

Should I have this in the events section or actions section of the rule?

[Jennifer_Dungan]

Since you were talking about triggers (or I thought you were), the code I provided is a trigger (as a potential replacement for Direct Call)

You can try it anyway.. 

Or was your code:

if(event.detail.value == "Selected Company From Search By Company Page")
{
linkName = "Connect Payroll:Provider Selected:"+event.detail.value.company;
}

In your actions area? If so, you may not be able to read the event data directly... another reason for why I use custom code, I can access the event.detail data within the trigger, then usually I add it to a window object, so that I can leverage that in my action... 

[MayankVashisth]

@aagk123 Do check if the direct call identifier is getting set twice from where it has been set in the source code. 

[Jennifer_Dungan]

Yes, I agree... this trigger is essentially coming from the source code, so your developers should be the ones fixing it (as they seem to be the ones triggering it twice).