How to ensure automation doesn't multi-run when based on Asset Object Change?

[Calvin]

For example, I want to have an asset where if someone updates the attribute to "TRUE" it creates a second asset elsewhere with certain information on it.

Now I know I can have a trigger for "Object Updated" then an "IF" condition to check if an attribute is TRUE. Which can then set off the object creation.

The issue is:

1. How do I ensure it doesn't do it many times (duplication check new asset doesn't already exist)

2. Because the trigger is based on "Object Updated" every single change will run the automation multiple times. Even with a duplication check the automation takes like ~10seconds to finalise which can be problematic when people make multiple changes at once firing the automation multiple times until the first one finally finishes.

Cheers!

[Jeroen Poismans · Accepted solution]

Hi Calvin,

Form your description I can only think of a "Processing change" flag of some sort. This is how the rule high level would look:

• Trigger on Updated
• Check if Processing flag is set
  • If Yes
    • SKIP
  • If No
    • Set Processing flag
    • Create Asset
    • Unset Processing flag

Give this a try?

Jeroen

[Calvin]

Thanks for this mate, do you know of any docs that show how to create the processing flag? Or would it just be a flag in the attribute?

I'm hoping to stay away from the attribute flag update by automation, incase the second automation runs before the first one is able to flag it.

[Jeroen Poismans]

The first one to flag it would be the one executed, the one coming behind ... will skip. That's why you set the flag at the very beginning of the rul. The flag indeed would be just an attribute on the assets.

[Calvin]

If your looking for an answer I'd recommend Jeroen above, but what I ended up doing is a duplication check of the main name. And I made the NAME unique, so for the most part this shouldn't be an issue since they'd have to beat the automation to run it, and whenever it is an issue Jira will naturally reject one of them internally because the system can not have two of the same names if set to UNIQUE.