Settings and activity
9 results found
-
5 votes
An error occurred while saving the comment -
133 votes
An error occurred while saving the comment Hi, you're absolutely correct with saying "Mac-related items we voted for ages ago getting combined into this feedback item, so either that's a (possible) good sign"
We have an internal ongoing effort to redefine how we approach UserVoice.Consolidating similar ideas into a big idea with several items to be considered and factored in before we plan our next Product enhancements - that's the End goal.
I will ping our RMM team on the matter and get back to you and the group.++
Dima L
Technical Product Marketing Manager
Atera -
9 votes
AdminDima Lukyanenko
(Technical Product Marketing Manager, Atera)
supported this idea
·
An error occurred while saving the comment Hi everyone
The search engine and the approach to it is being worked on. The reelase is coming soon. We're polishing some key aspects to start the transition to improve it for you.
++
Dima L
Technical Product Marketing Manager
Atera -
4 votes
Hi,
Thank you for your valuable suggestion. While we won't be implementing this idea in the immediate future, it has been added to our list for future consideration.
We continuously review user feedback to inform our development priorities, so your idea remains on our radar. You are also welcome to review the most recent comment added from our Product Marketing Team.
http://atera.uservoice.com/forums/936306/suggestions/50683820
Best regards,
The Atera Team
An error occurred while saving the comment Hello Derek, thanks for your request!
Where we are today:
Webhooks exist now (Webhooks are available for Enterprise & SuperPower plans). You can trigger a webhook from Ticket Automation Rules on status changes.
The native timer itself can’t be started/paused by rules yet.KB on the matter: https://support.atera.com/hc/en-us/articles/13688068743964-Webhooks#Createwebhook
What’s coming shortly:
- The API endpoint to add work hours to a ticket (POST /v3/tickets/{ticketId}/workhours) is planned to be shipped shortly.
- Once live, you’ll be able to combine status-change webhooks (Webhooks are available for Enterprise & SuperPower plans). with this API to automatically create start/stop time entries based on your ticket statuses (e.g., In Progress → start, Pending/On Hold → pause, Resolved → stop).
- This won’t “press” the in-app timer button, but it will record accurate time in Atera for reporting and billing.High-level setup (when the API is live):
- Automation Rule: On status change → Send Webhook (ticketId, newStatus, technician, timestamp).
- Small relay (serverless/app) receives the webhook (Webhooks are available for Enterprise & SuperPower plans). and calls /workhours to write the appropriate time entry (billable flag, notes, rate as needed).
- Keep in mind the simple safeguards to avoid duplicates if a tech also logs time manually.++
Dima L
Technical Product Marketing Manager
Atera -
27 votes
An error occurred while saving the comment Hello, great suggestion on color-coding ticket statuses.
How it works today:
- Colors are tied to the status behavior (the lifecycle bucket), not the label text.
- You can name statuses anything (e.g., “Waiting on Vendor”), and map each one to a behavior. The color follows the behavior.Current color scheme (fixed):
Open → Blue
Pending → Orange
Resolved → Green
Closed → GrayWhat to do:
- Create or edit your custom status names (e.g., “In QA”, “Waiting on Customer”): Data Management -> Custom Fields -> Ticket -> Status
- Assign a behavior to each status: Open, Pending, Resolved, or Closed.
- Save. Everywhere the status appears, it will show with the corresponding color above.Notes / limits:
- Per-status custom colors aren’t supported right now; the palette is as listed.
- Your labels remain fully customizable - only the behavior determines the color.++
Dima L
Technical Product Marketing Manager
Atera -
68 votesAdminDima Lukyanenko
(Technical Product Marketing Manager, Atera)
supported this idea
·
An error occurred while saving the comment Hello everyone - thanks for the nudge and for spelling out the driver-vs-OS need so clearly. Good news: you can achieve this separation in Atera today.
TL;DR: You can hide/suppress hardware driver updates from your working view, report OS-only compliance, and bulk-act on drivers separately using Advanced Filters and the Patch Management Dashboard.
Method #1: do it in Advanced Filters (Devices page / Devices tab in the Site/Customer section):
- Open Filters, at the bottom select Advanced Filters
- In advanced Filters, set Available Patch Class = Hardware driver updates to count just the driver-related updates or exclude them.
- Save as a View for one-click OS-only (no drivers) or Drivers-only triage.
- Run actions from the filtered list -OR- use the the Patching Dashboard / "Patch Search & Deploy" Operational report to force install them (if that is needed)Method #2: Patch Management Dashboard:
- Overview tab: use the Update Type selector to show only Hardware driver updates or everything except drivers to see your true OS patch posture. Pro tip: OS Patching status with all classes checked might display an inaccurate picture. Just 1 missing patch will consider the corresponding device as not "Fully Patched". It's recommended to go Class by Class to get more accurate data.
- OS Patches tab: isolate Hardware driver updates with a filter and perform mass install on drivers (when you purposely choose to), or work OS-only for regular servicing.Operational separation: drivers and OS appear in separate, filterable lanes, so drivers no longer inflate “missing patches” in your day-to-day OS view.
Reporting clarity: dashboards filtered to exclude drivers give accurate OS compliance numbers; you can also review Drivers-only when you need to plan onsite/controlled updates.
Control: you decide when to install/ignore drivers in bulk, independent of routine OS servicing.Notes:
If you still prefer a global “suppress drivers everywhere” toggle, we will review this internally as part of our upcoming RMM efforts; meanwhile, the workflows above deliver the practical outcome (clean OS counts + separate driver handling) today. I attached two screenshots for your reference.I hope this helps you and the group.
++
Dima L
Technical Product Marketing Manager
Atera -
15 votes
An error occurred while saving the comment Hi everyone, great idea, and thanks for the concrete “Sales” example!
Today, while the platform still has the classic four ticket Types, you can achieve your “custom types” outcomes (e.g., Sales, Projects) using Technician Groups + Flexible SLAs and (optional) custom statuses - with clean reporting and no break-fix SLA inflation.What this delivers:
- Cleanly separate lanes (e.g., Break-Fix vs Projects/Sales) without new system Types.
- Project/Sales work won’t distort Break-Fix SLA metrics.
- Enables different automation behavior (e.g., no customer emails for Sales; custom status path).Prerequisites:
- Flexible SLAs must be enabled on your tenant.
- If you still see the "legacy” SLA UI, more information on what has changed can be found here: https://support.atera.com/hc/en-us/articles/215286388-Manage-Service-Level-Agreement-SLA-policies
- To switch: contact Atera Support or your CSM and request Flexible SLAs to be enabled.How to set it up after the Flex SLAs are in place (5 quick steps):
1) Technician Groups
- Keep Tier 1/2/3 for Break-Fix.
- Add a dedicated Projects (or Sales) group. (Same engineers can belong to multiple groups.)2) SLA Policies:
- Break-Fix SLA = your standard targets.
- Project/Sales SLA = longer/milestone-friendly targets.3) (Optional) Custom Statuses:
Examples: Sales – Requested → Sales – Ordered → Sales – Delivered/Closed (or a project flow like Discovery → In Progress → Review → Closed).4) Ticket Automations (the router):
- Properties: use a custom field (e.g., Work Type = Sales/Project), a portal category, or a ticket template.
- Actions: assign to Projects/Sales group, apply Project/Sales SLA, set starting status.5) For your Sales example: exclude these tickets from any “notify customer” automations so no external email is sent by default.
6) Reporting:
- Filter by Technician Group = Projects/Sales and/or SLA Policy = Project/Sales to isolate workload and KPIs.
- Break-Fix SLA reports remain clean since different SLA + separate group are used.Why this matches your request:
- Different automation rules per “kind of ticket” (via routing conditions).
- Distinct status flows and SLA expectations for Sales/Project vs Break-Fix.
- Uses indicators that are consistent across clients (group/SLA/status), avoiding reliance on fields that aren’t available in the mobile app.Current limitation:
- Atera still supports four Types; the above pattern delivers the outcome today without adding new Types using two new delivered features.I hope this helps you and the group.
++
Dima L
Technical Product Marketing Manager
Atera -
20 votes
An error occurred while saving the comment Hi Charles,
From what you described in the idea, should it be for any software that they want or for a specific list of software that you can pre-define?
++
Dima L
Technical Product Marketing Manager
Atera -
86 votesAdminDima Lukyanenko
(Technical Product Marketing Manager, Atera)
supported this idea
·
An error occurred while saving the comment Hi everyone!
We are excited to share that we have added the following fields and they are available to everyone on the "Devices" page.
KB Link on the matter: https://support.atera.com/hc/en-us/articles/9903603088284-The-Devices-page#EditcolumnsList of values we have added:
- Last login
- Availability
- Device type
- Pending reboot
- Site (Customer - MSP)
- Folder
- Alerts
- Last patch scan
- Available patches
- Software updates
- Public IP/hostname
- Last reboot
- OS edition
- OS version
- Department
Hi there,
Yes - you can control remote-access approval and behavior per connection type using roles and configuration policies. Here’s the quickest way to set it up.
Role-based access (what a technician is allowed to do):
Admin → Access roles → New role (or edit).
- Remote management: allow access to Workstations, Servers, or both.
- Scripts: allow/deny Run scripts and limit by script categories (e.g., block server-only scripts for endpoint techs).
Save → add the relevant technicians to this role (Members tab).
Account-level Splashtop settings (default for the tenant):
- Admin → Settings → Remote access → Splashtop settings.
- Choose attended (end-user approval required) or unattended (no prompt) and set other defaults.
- Save.
Per-site/folder override via configuration policy:
- RMM → Configuration policies → New policy (or edit).
- Splashtop section → enable “Override account settings.”
- Set the mode you want for this scope (attended or unattended).
- Assign the policy to a folder/site or specific agents to enforce different rules per group.
- Save and apply.
Note: this override currently applies to Windows devices.
Tips
• Use multiple policies (Folder-based/agent-based) if you need different rules for servers vs workstations or by customer/site.
• Pair policy overrides with Access roles to both limit who can connect and how connections behave.
KB on the matter: https://support.atera.com/hc/en-us/articles/115001957308-Splashtop-remote-access#ManageSplashtopaccessviaconfigurationpolicyoverrides