Settings and activity
8 results found
-
3 votes
Ian Morris
supported this idea
·
-
16 votes
An error occurred while saving the comment Ian Morris
supported this idea
·
-
5 votesIan Morris
supported this idea
·
-
7 votesIan Morris
supported this idea
·
-
6 votesIan Morris
supported this idea
·
-
23 votesIan Morris
supported this idea
·
-
4 votes
An error occurred while saving the comment Ian Morris
commented
First, I want to say that we genuinely love the Atera platform. It’s central to how we operate, and we actively want to deepen our commitment to it. The automation, visibility, and overall direction of the product are excellent, which is why this issue stood out so starkly for us.
We recently experienced a serious operational incident caused by the current behaviour of the Remote Access settings UI.
What happened
We manage thousands of devices across many customers, often onboarding environments where previous MSP tools or customer-managed tools (for example, ScreenConnect) are already present on endpoints. In our environment, Splashtop is our only approved and enabled remote access tool.However, on the Remote Access settings page, the dropdown at the top of the screen:
Immediately switches the global default remote access tool
Enables that tool
Triggers uninstall actions for the previously enabled tool
Applies the change across all devices
Does all of the above without any warning, confirmation, or explanation
In our case, someone dropped down the list while navigating the page, assuming it was informational or a way to view configuration options. That single action silently changed the default remote access tooling for thousands of devices.
As a result:
Splashtop was uninstalled (or queued for uninstall) across the estate
Devices began surfacing ScreenConnect as the active remote tool simply because it was already present on endpoints
Customers were rightly asking why remote access software had been installed or changed without consent
We were left explaining and remediating a change that no one knowingly approved
Why this is a UI problem
The dropdown visually behaves like a navigation or filter control, not a destructive global action.
There is no indication that selecting an option will:Change account-wide behaviour
Impact all devices
Trigger installs/uninstalls
Override existing operational decisions
Compounding this, the actual enable/disable options for tools exist elsewhere on the page, which reinforces the assumption that the dropdown is informational rather than authoritative.
What we are requesting
At a minimum, one (or more) of the following safeguards should be introduced:A confirmation prompt clearly stating the impact
Example:
“Changing the default remote access tool will affect all devices and may trigger installs or uninstalls. Are you sure?”Separation of concerns
Use the dropdown purely as a view selector
Require an explicit “Set as default” or “Apply globally” action elsewhere
Change logging visibility
Clear audit entries for default remote access changes
Ideally surfaced inline on the Remote Access settings page
Optional role-based restriction
Ability to limit who can change global remote access defaults
This is not a request for new functionality, but for protection around an action that has very large blast radius and real customer impact.
We are very keen to continue expanding our use of Atera, but incidents like this make it difficult to do so confidently. Addressing this would significantly improve operational safety and trust in the platform.
Thank you for listening, and for continuing to build a genuinely powerful product.
Ian Morris
shared this idea
·
-
2 votesIan Morris
shared this idea
·
Hi,
We make heavy use of the Atera API and overall it’s solid. Device inventory, patching data, alerts etc are all there and work well. It’s one of the reasons we’ve built around Atera rather than trying to work around it.
One thing we keep hitting though is the lack of installed software inventory via the API.
In the UI, Atera clearly has visibility of what software is installed on each device, but via the API we can’t get that same data. We can pull hardware details and patching info, but not the actual list of installed applications.
That’s a real limitation for us in day-to-day operations. Software inventory is what lets us:
spot unauthorised remote tools or leftover MSP software
identify risky or outdated applications
audit customer environments properly
build meaningful reports without manually digging through the UI
automate any kind of software-based checks or remediation
Without that data exposed, we’re forced back into the UI or into separate tools, which feels like an unnecessary gap given how strong the rest of the API already is.
We’re not asking for anything exotic. Even a basic, read-only endpoint that returns installed software per device (name, version, publisher if available) would unlock a lot of value and let us go much further with automation and reporting.
It would also make Atera far more compelling as a single source of truth for device state, especially for MSPs who are building their own tooling on top of the platform.
Just wanted to raise it as this is one of the biggest blockers we keep running into when using the API.
Thanks for listening, and keep up the good work.