starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 15:05:57 +03:00

[GH-ISSUE #427] Feature request: Assign more than one automation policy #259

New issue

Open

opened 2026-03-02 02:14:55 +03:00 by kerem · 6 comments

kerem commented

2026-03-02 02:14:55 +03:00

Owner

Originally created by @manc74 on GitHub (Apr 23, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/427

Originally assigned to: @sadnub on GitHub.

I'm aware you can "cascade" automation policies (so set one to a client, then add another to the site and another to individual hosts which combines them together as you go down the hierarchy which is great), but is it possible to be able to add the ability to add more than one automation policy to a client/site or individual host?

Use case - we have a client with some specialist software that we can monitor and update via "tasks" - by assigning an automation policy to the PC's using the software, we can fire that policy as a "run once" when needed. This is in addition to the other more general policies/tasks already in place for the site/host

Originally created by @manc74 on GitHub (Apr 23, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/427 Originally assigned to: @sadnub on GitHub. I'm aware you can "cascade" automation policies (so set one to a client, then add another to the site and another to individual hosts which combines them together as you go down the hierarchy which is great), but is it possible to be able to add the ability to add more than one automation policy to a client/site or individual host? Use case - we have a client with some specialist software that we can monitor and update via "tasks" - by assigning an automation policy to the PC's using the software, we can fire that policy as a "run once" when needed. This is in addition to the other more general policies/tasks already in place for the site/host

kerem added the

enhancement

label

2026-03-02 02:14:55 +03:00

kerem commented

2026-03-02 02:14:55 +03:00

Author

Owner

@sadnub commented on GitHub (Apr 27, 2021):

Policies can probably be reworked to include multiple. Would add to the complexity and am thinking a policy order (1, 2, 3, etc) would need to be establish per container to see which checks, alert templates, and patch policies will be applied.

Another option would be to remove patch and alert policies from the automation policy and add those direct to the global/client/site/agent. Then I just need to worry about the checks that are added.

@sadnub commented on GitHub (Apr 27, 2021): Policies can probably be reworked to include multiple. Would add to the complexity and am thinking a policy order (1, 2, 3, etc) would need to be establish per container to see which checks, alert templates, and patch policies will be applied. Another option would be to remove patch and alert policies from the automation policy and add those direct to the global/client/site/agent. Then I just need to worry about the checks that are added.

kerem commented

2026-03-02 02:14:55 +03:00

Author

Owner

@Kieran-staffs-tech commented on GitHub (May 13, 2025):

Did this ever get more traction? There are a lot of cases where some agents need additional checks/tasks, whereas others don't. When you reach more than like 20 endpoints, it becomes fairly tedious to add these extra checks and tasks manually.

@Kieran-staffs-tech commented on GitHub (May 13, 2025): Did this ever get more traction? There are a lot of cases where some agents need additional checks/tasks, whereas others don't. When you reach more than like 20 endpoints, it becomes fairly tedious to add these extra checks and tasks manually.

kerem commented

2026-03-02 02:14:55 +03:00

Author

Owner

@christophsanz commented on GitHub (Sep 9, 2025):

This would be essential in my opinion. We have customers with different but overlapping configurations. So having an automation policy for every partial configuration and only assigning those to the customers who need it would be a huge improvement.

E.g.
One "base" automation policy with checks all of our customers need, and other automation policies that can be stacked on top of that for only those customers who need it.

@christophsanz commented on GitHub (Sep 9, 2025): This would be essential in my opinion. We have customers with different but overlapping configurations. So having an automation policy for every partial configuration and only assigning those to the customers who need it would be a huge improvement. E.g. One "base" automation policy with checks all of our customers need, and other automation policies that can be stacked on top of that for only those customers who need it.

kerem commented

2026-03-02 02:14:55 +03:00

Author

Owner

@P6g9YHK6 commented on GitHub (Sep 9, 2025):

This would be essential in my opinion. We have customers with different but overlapping configurations. So having an automation policy for every partial configuration and only assigning those to the customers who need it would be a huge improvement.

E.g. One "base" automation policy with checks all of our customers need, and other automation policies that can be stacked on top of that for only those customers who need it.

you can already do this every level global -> client -> site -> agent cascade polices to the next level this issue is about having multiple polices on each level.

@P6g9YHK6 commented on GitHub (Sep 9, 2025): > This would be essential in my opinion. We have customers with different but overlapping configurations. So having an automation policy for every partial configuration and only assigning those to the customers who need it would be a huge improvement. > > E.g. One "base" automation policy with checks all of our customers need, and other automation policies that can be stacked on top of that for only those customers who need it. you can already do this every level global -> client -> site -> agent cascade polices to the next level this issue is about having multiple polices on each level.

kerem commented

2026-03-02 02:14:56 +03:00

Author

Owner

@silversword411 commented on GitHub (Sep 10, 2025):

Yes this issue is about more than one automation policy per level (there are 4 ATM)

To hazard a guess this will probably be part of tags
https://github.com/amidaware/tacticalrmm/issues/653

@silversword411 commented on GitHub (Sep 10, 2025): Yes this issue is about more than one automation policy per level (there are 4 ATM) To hazard a guess this will probably be part of tags https://github.com/amidaware/tacticalrmm/issues/653

kerem commented

2026-03-02 02:14:56 +03:00

Author

Owner

@christophsanz commented on GitHub (Oct 16, 2025):

This would be essential in my opinion. We have customers with different but overlapping configurations. So having an automation policy for every partial configuration and only assigning those to the customers who need it would be a huge improvement.
E.g. One "base" automation policy with checks all of our customers need, and other automation policies that can be stacked on top of that for only those customers who need it.

you can already do this every level global -> client -> site -> agent cascade polices to the next level this issue is about having multiple polices on each level.

Didn't know about the global policies, that helps a lot thx.

Still it would be nice to have multiple policies, right now i still have to edit multiple automation policies if i have to change a check that needs to run for multiple clients (but not all of them).

Assigning Automation Policies to tags (#653) would be awesome :)

@christophsanz commented on GitHub (Oct 16, 2025): > > This would be essential in my opinion. We have customers with different but overlapping configurations. So having an automation policy for every partial configuration and only assigning those to the customers who need it would be a huge improvement. > > E.g. One "base" automation policy with checks all of our customers need, and other automation policies that can be stacked on top of that for only those customers who need it. > > you can already do this every level global -> client -> site -> agent cascade polices to the next level this issue is about having multiple polices on each level. Didn't know about the global policies, that helps a lot thx. Still it would be nice to have multiple policies, right now i still have to edit multiple automation policies if i have to change a check that needs to run for multiple clients (but not all of them). Assigning Automation Policies to tags (#653) would be awesome :)

kerem referenced this issue

2026-03-14 02:34:17 +03:00

[GH-ISSUE #259] Feature Request: Persistent sorting setting #2110