Thanks for the feedback - so my last comment there around the idea for targeting steps by property is coming from the targeting by property mechanism you’ve captured in your screenshot above. While an SA version might not look exactly the same, it would be based on the same principles.
There is an additional complexity though for plans with this approach when it comes to applying it in a policy situation… unlike fixlets/tasks/baselines where once we have a set of target identified (i.e. they satisfy the property selections), the endpoint can then just go ahead and process that action.
However for plans, each step can potentially target different computers. So in a policy situation, the plan would have to ensure it had at least one target for each step in the plan before we could execute it. Often times, the targets would need to be related, let’s take an example to show you what I mean by that:
Let’s say we have two running 3-tier web applications: a DB hosted on one computer, a web server on another and then a series of client computers. Let’s call the two applications as a whole APP1 and APP2
Let’s also say we have a “policy” plan whose workflow is this (and I guess a cluster plan would equally be valid here):
Steps 1-3: Stop the clients, web server & DB (in that order)
Steps 4-6: Patch the clients, DB & web server
Steps 6-9: Start the DB, web server & clients (in that order)
We can’t run this plan until we have at least one DB, one web server and one client machine to target.
We also need a way to ensure that the DB, web server and client are actually related to each other.
i.e. we wouldn’t want to target the DB of APP1 and the web server of APP2 in the same plan.
So there are a lot of complexities when it comes to autonomously kicking off plans, which is why it’s always good for us to hear of real life situations with customers to help us thrash out these use cases.