IBM QRadar SOAR

The Timer app is widely used to pause a workflow or playbook for a period of time before continuing execution. This function works best when the time to pause execution is relatively short, for instance, up to several hours. However, pausing execution for longer timeframes, such as 24 hours, can cause CPU and memory resource constraints within both the Timer app and the SOAR platform which require an alternative approach to ensure SOAR performance responsiveness.

One of the alternatives is to use the Scheduler App to, rather than pause the playbook for 24 hours, schedule another playbook to run in 24 hours. This approach has the benefit of completing the first playbook, freeing up SOAR resources. One requirement may be preserving context between the two playbooks. This can be done by sharing property data from the first playbook with the second playbook using a playbook’s activation fields. For instance, if the first playbook executed against an artifact and produced playbook property data, the second playbook can be scheduled to run in 24 hours passing a string-encoded version of the playbook properties. 

Here’s what the script would look like to schedule a second playbook for the same artifact, sharing property data in the playbook’s ‘saved_properties’ activation field as string-encoded JSON. 

Then, when the second playbook executes, a script is run to restore the string-encoded JSON sent in the playbook's 'saved_properties' activation field back to a python dictionary for use within the playbook.