Starting point
The company, a service provider with around 180 employees at two sites, had Microsoft 365 for everyone and nothing else for HR. An HR system had been evaluated twice and postponed twice because the budget was needed elsewhere. The HR team was two people. A leave request was an email to the manager with HR in copy, the team calendar was maintained by hand. For onboarding, HR opened the Excel list from the last new hire, copied the sheet and sent separate emails to IT, the department and reception. Probation periods, fixed-term contracts and promised reference letters sat in a spreadsheet one colleague reviewed on Mondays, when she was in.
The moment it tipped was a fixed-term contract. An employee's contract ended on a Friday, nobody had noticed, and she came to work on Monday as always. With that the employment became permanent, not because anyone had decided it, but because nobody had looked. The colleague with the spreadsheet had been off sick that week. In the same month a leave request sat for two weeks in the inbox of a manager who was also off sick, and the employee booked his trip without approval. The head of HR called me after she had explained both to the managing director.
At the first meeting the head of HR, the Microsoft 365 admin and the works council chair sat at the table. The admin said Power Automate had long been enabled in the tenant, nobody from HR had ever asked for it. The works council chair said a flow that records who approved what and when is a technical system, and he wanted to see every single one before it runs. I agreed to both: no new licence, no data outside the tenant, and no flow without his signature on the sketch.
Approach
Week one belonged to the stopwatch, as always. For one week both people in the HR team noted which task came how often, how long it took and which person it depended on. In parallel I settled with the admin which licence the HR accounts hold, where flows and lists may live and who may create them. At the end of the week three processes were at the top: the leave request, because it generated the most emails, onboarding, because it hung on an Excel list, and the deadlines, because they hung on one person. All three consisted of forwarding, reminding and entering.
In week two the first flow began, not on screen but on paper. The works council chair sat at the table, and we wrote the leave request down as a sketch: what triggers it, which fields it reads, who receives which message, where a human decides. Only when HR, the admin and the works council had signed off the sketch was it rebuilt in Power Automate, in the company's tenant, with an owner in the HR team. The employee fills in a form in Microsoft Forms, the flow looks up the manager in the directory, the manager approves or rejects with one click in Teams or Outlook. On approval an all-day entry appears in the team calendar, first name and dates only, no reason and no remark. Both receive the outcome, HR sees everything in one SharePoint list.
The snag came in the test with the first team. One request landed with a colleague who had not been a manager for a year. The flow had done nothing wrong; it read the manager field from Microsoft 365, and that field had not been maintained since the last reorganisation. Roughly every fifth account still showed the old manager. The admin and the head of HR updated the field for all accounts in two days, and since then it is part of every joiner and every team change. The lesson mattered more to the team than the flow itself: an automation is only as reliable as the directory it reads from.
Onboarding and deadlines followed the same pattern, sketch first, then flow. For onboarding, HR adds the new hire as an entry in the SharePoint list with first name, role, department, start date and manager, no contract data. The flow creates the house task list in Planner from it, with owners and due dates counted from the start date, and sends a summary of open tasks to HR and the manager seven days before day one. For the deadlines, the spreadsheet now lives as a SharePoint list with type, date, owner and status. Every Monday at eight the flow checks what falls due in the next six weeks and sends the overview to the HR mailbox. The team agreed two rules: every new contract gets an entry when it is created, and finished items are set to done, not deleted. None of the three processes needed AI Builder or premium connectors, and so it stayed that way.
The works agreement ran in parallel. Because every flow records who requested and approved what and when, it was clear that it is subject to co-determination. The text grew out of the signed-off sketches: which three flows run, which fields they read, who may see the lists and the run history, when they are deleted, and that every new flow is shown to the works council first. We defined the access rights on the SharePoint lists with the data protection officer: only HR writes, managers see only their own team in the calendar, the admin manages the environment and has no access to the contents of the lists. After three months the agreement was signed, the three flows ran in production, and the HR team maintained them with the admin without me.
Outcome
A leave request today is a form, one click by the manager and an entry in the team calendar that nobody makes by hand any more. If someone is off sick, no request sits in an inbox, because the request no longer starts in an inbox. Onboarding begins with an entry in the list, and IT knows on the day of signature when someone starts. On Mondays at eight the deadline list arrives, whether the colleague is in or not.
No new licence, no data outside the tenant; that was the condition, and it held. The works agreement names the three flows, the fields read, the access rights, the deletion periods and the procedure for new flows. At the six-month review the team presented a fourth process, the leaver with the return of devices and access rights, built with the admin on its own, sketch first, works council first. That it needed nobody from outside for that was the goal.