The recommended way to build runbooks is to build them in a isolated environment, then move them to a test environment and after that move them into production. In the production environment no modifications should be done, only import new or updated runbooks. When working with the Invoke Runbook activity there is a setting named “Invoke by path”. By default you invoke a runbook by GUID, meaning that you can move around a runbook between folders but it will still be triggered as it has the same GUID.

When the “Invoke by Path” setting is enable you will always invoke the runbook with the same folder path and name as configured, in this example /Prod/C. Even if update or re-create runbook C in the Prod folder it will be invoked. The challenge is when you invoke, with the invoke by name enabled, another runbook that requires parameters. In the image above we invoke a runbook named C with parameter named msg, the value is “Hello World!”. Looking at this from the database it looks like this

As you can see it will pass “Hello World!” to a parameter with GUID “87BFA0D3-741E-4E9A-9F84-7AD0AEC0FB75”. If we now import a new runbook named C and replace/overwrite the current version of runbook C, the first runbook will still try to trigger runbook C (the path is the same) and still a parameter with GUID “87BFA0D3-741E-4E9A-9F84-7AD0AEC0FB75”. But if we look in the Runbook Designer console, in runbook A we see that the value field is empty on the Invoke Runbook activity

This happened when we imported a new version of the C runbook. Why? It is because when we imported the new version of runbook C it has a new parameter. Even if the parameter has the same name and the runbook looks the same, same activities, the parameter GUID is not the same. The GUID is generated when the activity is created and it follows the activity. If you for example build a runbook in a test environment and then export it to production, it is the same GUID in both, the one from the test environment where you created it the first time.

With the following SQL query you can see all Invoke Runbook activities that have a NULL/blank  the value fields

SELECT OBJECTS.Name AS [Activity Name], TRIGGER_POLICY.TriggerByPolicyPath, TRIGGER_POLICY.PolicyPath AS Runbook, TRIGGER_POLICY_PARAMETERS.Value,
TRIGGER_POLICY_PARAMETERS.ParameterName
FROM OBJECTS INNER JOIN
TRIGGER_POLICY ON OBJECTS.UniqueID = TRIGGER_POLICY.UniqueID INNER JOIN
TRIGGER_POLICY_PARAMETERS ON OBJECTS.UniqueID = TRIGGER_POLICY_PARAMETERS.ParentID
WHERE (OBJECTS.ObjectType = ‘9C1BF9B4-515A-4FD2-A753-87D235D8BA1F’) AND (OBJECTS.Deleted = 0) AND (TRIGGER_POLICY_PARAMETERS.Value IS NULL)

To handle this, avoiding to manual update all Invoke Runbook activities when you implement a new version of the runbook they invoke, you need to work with updates. Always update the runbook, don’t create a brand new runbook. You can import your archive file, or even export from production, edit the runbook in another environment and then re-import it again. That will keep the same GUID for everything you don’t re-create. If you re-create any of the initialize start parameters you need to update runbooks that pass parameters to it.