Settings and activity
25 results found
-
27 votes
An error occurred while saving the comment -
69 votes
AdminDima 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 -
21 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 -
88 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
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 → Gray
What 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