A new floorhand is due at the yard on Monday. HR emailed the rig manager two weeks ago. The rig manager meant to reply with the crew and the equipment, then got busy. IT hears about the hire when the new person is standing at the shack door with no login, no timesheet app and no safety forms.
Most companies try to fix this with a form and a flow. HR fills something in, the department’s manager adds details and approves, and IT gets a completed request and creates the account. It sounds like a weekend build. It usually turns into three disconnected forms and an inbox full of “did this one get approved?”
A few design choices keep it from going that way.
One request, one SharePoint list item, one status
Treat each hire as a single record that moves through stages. That record is an item in a SharePoint list, with a request ID and a Status column. Every step reads and updates that same item.
A workable set of statuses:
- Submitted (HR has filled in the intake)
- With manager (waiting for the manager’s details)
- Awaiting approval
- Rejected (the request stops here)
- With IT
- Complete
This fixes the most common failure. If HR uses one Microsoft Form and the manager uses another, each submission creates a new record, and you end up joining them on an employee number someone typed by hand. With one list item, there’s nothing to merge.
The Status column also gives HR one view of every open hire and where it’s stuck.
Where HR types it: Microsoft Forms, a Lists form or Power Apps
You have three reasonable options for the intake.
| Option | How the data reaches the tracking list | Suits |
|---|---|---|
| Microsoft Forms | A flow copies each response into the list | HR needs only a handful of fields |
| Lists form | HR submits straight into the list, no copy step | Branching, lookups and attachments on the list itself |
| Power Apps form on the list | Opens and edits the same list item | A manager stage that needs its own screen |
Microsoft Forms is quick and familiar. You still need the copy step, though, and nothing in Forms knows about the list.
Since early 2025, Lists forms support conditional branching, lookup fields, attachments, submission notifications and start and end dates. For lookup fields, the person filling in the form needs read access to the source list.
With a Power Apps form, the manager opens the same item and sees only their section: crew, rig or site, supervisor, PPE sizes, which apps the hire needs. Anyone with access to the list can use a Power Apps-customised list form. Microsoft 365 E1 through E5 or F3 licences cover it using the SharePoint connector. F1 doesn’t (more on that in the field crew section below).
For most mid-sized companies the right answer is a Lists form or Forms for HR, plus a Power Apps form for the manager step. If you build the whole thing in Power Apps, keep the department-specific questions in data rather than hard-coding them into each screen. That’s the approach we took at Bonanza Drilling, where 20+ separate checklist forms became a single reusable checklist control whose questions live in Dataverse. Read the Bonanza checklist case study.
Route approvals by department from a config list
Most online guides ask HR to type the approver’s email address into the form. That breaks the first time someone misspells a name or a manager leaves.
Create a small config list instead, with one row per department or site:
- Department or operating area
- Manager (a person column)
- Backup approver
- IT queue or mailbox
- Reminder and escalation days
The flow looks up the department from the new request and pulls the manager from this list. When a rig manager changes, HR updates one row and no one edits the flow. If your Entra ID manager and department fields are reliable, you can pull the manager from there. In most field companies they aren’t, so the config list is safer.
Adding information and approving are two steps
The manager has two jobs: fill in the missing details, then approve. Build them as separate steps.
SharePoint’s built-in Approvals (Integrate, then Configure Approvals on the list) look tempting because there’s no flow to build. They don’t fit this process. They can’t route by department, and they cancel or reset an in-flight approval when the item or its metadata is edited, which is exactly what the manager is doing.
So the flow notifies the manager with a link to the item and sets Status to “With manager”. When the manager saves their section, a second flow checks the required fields are filled and sends the approval through the Power Automate Approvals connector. The approval arrives as an actionable email in Outlook, though guest users can’t act on it there. Check that your managers can respond from a phone, especially a superintendent on a remote site who mostly uses one.
Two details catch people out. The name of whoever created the flow appears on every approval, so build and own these flows under a service account rather than your own login. And put the key facts in the approval details (the connector supports Markdown there), so the approver can decide without opening the list.
Power Automate’s 30-day limit and the manager who never answers
A single Power Automate cloud flow run can last at most 30 days, and that includes time spent waiting on an approval. If a manager ignores a request, the run times out and nothing tells anyone.
Keep the state in the list instead of the flow run, and split the work across a few small flows:
- On create: look up the manager, set “With manager”, notify.
- On manager save: validate, set “Awaiting approval”, then send the approval with the “Create an approval” action. That action doesn’t wait, so the run ends straight away. Write the approval’s ID back to the list item.
- On response: a separate flow handles the manager’s answer. Approvals are stored in Dataverse, and this is Microsoft’s documented two-flow pattern for approvals that may outlast one run. The flow picks up the recorded response and matches it to the list item by the approval ID. If approved, set “With IT” and send IT the completed request. If rejected, set “Rejected” and send HR the manager’s comments.
- A daily scheduled flow: find items stuck in any status past the days set in the config list, and remind the owner. For items in “Awaiting approval” whose original approval has expired, create a new approval, sent to the manager or the backup approver, and store the new ID on the item.
Rule of thumb: each flow reads the status from the list item, does one job, updates the status and ends.
Test both outcomes with a dummy hire before go-live. A rejected request should never reach IT.
The IT step: ticket, flow or Entra Lifecycle Workflows
The simplest finish is an email or ticket to IT containing everything they need. For many companies that’s the right place to stop.
You can go further. The Microsoft Entra ID connector in Power Automate can create the user, assign the manager and add them to groups, and it’s a standard connector. The connection needs broad directory write permissions, though (User.ReadWrite.All and Directory.ReadWrite.All among them). Microsoft also documents that it doesn’t work as expected where Conditional Access or MFA applies. That makes it a security decision for IT to take, well beyond ticking a box in a flow.
If you have Microsoft Entra ID Governance or Entra Suite licences, Lifecycle Workflows is the Microsoft-native route. Its pre-hire template generates a Temporary Access Pass and emails it to the new hire’s manager a set number of days before the hire date, and you can scope it by department. It depends on employeeHireDate, department and manager being set correctly in Entra, and on the manager having a mailbox. Your onboarding list becomes the place that gets those fields right.
Field crew hires are different
Office onboarding guides assume every hire gets a laptop and a mailbox. Field crews often have neither, and the form should reflect that.
Capture the licence the hire needs. Microsoft 365 F1 doesn’t include Power Apps or Power Automate; F3 does. If the new floorhand will fill in field tickets, timesheets or FLHAs in a Power Apps app, F1 won’t do, and IT needs to know that before Monday.
Many crew members have no mailbox or share a device in the doghouse. Route anything they’d need to act on (a Temporary Access Pass, a welcome message, a first-day checklist) to their supervisor. Record the site, the crew and the tickets they hold, such as H2S Alive and First Aid, so site orientation can be planned.
Keep sensitive personal data out of the onboarding list, because managers across departments read it. SIN, banking and medical details belong in your payroll system or a separate list with tightly restricted access.
When a SharePoint list stops being enough
The list starts to strain when onboarding needs to share data with timesheets, equipment and safety records. That’s the point to move the data model to Dataverse. Bonanza Drilling’s field tickets, HSE checklists and payroll export run on Dataverse and Canvas Apps, and replaced 25+ paper forms.
We design and build approval workflows like this for field-heavy companies on SharePoint, Power Automate and Dataverse. See our Power Platform work.