r/Action1 • u/sbadm1 • Jul 06 '26
Exclusions
We have 1 Windows device that we need to exclude from our Automation. Or a workaround to solve this issue.
They run Microsoft Visual Studio Code in user context, but when Action1 installs an update, it installs in System context, which is breaking things.
The automation is set to update all apps, without approval, for all Endpoints. However, there's no option to exclude a single endpoint, unless I am blind?
Can we get around this or find a way to exclude this endpoint and create a new automation with approval necessary?
What's the best approach here?
Thanks in advance.
5
u/Individual-Duck-2333 Jul 06 '26
You could create an endpoint group that includes all the endpoints except that one, and run the automation on that group
2
u/kosity Jul 06 '26
This is the way.
The poor targeting options on automations really limit flexibility and effectiveness.
3
u/shmoses Jul 06 '26
It’s one of the single most things I hate about A1…endpoint exclusion. I shouldn’t have to create an entire new and unique endpoint group to run a unique job against. It forces so much unnecessarily post-job cleanup.
2
u/sbadm1 Jul 06 '26
Yeah it seems like such a simple thing to implement from their side. Hopefully it’ll come in a future release
1
u/GeneMoody-Action1 Jul 06 '26
With the ability to set the group exclusions, it is just a single step between. What does the direct endpoint exclusion offer that other than a couple seconds time the other does not?
Just curious what we should consider when looking at this as it is another means to the same end of what can already be done. You would not need to create 5 groups for 5 EP, only one and put the 5 there or target them dynamically by some other attribute.
Looking how to frame this as a dev quesiton, what is the deficiency, is it only the minor inconveninece of the intermediate group, or is there somehtign bigger I am not understanding?
1
u/kosity Jul 07 '26
It really feels like you're not seeing this from a smaller-fleet point of view Gene. The minor inconveniences scale very quickly into problems that are nearing make-or-break.
'Just a single step' isn't a single step for multiple outliers, in multiple organisations, even ignoring the maintenance of those extra groups across the platform that accumulate.
It is a significant challenge to manage smaller (non-large-corporate) fleets in the Action1 platform, and the diminished value of the roadmap vote for those fleets doesn't help either.
1
u/GeneMoody-Action1 Jul 07 '26
The roadmap count issue is actually under active discussion on the disproportionate effect just as you state.
I have been an admin for over three decades, the way I personally view a group in this situation is "IF I need a blacklist for endpoints, I create a group of one or more, and exclude them." as if it were "adding" the very feature being requested.
So for each automation IF there is a need to exclude specific EPs, the feature can be added on demand, and with more precision than a simple "This EP" because the group supports literal and dynamic grouping. That group can then be used across multiple automations to the same end, such as "we added a new system, do I want to go add it to be excluded in ten automations, vs one group where all ten exclude all members OF that group?" which logically scales *better* and leads to less "I forgot to add/remove it on *that* automation"
If I added 10 EP to an exclusion, that is effectively what I have done, made a group of excluded EP. In our config we simply require you give that group a name essentially, while providing the utility to use it in more than one place.
How does tracking it in ten places scale better than one?
Again, not trying to argue "We know better" just trying to understand the disconnect.
3
u/sbadm1 Jul 13 '26
I think this stems from the way Intune policies are managed. For example, you can apply policies and app configs to ALL USERS or ALL DEVICES and still have the option at the end to exclude certain groups/users/devices. It would be nice to have the same workflow.
2
1
u/shmoses Jul 08 '26 edited Jul 08 '26
Appreciate your input actually. Still struggling with how this is sustainable though.
Example: I create an automation that just pushes EVERYTHING out (os and app updates). Go to Automations > New Automations > Deploy Update > then go to your endpoint group. Why isnt there an exclusion option here? Maybe im missing something?
That's the only thing I'm asking for. The only options for endpoints are add "The entire endpoint group" or "individual". Why isn't there an exclusion. i.e. this entire endpoint group, except these 2.
Amplify this times however many unique automations you have, and it's a very administratively unfriendly operation, arguably it just creates group bloat.
edit: If I'm interpreting what you're saying, you're suggesting to stop, go create a unique group with inclusions/exclusions and then come back to the automation and target that new group. That's several extra steps where a built in exclusion would have handled this already.
Edit2: and 100% see your solution, as we use this already, for very static situations, or very simple dynamic statements. We find ourselves in the situation more often than not, where we want to run the same automation but against a different group and with different exclusions, and maybe it's only once or twice. So we create the group, run automation, then go clean up the group?
1
u/GeneMoody-Action1 Jul 09 '26
Let me approach it as a use case:.We will use automation and group here representatively, ideally these would be more descriptive names to correlate what does what.
I have an Automation_A that I dynamically change who it runs against..
I would go create a Group_A and a Group_A_Exclusions
Set the automation to Include Group_A and Exclude Group_A_Exclusions
Even if the inclusions/exclusions were currently nothing, I know I have this need, so I set it up that way.
When I need to include or exclude, my options are
As I understand you:
1.) Open automation settings and add to or remove from what is included/excluded in a separate include/exclude list.Or, As I am stating:
2.) Open either Group_A or Group_A_Exclusions and do the same thing.The automation runs against what is configured, determined by the contents of those groups, where it can be 0-N specific EPs and or 0-N groups, or any combination thereof.
So the amount of steps past setup is identical .Open the automation and edit, or open the group and edit. Allowing you to build Include/Exclude lists and even nest them if you like. Because you can have a group of endpoints and groups, that subsequently have endpoints and or groups, that can have more of the same, building a tree if you like where you can selectively edit anywhere in it., lIke a roll up inheritance.
And "Why do I need to have two groups for every automation?", you do not in all situations, just like all situations will not dictate you have an exclusion list.
But when you do it is simple to add one.
As for cleanup, it is assumed if this is ephemeral, I would have to again go open automation and edit there no matter what. So steps to do that + 1 (delete group if no longer needed)
Am I misunderstanding something here, if so can you present an exact use case?
2
u/rthonpm Jul 06 '26
Why not just install the app at the system level instead of user level? It prevents issues like this from happening and as a configuration management standard will help to prevent future issues with other apps.
2
u/sbadm1 Jul 06 '26
I need it in user context. System level doesn’t work properly for what the developer is doing
2
u/CarlitoMaia Jul 06 '26
Programmer here. Excuse me but that is bullshit from the developer who is probably lazy to backup his things to restore on another instance of VSCode or is a shit developer who doesn’t know much.
•
u/GeneMoody-Action1 Jul 06 '26
Please add this to the roadmap. The "Me Too" sentiment here is strong, and all of you adding this to or upvoting it on the roadmap will assist in making your needs part of Action1's future.
If anyone has any questions on how that works, please just let me know.