Using dynamic names in lists in playbooks

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Using dynamic names in lists in playbooks

L1 Bithead

I have a sub-playbook that checks if a list exists and if not, fetches data from an external API and saves the result to that list, the next time the playbook runs it will load it from the list rather than fetching from the external API.

I want this list to be named based on the current month, but am unable to make this work as it seems I need nested variables, which require a custom script.

My current task list is (abbreviated to relevant ones)

  • Conditional task with IsListExist automation with a text name for the list bla_bla_bla. I am assuming I can make this ${list_name}
  • Task with Set automation that has the value ${lists.bla_bla_bla}
  • Finally createList builtin that uses the bla_bla_bla list name

So the challenge is to solve the middle task that uses the Set with ${lists.xxx}, where xxx needs to be dynamic.

Is there a way to solve this or is there an alternative way - I did originally try getList, but this seems to create a File in the context, but whose contents was some 500 error.

 

1 accepted solution

Accepted Solutions

L5 Sessionator

Hi @bowesmana, I've attached a short playbook that should work for your requirement. We have an automation called TimeComponent that will work better. 

Screenshot 2024-06-06 at 12.50.44 PM.png

 

In my example, I've created the error path feature instead of a conditional check. I think you might be able to use the playbook as-is, ensure that you replace the "Make some API call.." step with the actual steps for fetch the remote data.

 

Note: Just rename the attached file from .xml to .yml.

View solution in original post

3 REPLIES 3

L5 Sessionator

Hi @bowesmana, I've attached a short playbook that should work for your requirement. We have an automation called TimeComponent that will work better. 

Screenshot 2024-06-06 at 12.50.44 PM.png

 

In my example, I've created the error path feature instead of a conditional check. I think you might be able to use the playbook as-is, ensure that you replace the "Make some API call.." step with the actual steps for fetch the remote data.

 

Note: Just rename the attached file from .xml to .yml.

Thanks @jfernandes1 - something I don't get (I'm a real newbie) is having done getList and the list is loaded, where does the list data actually go? If I turn of quiet mode, I can see the data logged, but I can't see it in the context of the playbook, so how do I actually use it?  I think that was why I went down the ${lists.xxx} logic as I could put that in a Set automation and get the data into the context - with this method above, after the getList builtin runs, I don't have the data anywhere I can see.

 

L5 Sessionator

Hi @bowesmana, by default nothing is written to context. You can keep quite mode enable and add the below to the advanced tab. 

 

Screenshot 2024-06-07 at 1.13.14 PM.png

 

Do not add anything after the equal sign (=). The syntax tells XSOAR to grab all output and add it to the listdata key.

 

I would also like to recommend that you have a separate step for the getList command that saves the data to the context. Before you start adding more data to context, I would suggest that you only do so:-

 - When you cannot use CompareList or FilterByList commands

 - When you cannot use a conditional playbook task with the In, Not In, In List or Not in List operators. 

  • 1 accepted solution
  • 8404 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!