Understanding Custom triggers

@mconners There are really several ways to approach this. At it's simplest, you could do something as basic as adding something like the following into the Files and Processes > Execute Command field in Policy 1

/usr/local/bin/jamf policy -trigger <triggername>

That would execute the specific policy called by that trigger at the very end of the Policy 1 run. However, that doesn't have any actual logic to it, meaning, even if Policy 1 fails, it will try to run the policy called by the trigger. If you have some dependencies there, meaning Policy 1 must execute successfully before Policy 2 should run, then you'd want to do this in a script running as "After" instead, and within the script, add some logic to check for whatever it is that Policy 1 should have done, and if the result is true/successful, call the next policy. I can't necessary guide you specifically on that, because it all depends on what your policies are doing, and how to check for the success status, and indeed, whether that's even important.
I'm thinking the latter example is likely how a lot of people are using custom triggers when talking about chaining multiple policies together.

You can also just call a policy by it's trigger on the command line with the same command above. This can be useful when you don't want to put something in Self Service, but still want an easy way to call the policy on a scoped system in a manual way, rather than waiting for a check-in or other condition to occur. I have a few policies set up this way. They have no direct trigger executing them, are scoped to all systems, or just systems within a Smart Group, are usually set to an Ongoing frequency, and I can call them when working on a machine from Terminal whenever I need to.

Hope that helps clarify things a bit. Post back if you still have any questions.

Yeah, I strongly recommend using "control scripts" with logic that calls various policy triggers when you need to control the timing of events. Once you get the hang of it, it's very effective.

Thank you both for your quick replies. This does make sense now.

Without being a scripter, I need to learn about how to determine these dependencies. I can totally see how this would be beneficial and something we need to learn to do.

This is guiding me along, thank you.

That being said, jamf is also preferring you use the "event" command instead of trigger

jamf policy -event <yourtriggerhere>

@rderewianko Yeah, I have a hard time shedding the older -trigger in favor of the new -event Fortunately, for now at least, both still work. Not sure if -trigger will eventually be deprecated.

@mm2270 me too.. I've alway wondered the reasoning for working on a change.

I just have one policy with a simple script that calls other policies directly by their triggers as specified in arguments 4 thru 11 (the ones you can populate in a policy in JAMF).
You just queue up the triggers in the scripts options with the triggers you want in the order you want.

#!/bin/bash
echo START
date
for Custom_Policy in $(seq 4 11); do
if [[ "${!Custom_Policy}" ]]; then
echo Running trigger ${!Custom_Policy}
jamf policy -event "${!Custom_Policy}"
fi
done
echo FINISH
date