Hi All,
I have initially built a workflow that will trigger after a certain source has completed aggregation. I am trying to get the the identities of the source and from there get the account attribute of the identity so I could do some comparison. However, I am not sure how to get the proper $.getAccounts.accounts syntax for it. If anyone could please share their input that would be great. Thank you so much!
Hi @Jasmine,
Can you brief the condition you are trying to achieve, such that we can suggest the right syntax here.
Regards,
Uday Kilambi
Hi Uday,
I want to get the last_login_date account attribute from AlertOps source application and compare it to a specific value
Something like this should work $.getAccounts.accounts[?(@.sourceId=='<alertOps-source-id>')].attributes.last_login_date. Replace <alertOps-source-id> with your source id.
If I am assuming the use case properly, the above wouldn’t work. Since you are using multiple identities/accounts, you may need to do a loop to iterate them and complete the compare. Note: Loops are limited to 100 items. If you have more than 100 accounts, I’d advise to filter the loop input or use a recursive approach.
Can you please provide a detailed explanation of your use case?
Hi Braden,
Thank you for your response! We have 2 use cases that will need the last_login_date attribute.
1st: Delete the account of AlertOps users (except service accounts) with no login date. I have already configured the rule and http operation for the deletion and it is working fine.
2nd: Send a notification to AlertOps users who haven’t logged in for 3 months.
Let me know what approach would be better to achieve these. Thank you!
After the account aggregation trigger node, you can do “Get Accounts” and configure like so:
This will get all accounts for the source that finished aggregation.
You can then do a “Manage Accounts” and filter the Get Accounts to only accounts that do not have last_login_date set. The filter I’d recommend is $.getAccounts.account[?(@.attributes.last_login_date == null)].id.
I’m not aware of limitations on this aside from:
This step will time out if it takes longer than 1 hour to complete.
This should cover the first use case. To cover the second, I’d recommend using a loop and comparing current time. The loop input can be $.getAccounts.accounts[?(@.attributes.last_login_date != null)].
In the loop, you can:
1.1 True: Send alert.
1.1 False: End Success
I’d still recommend using a recursive approach to the loop to avoid the 100 item limit.
Another limitation to note is that the Get Accounts may be limited to response size restrictions and limit of 250 accounts returned.
If you run into these limitations, scripting using IDN API calls may be the best approach.
Thanks Braden! I will try this approach 
Do you mean using HTTP Request action or do you mean something else like rules? Thank you
If these limitations occur, I’d recommend moving out of the workflows and creating a script using the PowerShell SDK or another preferred scripting language.
In theory, you could probably continue with the workflows using HTTP requests in a recursive approach to enact pagination, but it will get convoluted quick.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
