I implemented the workaround a few months ago and have found out that it often just does not work and there's really no way to know it. Specifically, what seems to be happening is the Object Updated trigger is often running in a delayed state to varying degrees. For instance, this morning, update triggers were running at a nearly 30 minute delay from when the actual asset object was updated and it seemed to suddenly "catch up" and process a bunch of updates at one time. A delay itself is annoying, but as long as it still processes the flow correctly, it's not the end of the world (at least not in my use case, though it could be hugely problematic for something more sensitive).

The problem here lies in that initial api call to get the update history not firing off in realtime when the update happens. I have my flow checking for a match on a certain attribute (just like the workaround suggests), but when it runs on a delay, if anything else has changed on the asset, the "most recent" update will no longer match up and will pull a different change. I just had an asset where I updated a handful of fields, then the automation caught up 20-30 minutes later and ran them all, but the api returned the same attribute as the "most recently updated" one for 6-8 different automation triggers. 

We often update more than one attribute in a short period of time, so simply put, if the automation trigger isn't running in realtime, then the workaround 100% does not work at all.

To properly support Asset Lifecycle Management, this is required in one shape or another - and it needs to scale to hundreds or thousand of entity changes - ESPECIALLY once JSDCLOUD-14881 is solved. Examples: Your vulnerability management tool detects a required software update that needs to trigger work for you support team.

c02f7a849e2e 
Indeed, you especially need to watch out for bulk edits with the workaround because it can trigger the rate limiting on automation.
We experienced this when we updated the vendor in our environment from Hewlett-Packard to HP.

As the description has been updated with a workaround I just want to point out again that the workaround isn't really suitable for anything at a larger scale. Unless I'm misunderstanding how it works.

Using automation you can:

• Detect changes to the asset object as a whole and then double checking if the attributes changed over the api.
  • This invokes automation executions every time whether your desired attribute has changed or not because you're still using the 'send web request' action.
  • For environments that sync regularly via Discovery this could trigger thousands upon thousands of individual rule executions.
• Run a scheduled automation rule periodically
  • This would enabled you to branch through a filter of 'Assets updated within the last x hours'
  • This is limited to 1000 branches

For my use case, I want to trigger automated updates on asset objects and asset object relationships when the user's location value (automatically synced in from Azure AD) is updated.

Hi,

Does anyone have an ETA on this request? 

I need to be able to trigger email notifications as soon as an assets value changes in a certain attribute. 
Example: 
When a laptops status changes from "In Service" to "Damaged" my finance department needs to be informed of this as they need to action it promptly for insurance and reporting etc. 

Looking forward hearing back. 

Thanks in advance, 

My use case is importing 'Laptops' and 'Last Logged On User' which is something that will sync on a daily basis.

The problem with this workaround is that it requires a chargable automation rule action execution just query the api and just assess whether the attribute that you're watching has changed or not. If it hasn't, you've wasted one of your limited executions.

For CMDBs with lots of changes this is going to mount up incredibly quickly.

Hopefully this is something Airtrack / Datamanager will bring some extra functionality to solve?

Another use case that enabling a specific attribute/objectType in the trigger is:

You have multiple objectTypes, amongst others:

• Offices
• Employees
• Computers

On Employees, there is an attribute "Office" that refers to objectType Office.
On Computers, there is also an attribute "Office" that refers to objectType Office. There is also an attribute "Employee" that refers to objectType Employees.

Computers' attribute Office should be set based on the attribute Office of Employee referenced on the object. So an Employee is located at the London Office, then the Office of that Employee's Computer should also be set to London.

Now an automation rule should automatically update the Computer's Office-attribute if the Office-attribute of the Employee is updated. So our Employee from before is moved to the Paris office, now the Computer's Office-attribute should automatically be updated to Paris as well.

With the help of Atlassian support, I have managed to create an automation rule that supports the need, though the rule is more complex than it needed to be, if automation rule supported a more advanced object-updated trigger.

Trigger: Object Updated

AQL Condition: objectType = Employees

Action: Lookup objects: objectType = Computers and Employee = object.key

smart value condition: {{lookupObjects.Office}} does not equal {{object.Office}}

Action: create variable, name: var - smart value: {{object.Office}}

Branch on AQL: query: Key IN ({{lookupObjects.key)}}

Branch Action Edit object: atribute "Office", value: {{var}}

Hello, will this feature get introduced?

This is good 74f0f3156212  
Will include this in the document as an optional step for someone who is looking to get objectTypeAttributeId dynamically.