Splunk SOAR

Can you stop SOAR from calling a function as "join_*"?

CS_
Path Finder

Hey all,

So I have some playbooks which were working fine previously, but I don't know if something has changed on SOAR side. I'm not sure if this is a new feature, or if i just have never noticed it before, but when you add multiple connections to one block, the function name changes to "join_*" where * is the original function name.

e.g: join_review_results

My playbooks get to part where they would call "join_*" but then doesn't actually run the next function. I guess because it cannot find a function with that name. Not sure why it's not working.

Can i prevent SOAR from renaming the functions? Do i have to rebuilt the playbook to get it to work again?

If i create a test playbook, like attached, it seems to work fine.  It's only affecting my existing playbooks.
Selection_508.png

0 Karma
1 Solution

phanTom
SplunkTrust
SplunkTrust

@CS_ joins are auto created whenever more than 1 path joins to a block and the function is automatically called as you have seen. 

A join usually requires all of the previous blocks to have completed before it will call the next function, but it is configurable. If your playbooks are failing then it's likely due to one or more of the expected 'upstream' blocks not being run/completed and therefore the join fails. 

You CAN update these settings by selected the Advanced drop-down in the block settings: 

phanTom_0-1656933116071.png


In here you can view & select which blocks need to have completed before the function runs. I would recommend taking a look and seeing if there are any items here that may not run under certain conditions and then you may find why it's failing. 

On your example there will likely only be one required app in the join (whois_domain) as it doesn't create them for custom functions.

To answer your original question, if you untick all the boxes in the join settings then the function will still be called but won't enforce anything, BUT it may cause the playbook to run differently than expected unless it's simple enough to not need that awareness of upstream actions. 

View solution in original post

0 Karma

phanTom
SplunkTrust
SplunkTrust

@CS_ joins are auto created whenever more than 1 path joins to a block and the function is automatically called as you have seen. 

A join usually requires all of the previous blocks to have completed before it will call the next function, but it is configurable. If your playbooks are failing then it's likely due to one or more of the expected 'upstream' blocks not being run/completed and therefore the join fails. 

You CAN update these settings by selected the Advanced drop-down in the block settings: 

phanTom_0-1656933116071.png


In here you can view & select which blocks need to have completed before the function runs. I would recommend taking a look and seeing if there are any items here that may not run under certain conditions and then you may find why it's failing. 

On your example there will likely only be one required app in the join (whois_domain) as it doesn't create them for custom functions.

To answer your original question, if you untick all the boxes in the join settings then the function will still be called but won't enforce anything, BUT it may cause the playbook to run differently than expected unless it's simple enough to not need that awareness of upstream actions. 

0 Karma

CS_
Path Finder

Hey @phanTom 

Once again you've saved me a lot of grief. You are 100% correct.

So I had an action in my decision tree (for the else) which wasn't being run, but was still required on the "join_*" function. I removed the tick for required, and now it's working as expected.

Can't believe I haven't come across this issue before, but happy to know it's just a simple setting to change to resolve it.

Thanks a million, I owe you a beer/coffee!

0 Karma
Get Updates on the Splunk Community!

Continuing Innovation & New Integrations Unlock Full Stack Observability For Your ...

You’ve probably heard the latest about AppDynamics joining the Splunk Observability portfolio, deepening our ...

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...

Cloud Platform & Enterprise: Classic Dashboard Export Feature Deprecation

As of Splunk Cloud Platform 9.3.2408 and Splunk Enterprise 9.4, classic dashboard export features are now ...