Home · Solutions · Other solutions
Solution · Other solutionsThe disk was nearly full three weeks ago. Intune knew; nobody was reading the list.
The failing laptop fixed before the user opens a ticket
A scheduled robot reads Intune, Defender for Endpoint, mailbox and certificate signals, runs the approved fix for routine cases, tells the user in Microsoft Teams and opens a ticket only when an engineer is needed.
Executive summary
The disk fills, the certificate expires, the update fails again, and the desk hears about it from the user.
The design starts with a schedule rather than an inbox.
Routine faults are fixed when the signal appears rather than when the user calls, so a stream of incidents stops arriving at the desk.
Microsoft Intune device actions; ServiceNow incidents and problem records; the monthly remediation log
Business problem
Devices
Endpoint management produces data, not work. Intune reports compliance, disk, update and encryption state; Defender for Endpoint reports alerts and vulnerable software; Exchange Online knows which mailboxes sit at quota; the certificate authority knows which machine certificates expire next week. Acting on any of it takes a person who filters, prioritises, contacts the user and applies a fix, and the desk has no capacity for work that is not yet a ticket.
So the routine failures are handled backwards. A full disk becomes an incident when Outlook stops syncing, an expired certificate becomes an incident when a site drops off the wireless network on a Monday morning, a mailbox at quota becomes an incident when a customer says the reply never arrived. Engineers fix the same fault on the same laptop model twenty times without anyone noticing that it is one problem rather than twenty.
Users conclude that the laptops are unreliable and IT is slow, which is unfair to both. The pattern holds because monitoring and remediation sit in different tools owned by different teams, each fix is cheap on its own, and nobody is measured on prevention.
How it works today
- SystemTelemetry records the failing disk, the third failed update and the certificate that expires in eleven days
- WaitingNothing is assigned to read it, so the finding sits on a dashboard until the symptom appears
- PersonThe user notices Outlook has stopped syncing, works around it for two days, then calls the desk
- PersonThe analyst collects the device name, the model and the error text that the tenant already held
- WaitingThe ticket goes to an engineer and waits for a callback window that suits a shift worker
- SystemThe engineer applies a known fix, clears storage or retries the update, and closes the ticket
- Risk of errorThe same fault on the same model returns next week; no pattern is recorded, and the machine is replaced early or late
Why the current process costs more than it appears
The budget shows headcount, not what it is spent on.
- Desk minutes are half the bill. The user loses about as long again, at the worst moment: before a client visit, during a shift handover, in a substation with the safety pack on a dead laptop.
- A device that fails a compliance check or misses a patch stays exposed until somebody acts, which makes the interval between signal and fix a security number, not a service number.
- Certificate expiry does not arrive one device at a time. It takes a site off the wireless network in a morning, and the desk hears it as twenty simultaneous calls.
- Replacement decisions follow complaints rather than health data, so the budget buys machines a twenty-minute fix would have kept, while engineers spend skilled hours on scripts they have run before.
Cost of inaction
Neither of the first two rows prices the exposure: a device that misses a patch or fails a compliance check stays that way until somebody acts, and the interval between signal and fix is the number a security audit asks for. The middle row adds 300 prevented incidents a month at 40 minutes each, so 200 hours at €36 an hour; a technician's hour in a substation is worth more, and no row prices the safety documentation on the dead laptop.
A year of this leaves the desk busier rather than calmer: the estate ages, so failures rise, and headcount adds devices at the same time. Certificates keep expiring by surprise, sites keep losing wireless for a morning, and the budget keeps buying replacements a twenty-minute fix would have avoided.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
An energy utility with 6,000 staff, about 7,500 Windows and macOS devices managed in Microsoft Intune with Microsoft Defender for Endpoint, and a service desk running on ServiceNow.
Around 600 device-related incidents a month: low disk, failed updates, compliance and encryption failures, battery and hardware faults, certificate problems and mailboxes at quota. Substation technicians depend on their laptops for safety documentation.
Each incident arrives as a ticket after the user notices the symptom; the desk re-gathers data the tenant already holds, and an engineer applies a known fix.
About 34 minutes of desk and engineer time per incident and about 40 minutes of the user's own time around it; the IT director estimates half were visible in the telemetry before anyone noticed.
A scheduled UiPath Robot reads Intune, Defender for Endpoint, mailbox usage and certificate expiry, applies the utility's thresholds and sorts each finding three ways: an approved runbook that runs and then tells the user in Microsoft Teams, a Teams card asking for two steps, or a ServiceNow ticket opened with telemetry and a proposed fix before the user has called.
In the modelled case half of the 600 monthly incidents stop arriving as tickets, engineers open tickets that already contain the evidence, and recurring faults are written down as problems. The figures are a model, not a measurement.
Proposed solution
The design starts with a schedule rather than an inbox. A UiPath Robot runs on an Orchestrator time trigger and reads inventory and compliance state from Microsoft Intune, alerts and vulnerability state from Microsoft Defender for Endpoint, mailbox usage from Exchange Online and expiry dates from your certificate authority. It then applies your own thresholds: five percent of disk, three failed updates in a row, fourteen days to certificate expiry, ninety percent of mailbox quota.
Each finding above a threshold gets one of three outcomes, and that split is the whole design. Routine and safe: the robot runs an approved remediation runbook, clearing temporary storage, retrying the update or requesting a certificate renewal, then tells the user in Microsoft Teams what was done. User action needed: a Teams card with the two steps to take and a snooze button, and the desk stays out of it unless the card expires. Engineer needed: a ticket opens in ServiceNow through UiPath Integration Service carrying the telemetry, the history and a proposed fix, before the user has called.
Where the same fault keeps appearing, a UiPath Agent reads the month's remediation log and drafts a root-cause note: this model with this dock firmware, this office with this certificate template. The draft stays a draft: it reaches the problem manager as a UiPath Action Center task in Teams and becomes a problem record only if a person accepts it. The language model reads the log; it never runs a fix and never touches a device.
Microsoft Intune inventory, compliance state and device actions; Microsoft Defender for Endpoint alerts and vulnerability state; Adaptive Cards in Microsoft Teams; UiPath Orchestrator time triggers, credential store and audit; UiPath Action Center tasks completed in Teams; AI Trust Layer model allow-list and PII masking for the agent
The threshold model and classification rules, the remediation runbooks as robot workflows, the user cards and their follow-up logic, the ticket template with evidence attached, the remediation log and the prevention report
Microsoft Graph reads of Intune managed devices, Exchange Online mailbox usage and Defender for Endpoint state under one scoped identity; the ServiceNow connector in UiPath Integration Service for incidents and problem records; the certificate authority's expiry report
How the automated process works
- AutomationOn the schedule, a robot reads Intune, Defender for Endpoint and mailbox signals through Microsoft Graph, and expiry dates from the certificate authority
- AutomationEach device is measured against your thresholds; findings below them are recorded and nothing else happens
- AutomationRoutine and safe findings trigger an approved remediation runbook, which runs and then verifies its own result
- SystemThe user gets a short note in Microsoft Teams saying what was fixed, or a card with the two steps only they can take
- SystemAnything an engineer must see opens as a ServiceNow ticket with the telemetry, the history and a proposed fix attached
- PersonThe engineer resolves the non-routine cases, starting from evidence instead of questions
- AutomationEvery run, runbook and outcome is written to the Orchestrator log and the monthly record
- PersonA UiPath Agent drafts root-cause notes from that record; the problem manager accepts or discards each one as an Action Center task in Teams
Human-in-the-loop model
Automation handles
- Reading device, security, mailbox and certificate signals on a schedule and applying your thresholds
- Classifying every finding as routine, user action or engineer, then running the approved runbook and confirming the fix took
- Posting user notes and cards in Teams, and opening tickets with the evidence already attached
- Drafting root-cause notes from the monthly remediation log
People decide
- Which runbooks may run unattended, on which device groups, approved one at a time
- Every diagnosis the runbooks do not cover, and every change to a production device outside them
- Whether a drafted root cause becomes a problem record or is discarded
- Thresholds, policy, and when a device is replaced rather than repaired
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- Microsoft Intune inventory and compliance state
- Microsoft Defender for Endpoint alerts and vulnerabilities
- Exchange Online mailbox usage
- certificate expiry from the certificate authority
- device-to-user mapping in Microsoft Entra ID
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Agents
- UiPath Action Center
- UiPath Integration Service
Target systems
- Microsoft Intune device actions
- ServiceNow incidents and problem records
- the monthly remediation log
- the prevention report
Human touchpoints: user notes and cards in Microsoft Teams; Action Center tasks in Teams for the problem manager; the engineer's ServiceNow queue
Technologies used
inventory, compliance state and the device actions the runbooks call
Aalerts and vulnerability state that raise a device's priority
Areads device, mailbox and security data under one scoped application identity
Athe scheduled run, the runbooks, credential store, retries and audit
Auser notes, and cards asking for the two steps only the user can take
Aproactive incidents and problem records with telemetry attached
Adrafts root-cause notes from the remediation log under a model allow-list
Athe problem manager accepts or discards each drafted root cause
AIllustrative economic model
What it is worth, with the arithmetic shown.
The preventable share is the only assumption that really moves this model, and it is set at half: 300 of the 600 monthly incidents are treated as visible in the telemetry early enough to be handled without a ticket, so the calculator starts at 300 rather than 600. Thirty-four minutes is the desk and engineer time per incident and €51 the blended fully loaded hourly cost. The user's own time is priced in the next section, not here. Licences, build and runbook development sit outside these figures, and nothing was measured at a client.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Routine faults are fixed when the signal appears rather than when the user calls, so a stream of incidents stops arriving at the desk
- Users are told what happened, or what to do, in a Teams message, which replaces a surprise failure with thirty seconds of reading
- Tickets that do reach an engineer arrive with the telemetry, the history and a proposed fix, so diagnosis starts from evidence rather than questions
- Recurring faults on a model or at a site become named problems, which stops the twentieth identical repair and shortens the exposure window on unpatched machines
The management view
- Prevention becomes measurable: findings per run, fixes applied without a ticket, user actions completed, tickets opened before the user called
- Patch and compliance exposure turn into a daily number with an owner, not a monthly report that arrives after the window has closed
- Engineers' time shifts from scripted repairs to real diagnosis, and it shows up in the numbers instead of an impression
- The answer to "what runs on our devices without a human" is a versioned list of approved runbooks with named owners
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- The robot reads through Microsoft Graph with an application identity limited to device, security and mailbox read scopes plus the device actions its runbooks call; secrets are resolved at run time from a credential store, Orchestrator's own or your Azure Key Vault
- Every runbook has a named owner, a version and a list of device groups it may touch. One that fails stops and opens a ticket instead of retrying blindly, and the pilot runs in detection-only mode first
- The agent reads the remediation log and nothing else. It runs behind the AI Trust Layer with a model allow-list, PII masking and its own audit trail, and its output stays a draft until the problem manager accepts it
- User-facing cards carry only what the user needs in order to act; processing stays in the EU regions of UiPath Automation Cloud and Microsoft 365, and every run and fix can be reconstructed from the Orchestrator log
Why now
The trigger is usually external: a security audit asking how long a known vulnerability stayed open, a field workforce that cannot wait for callbacks, or a hardware budget spent on replacements a fix would have prevented
Intune and Defender for Endpoint now expose through Microsoft Graph most of what a technician used to collect by hand, and the device actions that correct the routine states are reachable the same way, under a scoped identity
A robot runs those actions under approval and audit, and a language model can read a month of remediation logs and propose the patterns inside them; the desk and engineer time alone is modelled at €8,670 a month
Relevant executive roles
The endpoint estate becomes something IT manages ahead of failure, with a prevention number to show the board instead of a ticket count
A stream of avoidable incidents leaves the desk, and engineers stop repeating scripted fixes on the same three models
Field and frontline staff lose fewer hours to a laptop that failed on a day the telemetry had already flagged
Common questions and objections
It can, for specific scripted checks. What this adds is the classification across Intune, Defender for Endpoint, Exchange Online and your certificate authority in one run, the message to the user, the ticket with evidence and an approval trail for every runbook.
Every runbook is approved by a named owner, scoped to device groups and versioned, and the pilot runs in detection-only mode until the desk agrees with the classification. The alternative is not "no fixes": it is the same fixes by hand, with no record.
Alerts without an action attached drown everyone. Here each finding leaves the run as a runbook, a user card or a ticket, and the count of each is how you tell whether a threshold is set right.
When this is not the right solution
- Fewer than a few hundred devices, where one technician holds the whole estate in view and a quarterly check costs less than a flow
- Devices are not managed in Intune or an equivalent, so there is no telemetry to read; the first project is endpoint management, not this one
- A managed endpoint provider already owns proactive remediation under contract, or device incidents are rare and the desk's time goes elsewhere
A question for the next management meeting
Would we rather hear about the 212 devices that are about to fail from tonight's dashboard, or from their users over the next month?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- A match of one month of device tickets against the telemetry of the same devices, which settles the preventable share with your data
- The threshold model and classification rules, agreed with the desk and with security
- The first remediation runbooks, typically disk, update retry and mailbox quota, each approved and scoped to a device group
- User cards and notes in Teams, the ServiceNow ticket template with telemetry and proposed fix, and the route from a validated root cause to a problem record
- The remediation log, the prevention report and the agent configuration for root-cause drafting
We need from you
- A Microsoft Graph application identity for the robot, scoped to device, security and mailbox reads plus the device actions its runbooks call
- A named runbook approver and a problem manager, and one month of device tickets to match against the telemetry
- Your thresholds, or a first draft of them from the desk, and the device groups the pilot may act on
Stages
Discovery
Match a month of tickets to the telemetry of the same devices, and size the preventable share
Detection only
The classification runs and reports; nothing is remediated, and the desk checks the findings against reality
First runbooks
Three routine fixes go live for one device group, with every run reviewed
Scale
More runbooks and device groups, thresholds tuned from what the runs find
Patterns
The agent drafts root causes once the log is worth reading, and the problem manager validates them
Departmental. Effort follows the number of telemetry sources, how many runbooks the desk wants automated, and how strict your change process is for a production device.
The failure was on the dashboard three weeks before it was on the phone.
Send us one Intune compliance export and one month of device tickets. We match them and give you back the incidents that were visible in the telemetry before anyone reported them, with the three runbooks that would have closed them first.
Compare one Intune export with your ticketsThe neighbouring process usually has the same problem
Four IT tickets in ten follow a known procedure, and every one of them still queues for an analyst.
View solution Other solutionsStatus, outage and change news that reaches people firstThe outage email leaves after the outage, and one ticket comment in five is the same two words.
View solution Other solutionsIncidents staffed, communicated and closed by one flowThe tool records what happened. Finding owners, chasing updates and reading nothing on Friday is done by people.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsServices & ITShared services