Settings and activity
20 results found
-
9 votes
Ben Ahlquist
shared this idea
·
-
10 votesBen Ahlquist
shared this idea
·
-
967 votesBen Ahlquist
supported this idea
·
-
80 votes
Hi,
Great news! Your idea has been approved and is planned for implementation.
We appreciate your contribution and will keep you informed about the progress and expected release date, as well as here in the portal.
Best regards,
The Atera Team
An error occurred while saving the comment Ben Ahlquist
supported this idea
·
-
7 votes
An error occurred while saving the comment Ben Ahlquist
commented
IMO the agent on the ticket itself should remain static - as that ticket likely applied to that specific agent. I didn't realize the agent field would dynamically change when a user's profile is updated with a new agent (for instance, in an equipment refresh). And, I didn't realize the User's Related Agent field would change when I change the "Device" field on the ticket.
We reuse and repurpose our equipment and it would sure be nice for the ticket history to follow the equipment/device/agent. We also have users who use multiple devices (also see here: https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/44068440-assign-a-contact-to-multiple-agents-and-or-assign) - a ticket they send in might apply to any one of those devices they "own".
Ben Ahlquist
supported this idea
·
-
194 votes
Hi,
Great news! Your idea has been approved and is planned for implementation.
We appreciate your contribution and will keep you informed about the progress and expected release date, as well as here in the portal.
You can also follow this in our Public Roadmap.
Best regards,
The Atera Team
An error occurred while saving the comment Ben Ahlquist
commented
Any updates on this request? We have about 1/3 of our users that routinely use multiple devices. We currently only are able to set their primary device as the Related Agent, but it would sure be nice to associate multiple devices/agents with one user.
Ben Ahlquist
supported this idea
·
-
8 votesBen Ahlquist
supported this idea
·
-
5 votesBen Ahlquist
supported this idea
·
-
8 votesBen Ahlquist
supported this idea
·
-
5 votesBen Ahlquist
shared this idea
·
-
3 votesBen Ahlquist
shared this idea
·
-
21 votesBen Ahlquist
supported this idea
·
-
758 votesBen Ahlquist
supported this idea
·
-
1,648 votesBen Ahlquist
supported this idea
·
-
30 votes
An error occurred while saving the comment Ben Ahlquist
commented
It seems the only time the welcome email sends is when a user is manually created. We intend to use Azure AD sync (once it's working (https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/47085382-azure-ad-group-sync-query-group-name-to-get-aroun) and CSV import (in the meantime) to provision ALL of our users.
It would certainly be nice to have this email fire during both import functions - really, any time a user is created regardless of method, this email should fire.
Someone spent a lot of time building in the capability of the welcome email in the first place, only to have it designed to work for what I bet is the least-used scenario of user creation.
Ben Ahlquist
supported this idea
·
-
5 votes
An error occurred while saving the comment Ben Ahlquist
commented
This would be very useful!
Ben Ahlquist
supported this idea
·
-
24 votes
An error occurred while saving the comment Ben Ahlquist
commented
This would be very useful!
Ben Ahlquist
supported this idea
·
-
8 votesBen Ahlquist
shared this idea
·
-
3 votes
An error occurred while saving the comment Ben Ahlquist
commented
I'm trying to provision our ~325 users via CSV import today and zero emails are firing in my testing. Add the same users manually in Atera and the emails come through without issue. I've got a support ticket open for this as well. It would sure be nice if this worked.
There's no way I'm manually adding them just so they can get a welcome email. This really needs to be fixed.
Ben Ahlquist
supported this idea
·
-
1,499 votesBen Ahlquist
supported this idea
·
We came to Atera from using PDQ Inventory/PDQ Deploy and were admittedly spoiled rotten with how well that solution worked. This is in the scope of what PDQ refers to as "dynamic collections" - and this is something Atera would benefit hugely from, should they choose to go after this. I tried to keep this brief, and failed miserably - my apologies in advance, and gratitude to anyone that reads to the end ;)
For full context this video does a good job outlining dynamic collections in PDQ: https://www.youtube.com/watch?v=wVWzNhZHPV4
Here's the scenario:
We have ~50 3rd party software titles that we manage on subsets of computers. In PDQ, to manage 3rd party software we simply created a dynamic collection containing "devices with software 'xyz' installed", which we could then target for automated 3rd party software updates and patches.
Take for example our deployment of Visual Studio Code and AutoCAD Inventor. There's maybe 30 users in our company that require VS Code on their computers, and about 40 that require AutoCAD inventor. These are not mutually exclusive lists; there are some users who require both VS Code and AutoCAD Inventor on their computer, and many others that need only one or the other.
We have "overlaps" like this all across our 3rd party software deployments.
I've worked with Atera Support on this and they offered the solution of using folders for 3rd party patch automation - but unfortunately, as an agent can only be a member of one folder at a time, this doesn't help our "overlaps" discussed above.
For the time being we’ve been able to achieve a “good enough/close enough” solution with Atera using the following:
1.) Create 3rd party software bundle and automation profile
2.) Use custom views in the Devices tab to create our “dynamic collections”
3.) Assign Step 1 automation profile to the devices in this view
It’s Step 3 that gives us the trouble, as the automation profile is assigned to devices in the view, rather than the view itself. When we perform Step 3, it only applies to the devices that were in that view at that specific date/time the automation profile was assigned.
This means that, if we were to repurpose a device and it no longer needed the 3rd party automation profile from step 3, it would still have this automation profile assigned until we remove it manually. Likewise, new devices coming in do not pick up the automation profile either – even though they are dynamically added to the saved view. I think if we had the ability to assign an automated profile to a saved view, rather than the devices in the view at that point in time, that would make Atera even more powerful and beneficial to us.
Thanks for considering!