Move policy-specific automations into individual policy detail UI for read/write, policy list for reads

[iansltx]

Problem

A new use case for policies is "when X fails do something to make it pass," whether installing software (#19551) or running a script (#17129). In these cases, having the context of the entire policy available is helpful when setting up the automation, and changing both the automation and the policy at the same time is useful for cases like "make sure the version of Firefox is current" when the definition of "current" changes.

Currently automations are configured per automation type, with selection modals for software (and soon scripts) that list all policies for a team in the same UI. While this kind of made sense in the context of a webhook or a maintenance window on a calendar, this

• makes less sense when a specific action (e.g. specific installer) ties to a specific policy
• gets crowded when there are a bunch of policies (e.g. for maintaining a full set of installed software on a host)
• doesn't provide enough room for context (e.g. if the associated installer isn't compatible with all platforms covered by the policy)
• doesn't make sense in the context of a pre-built policy that includes both a pre-built query and a pre-built automation action

Additionally, policy automation actions aren't surfaced on the list view, so you have to dig through each automation type to see what actions (if any) a policy takes when it fails.

Potential solutions

Show, and allow editing for, automations when viewing an individual policy. UX could be something like "we run this query and if it fails then perform the actions corresponding to the boxes that are checked." The ability to check the boxes could be left to an edit modal if it's clearer that way.

In addition to the view/edit, we should also e.g. warn if automations won't work on one or more of the selected automation platforms.

This makes things clearer when e.g. you're changing a policy "update to Firefox 129" -> "update to Firefox 130", where you need to push the updated installer package first before updating the query to bump the required version (we should show installer platform and version when that automation is selected).

This should replace the existing software/script automation dialogs, as "apply this automation in-context" is a much likelier workflow than "apply these automations en masse", at least for admins who don't have a bunch of policies for which they're newly able to associate installers or scripts. Which...since these UI changes would be landing at least one release after script automations go live, anyone who doesn't skip releases won't need this workflow.

For consistency, my thought would be to move web hook and calendar automations as well as installer/script automations, though those automations are configured globally so we would need to find a new place for that UI. But the automations button on the top right of policies would go away, msynr with a "Looking for automations?" link that sticks around for a few releases.

Finally, if a policy has an automation attached, it should show as a column in the policies list, e.g. "Install Mozilla Firefox.pkg" or "Run prime-photon-torpedoes.sh". Bonus points for link-ifying the script or package name to open the relevant artifact in a new tab. Thinking that we keep automations in one column and comma-delimit if there are multiple, but if calendar events and webhooks are common and stacked on top of both each other and install software/run script, maybe one column per automation type makes more sense.

What is the expected workflow as a result of your proposal?

For checking which automations are applied to a policy, I look at the policy list.

For editing which automations are applied to a policy, I click into the policy from the policy list, and either edit the policy on that screen or click Edit and make changes there.

[noahtalerman]

Hey @iansltx thanks for tracking this UX improvement. We'll weigh it at the upcoming feature fest.