Home · Solutions · Other solutions
Solution · Other solutionsOrders, refresh and returns run against one register that Intune confirms every night
Every laptop order, refresh and return against one register
Orders start from the HR start date, refresh becomes a planned cohort, returns start on the leaver event, and one register reconciled with Microsoft Intune nightly says where every device is.
Executive summary
Three spreadsheets describe the same laptop, starters wait, refresh happens at failure and leavers' devices vanish.
The register is the centre of the design, and it is deliberately the list you already have.
Starters have a device on day one, because the order starts from the HR start date rather than a manager's memory.
the register in Microsoft Lists (or the CMDB); SAP purchase requisitions and fixed assets; Microsoft Intune wipe
Business problem
Devices
Device events are frequent, cross-functional and tracked nowhere in particular. A new-hire order needs HR's start date, the manager's choice from the catalogue, procurement's purchase order and IT's enrolment, and every hand-off between the four happens by email. Refresh is a policy, four years, that nobody applies, because finding the eligible devices means joining Intune's inventory to the finance ledger by hand. Returns depend on the leaver's goodwill and a courier label somebody has to generate.
Each function's list serves its own purpose well enough, which is why the problem persists: procurement knows what it ordered, IT what it enrolled, HR who started. The gaps land in three different budgets, as idle starters, lost devices and unplanned refresh spend, so no single director sees the whole cost.
At scale the gaps compound. Devices die on a clinic day and are replaced at list price in a hurry, while the ledger carries assets that no longer exist. Unreturned devices are a data protection exposure until wiped and a loss when never recovered. Insurance and audit want a register that matches reality; three spreadsheets do not.
How it works today
- PersonHR confirms a start date; the hiring manager emails IT for a laptop, days after everyone else knew the date
- PersonIT asks which model; procurement raises a purchase order in SAP from the thread; each adds a row to its own tracker
- WaitingThe device waits on the stockroom shelf at head office until someone has time to enrol it
- SystemIT enrols the device in Microsoft Intune and hands it over; the asset list is updated later, if at all
- Risk of errorFour years pass with no refresh trigger; the device fails on a clinic day and a replacement is bought at list price
- WaitingHR mentions the leaver after the last day; IT emails the leaver about the device and waits
- Risk of errorThe device is "in transit" in one sheet and "returned" in another, unwiped until proven otherwise, until the auditor asks
Why the current process costs more than it appears
Behind every exception is an hour nobody logged.
- Idle starters are paid in full: three days on a borrowed machine is three days of salary for reduced work, plus the manager's hours arranging a login and a workaround.
- Refresh at failure is the most expensive refresh there is, one device at list price with express delivery on a clinic day, instead of a cohort at a negotiated price in a planned month.
- Every unrecovered device is an unwiped one until somebody proves otherwise, and for a healthcare provider that is a data question first and a replacement cost second.
- Finance depreciates devices that no longer exist and IT enrols devices finance has never seen; the difference surfaces at audit as a finding.
Cost of inaction
Unrecovered devices are unwiped devices until proven otherwise, and in a healthcare provider that is a data question before it is a financial one. The middle row prices only the replacement, 36 devices at a modelled €850, or €30,600 a year; replace both numbers with your own audit count. No row prices the purchasing side: a cohort bought at a negotiated price instead of one failed laptop at a time is often worth more than everything above.
Twelve months on, the estate is older, the three lists are further apart, and the reconciliation project that would fix them has grown with every new clinic and every hire. Starters keep borrowing machines, which in a clinical setting means shared logins; audit findings recur.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A private healthcare provider, 3,000 staff across 14 clinics and a head office; about 3,400 devices in Microsoft Intune; purchasing through SAP purchase orders; an asset list in Microsoft Lists roughly a quarter out of date.
About 180 device events a month across new-hire orders, replacements, refresh and returns; about 36 devices a year never recovered or not locatable at audit; refresh due at four years, in practice at failure.
Start dates in the HR system, orders by email, purchase orders in SAP, enrolment in Intune, three trackers updated after the fact, returns chased by email once HR has mentioned the leaver.
Around 70 minutes of combined handling per event across IT, procurement and the requesting manager, spread over days, with no shared record and no trigger for refresh or return.
One register in Microsoft Lists, reconciled with Intune by a robot every night. Orders start from the HR start date or a Microsoft Forms request, are approved in UiPath Action Center from Teams and become SAP purchase requisitions raised by robots. A monthly job flags devices past the policy age or failing health checks and pre-fills the replacement order. Returns start on the leaver event with a courier label; the robot tracks, confirms receipt, triggers the Intune wipe and closes the record.
In the modelled case six in ten events run without manual coordination, starters have a device on day one, refresh becomes a cohort at a negotiated price, and returns are chased from the day of leaving. These are modelled figures on stated assumptions, not a client result.
Proposed solution
The register is the centre of the design, and it is deliberately the list you already have. A UiPath Robot reconciles it, Microsoft Lists at first or your CMDB later, with Microsoft Intune every night through Microsoft Graph, so model, age, last check-in, compliance state and assigned user are current every morning. Whatever Intune knows and the register does not, or the other way round, becomes an exception with an owner rather than a finding at audit.
Orders start from two triggers instead of a manager's memory: the HR start date, which opens an order the moment HR confirms it, and a catalogue request in Microsoft Forms, available as a tab in Teams. The manager approves in UiPath Action Center from a notification in Teams, cost centre attached; a robot raises the purchase requisition in SAP through the SAP BAPI connector, follows the goods receipt and records the device against the person before it is enrolled.
A monthly job flags devices past four years or failing Intune health checks, tells the user and the manager in Teams and pre-fills the replacement order, so procurement sees the cohort a month ahead and buys it at once. Returns start from the offboarding event: the leaver receives instructions and a courier label, the robot follows the tracking number, confirms receipt, triggers the Intune wipe and closes the record. Exceptions reach the IT asset manager as a task in Teams with the evidence attached.
Microsoft Intune inventory, compliance state and the Wipe action; Microsoft Lists as the register; Microsoft Forms requests written to the register by Power Automate; UiPath Action Center tasks completed in Microsoft Teams; UiPath Orchestrator time triggers, queues, credential store and audit; UiPath Integration Service connectors for Microsoft Teams and Microsoft OneDrive & SharePoint; Power BI
The register model and statuses, the nightly reconciliation and its exception rules, the order and approval flow, refresh detection and notices, the returns flow with label, tracking and wipe confirmation, the management report
Microsoft Graph reads of Intune managed devices and the wipe call; SAP purchase requisitions and goods receipts through the UiPath SAP BAPI connector; the HR feed for start and leave dates; the carrier's label and tracking interface
How the automated process works
- AutomationAn HR start date or a Microsoft Forms request opens an order in the register, and an Orchestrator trigger picks it up
- PersonThe manager approves in UiPath Action Center from Teams, cost centre attached; non-standard models go to IT for a second look
- SystemA robot raises the purchase requisition in SAP through the SAP BAPI connector, follows the goods receipt and records the device against the person
- AutomationEvery night a robot reads managed devices from Intune through Microsoft Graph and reconciles model, age, last check-in, compliance and user with the register
- AutomationA monthly refresh job flags devices past the policy age or failing health checks, notifies user and manager in Teams and pre-fills the replacement order
- AutomationAn offboarding event sends the leaver the return instructions and a courier label; the robot follows the tracking number
- SystemOn receipt, or after the last day where the policy says so, the robot triggers the Intune wipe, writes the status to the record and closes it
- PersonExceptions, an unreturned device, a rejected order, an Intune record with no register entry, reach the IT asset manager as an Action Center task in Teams
Human-in-the-loop model
Automation handles
- Nightly reconciliation of the register with Intune, and the exception list it produces
- Order intake against the catalogue; the requisition and goods receipt in SAP after approval
- Refresh detection by age and health, with notices in Teams and pre-filled orders
- Return instructions, courier label, tracking, the wipe trigger and closure of the record
People decide
- Managers approve orders and non-standard requests, cost centre attached
- The IT asset manager decides exceptions, write-offs and devices that never come back
- Procurement chooses models, vendors and the timing of each cohort
- IT owns the policy: refresh age, the catalogue and who may order what
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- HR start and leave dates
- Microsoft Forms requests
- Intune inventory through Microsoft Graph
- SAP goods receipts
- carrier tracking events
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Action Center
- UiPath Integration Service
- Power Automate
Target systems
- the register in Microsoft Lists (or the CMDB)
- SAP purchase requisitions and fixed assets
- Microsoft Intune wipe
- Power BI
Human touchpoints: Action Center approvals and exception tasks in Microsoft Teams; refresh notices in Teams; return instructions by email
Technologies used
live inventory, compliance state and the Wipe action
Areads managed devices (model, serial number, enrolment date, last sync, user) and issues the wipe
Athe register: one item per device with status, holder, cost centre and refresh date
Acatalogue requests from a form in Teams, written to the register
Areconciliation, SAP steps, refresh job, return tracking; triggers, credential store, audit
Amanager approvals; exception tasks for the asset manager
Arequisitions and goods receipts; Teams notices; register reads and writes
Aestate age, refresh cohorts, event status, recovery rate
AIllustrative economic model
Start by questioning the assumptions.
Six in ten of the 180 monthly events is the share the model hands to the flow without manual coordination, so the calculator starts from 108 events rather than 180; the other 72 keep a person in the loop and are priced at zero. Seventy minutes per event is the sum across IT, procurement and the requesting manager, and €46 a blended fully loaded hourly cost for those roles. Nothing here 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
- Starters have a device on day one, because the order starts from the HR start date rather than a manager's memory
- Refresh becomes a planned cohort at a negotiated price instead of an emergency purchase at failure
- Leavers' devices are chased from the day of leaving with a label already in hand, and the wipe is recorded
- The register agrees with Intune and the ledger every morning, which answers audit and insurance without a project
- Managers spend minutes approving instead of hours coordinating; the asset manager works a short exception list
The management view
- Every device event becomes a status in one flow: ordered, received, assigned, enrolled, due for refresh, returned, wiped, each with a timestamp and an owner
- The refresh plan turns into a forecast by month and model: a budget line for the CFO and a negotiating position for procurement
- Exceptions are a short named list, and the asset manager's workload follows starts, leavers and the refresh calendar
- HR receives confirmation that a leaver's device is back and wiped before the file closes
Board-level KPIs
Security and governance
Trust in automation is built on the audit trail, not on a promise.
- The robot reads Intune through Microsoft Graph with an application identity limited to device inventory and the wipe action, and raises requisitions in SAP under a service account restricted to the device catalogue and cost centres; secrets are drawn at run time from the Orchestrator credential store or your own Azure Key Vault
- A wipe runs only after the return is confirmed received or the leaver's last day has passed under a rule you set, and is recorded against the device and the person with the authoriser and the time
- Manager approvals carry the cost centre and are recorded in Action Center; every status change on the register is logged, which is the evidence for audit and insurance
- Personal data is limited to the assignment of a device to a person, retained under your Microsoft Purview policy; the register stays in your Microsoft 365 tenant and the robots run in the EU region of UiPath Automation Cloud
Why now
The trigger is usually financial: an audit finding on the asset register, an estate bought in one wave four years ago and now due all at once, or a procurement lead who wants to buy cohorts and cannot see demand
Intune holds enough about every device, model, age, compliance state and last check-in, to drive both refresh and reconciliation, and Microsoft Graph exposes it as a read rather than a project
Robots raise requisitions in SAP through the SAP BAPI connector and approvals are completed in Teams, which removes the last manual hand-offs; the coordination alone is modelled at €5,796 a month
Relevant executive roles
The device estate becomes a managed lifecycle with one record instead of three lists and a stockroom shelf
Starters get devices on day one, refresh is planned, and the asset manager stops reconciling spreadsheets
The asset register matches the ledger, refresh becomes a forecast, and unrecovered devices stop being a write-off line
Demand is visible by month and model, so devices are bought in cohorts at negotiated prices
Common questions and objections
Then it becomes the register and we write into it. What is usually missing is the flow around it, orders, refresh notices and returns, and the nightly reconciliation with Intune that keeps the tool true.
The catalogue and the approval with a cost centre are the control, and the report shows who orders what. Non-standard requests go to IT for a second look and appear by name in the monthly view.
Some will not. Chasing from day one with a label already in the leaver's hands recovers far more than an email a month later, and the wipe closes the data risk either way.
When this is not the right solution
- Fewer than a few hundred devices and one person who knows where each of them is; a good list and a quarterly check cost less
- Devices are leased and the lessor already runs orders, refresh and returns with a register you trust
- No Intune or equivalent management, so there is no live inventory to reconcile against, or an ERP or asset-management migration is under way; build after it
A question for the next management meeting
Name one leaver from last quarter whose laptop is "in transit" in one of our spreadsheets and "returned" in another: who is chasing it today, and has it been wiped?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A first reconciliation of your current lists against Intune and the ledger, which produces the exception list and usually the business case
- The register model, statuses and catalogue, agreed with IT, procurement and finance, with the refresh policy written down
- The order and approval flow: Action Center approvals in Teams, the SAP requisition and goods-receipt steps
- Refresh detection with notices in Teams and pre-filled cohort orders, in report-only mode first
- The returns flow: instructions, courier label, tracking, wipe trigger and record closure, with escalation for the unreturned
- The nightly reconciliation, the Power BI report and the asset manager's runbook
We need from you
- Read access to Intune for the robot and an SAP purchasing account limited to the device catalogue and cost centres
- The HR feed for start and leave dates, or the trigger you already use for joiners and leavers
- A refresh policy, a catalogue, an approval rule per cost centre and a named IT asset manager
Stages
Discovery
The first reconciliation: Intune against the asset list against the ledger, with volumes by event type
Design
Register model, catalogue, approval rule, refresh policy, return deadlines, exception rules
Build
Reconciliation, order and return flows, SAP and carrier integrations, Teams touchpoints, the report
Pilot
New-hire orders and returns for one region, every automated step reviewed by the asset manager; refresh in report-only mode
Scale
Further regions, the refresh notices switched on, the remaining device types; exception rules tightened from what the nightly run finds
Departmental. Effort follows the number of purchasing routes and device types, how far the current lists sit from Intune, and whether the carrier offers an interface for labels and tracking.
A leaver's laptop is "in transit" in one sheet and "returned" in another. Both are wrong.
Bring the three spreadsheets that describe your devices, procurement's tracker, IT's list and HR's sheet, to a two-hour workshop. We return the one register they should become and the first exception list: devices in Intune that are on no list, and list entries Intune has never seen.
Bring your three device spreadsheetsThe neighbouring process usually has the same problem
Hardware ordered by email, handed over without a record, and written off when the auditor asks.
View solution Other solutionsDay one ready: accounts, access and kit from one HR triggerNew hires wait days for roles and laptops because onboarding is five processes held together by email.
View solution Other solutionsEvery access and device of a leaver closed on the last dayA disabled account is not the same as closed access. The long tail is where audit findings come from.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsServices & ITShared services