Description
How to run policies in a specific order, ensuring that an ensuing policy only kicks off after the preceding one has completed.
Running Your Daisy Chain Policies
We can daisy chain policies by using the "Files and Processes" payload in a policy to kick off a custom event trigger when one policy ends to start another policy subsequently, rather than recurring check-in triggers. Custom events are triggers that are only kicked off by running a command like this:
sudo jamf policy -event $TRIGGER
Where "$TRIGGER" is the custom event trigger we're using.
EXAMPLE IMPLEMENTATION: Let's say we have two policies scoped to our device: Policy A and Policy B. We want Policy A to run and then kick off Policy B after A has completed.
Settings for Policy A:
Trigger can be whatever we want, recurring check-in is fine
Add a "Files and Processes" payload. In the "Execute Command" line, enter the following:
/usr/local/bin/jamf policy -event EventB
It is recommended to always use full paths when calling binaries in deployment. We don't need to use "sudo" here because commands run by Jamf Pro are run as root already.
The Files and Processes payload is the last thing to run in a policy, so when Policy A runs, the last thing it will do is execute the command which will then kick off Policy B.
Settings for Policy B:
Trigger: Check the Custom box. Type EventB in the Custom Event field that appears. This is now the custom event that will kick off Policy B.