Hi Ash,

The global parameters are meant to pass the static value within the playbook. You can add  general variables to pass through the playbook via trigger block. But those general variables can change its values if you are triggering the playbook thorough incident( only if the name of the variable is present as the metadata of the incident log). So the best practice would be using the global variables if they are supposed to be static or if you know the default value of the variable beforehand.

Best Regards,

Sagar

Hi Sagar,

Thanks for that - just to clarify then, when you say that the variables can change - is that the metadata specified on the alert itself (the ‘Event Metadata’ field in the alert rules), or is that just the built-in incident metadata (like ID, Incident ID, start time etc) you’re referring to?

Cheers,

Ash

Hello Ash, 

It is not the Event Metadata of the alert rules. If you have setup the automation of the triggers then the playbook’s trigger block will use the query of same alert rule that generated the incident and it will fetch the metadata if used any(like source_address, indcident_name, device_ip etc)

Regards,

Sagar

Hi Sagar,

That’s what I suspected was the case - thanks for clearing that up!

Cheers,

Ash

One of the use cases that I feel like highlighting regarding the global parameter is the case of multiple flows due to if else condition.

Say, you have two flows :

One:  when the if condition matches.

Two: when the else condition matches.

Both the conditions return a value that will be used by the next action blocks. If there was no global parameter available for us, we would have to use two input parameters. However, one of them would always show “Unable to Resolve” error during execution, which is logical since both flows cannot exist at a same time.

To prevent that, the only option is to use Parameters action block to set a single global variable. The value could be then used anywhere else.

That makes a lot of sense - thanks Nabin!