Settings and activity
6 results found
-
3 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 -
21 votes
An error occurred while saving the comment 
AdminDmitry Lukyanenko
(Admin, Atera)
commented
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 votesAdminDmitry Lukyanenko
(Admin, Atera)
supported this idea
·
An error occurred while saving the comment AdminDmitry Lukyanenko
(Admin, Atera)
commented
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 AdminDmitry Lukyanenko
(Admin, Atera)
commented
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 -
6 votes
An error occurred while saving the comment AdminDmitry Lukyanenko
(Admin, Atera)
commented
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 votesAdminDmitry Lukyanenko
(Admin, Atera)
supported this idea
·
An error occurred while saving the comment AdminDmitry Lukyanenko
(Admin, Atera)
commented
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 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