Ask any IT manager at a mid-size organisation what their most time-consuming, error-prone process is — and most will say the same thing: employee onboarding and offboarding. Creating an Active Directory account, assigning the right groups, provisioning an M365 licence, configuring email rules, coordinating hardware — and then reversing all of that when someone leaves — is a chain of steps that falls apart the moment any one of them is missed.
This article documents a production-grade solution built for exactly this problem: a centralised, role-restricted SharePoint Online HR Self-Service Portal that automates the complete employee lifecycle using Power Automate, Azure Automation runbooks, and Microsoft Graph API — with zero manual IT intervention required for standard cases.
“No manual IT intervention required for standard onboarding or offboarding — Power Automate handles the full chain from form to AD to M365 to Exchange to audit log.”
The Problem: Why Manual HR Processes Are a Security and Operational Liability
The traditional HR-to-IT workflow looks something like this: HR emails IT to say someone is joining. IT creates the account manually. Someone remembers to add the security groups. Maybe. The licence gets assigned a day late. The hardware request goes to a personal inbox and gets missed. And when the employee leaves — if the offboarding ticket doesn’t arrive before their last day — their account stays active for weeks.
This isn’t just an operational inefficiency. It’s a security liability. Active accounts belonging to former employees, incorrect group memberships granting access to the wrong data, agent mailboxes receiving external emails they shouldn’t — these are the gaps that become incidents.
A single missed offboarding — where an account remains active after an employee departs — represents both a compliance risk and a potential data breach vector. In regulated industries (healthcare, finance, legal), this can carry direct regulatory consequences. Automation isn’t a luxury for these processes; it’s a governance requirement.
The solution described here eliminates manual IT intervention from all standard cases. HR submits a form. Power Automate handles every subsequent step — AD provisioning, group assignments, ADSync, M365 licensing, Exchange rules, hardware notification, and audit logging — with structured error handling and IT alerts at every failure point.
System Architecture: The Full Technology Stack
The portal is built on eight interconnected Microsoft technologies, each responsible for a distinct layer of the solution. Understanding how they fit together is essential before diving into individual workflow components.
Communication Site hosting all portal pages, 9 structured lists as the data layer, role-gated navigation, and embedded Power Apps forms for every function.
5 custom forms — Onboarding, Offboarding, Employee Change, Password Reset, Account Unlock — with real-time validations and conditional sections embedded directly in SharePoint pages.
7 flows orchestrating all workflows. Triggers Azure Automation runbooks, polls Graph API, handles branching logic, error handling, and all email notifications.
13 PowerShell runbooks executing all AD operations, ADSync, M365 licence management, Exchange transport rules — all with Key Vault credential management.
Transport rules applied automatically to Agent mailboxes: block inbound external, block outbound external, block external Reply-To headers.
Username uniqueness checking in real time, M365 account presence verification post-ADSync (max 5 retries), licence assignment via AssignM365Licence runbook.
Stores all service account credentials and certificates used by runbooks. App-only Exchange Online authentication certificate stored and retrieved securely at runtime.
Force delta sync triggered by Power Automate after AD account creation. Graph API polled to confirm M365 account presence before licence assignment proceeds.
SharePoint acts as the governance and visibility layer — every request, every outcome, and every audit event lives in a SharePoint list. Power Automate is the orchestration engine, not the execution engine — it calls Azure Automation runbooks for all privileged operations, keeping credentials out of flow variables entirely. Azure Key Vault ensures no service account password ever appears in plain text anywhere in the system.
The Full Tech Stack
Role-Based Access Control: Who Can Do What
Access to every portal function is governed by Active Directory Security Group membership — not SharePoint permissions alone. Power Automate validates group membership server-side before executing any action. SharePoint audience targeting hides pages from unauthorised users. Even if someone navigates directly to a page URL, the flow will reject the request if the submitter is not in the correct group.
This means RBAC is enforced at three independent layers: SharePoint page visibility, Power Apps form availability, and Power Automate execution validation. All three must pass for an action to proceed.
| Portal Function | HR | Floor Managers | Floor Supervisors | IT |
|---|---|---|---|---|
| Onboard New Employee | ✔ | — | — | Read only |
| Offboard Employee | ✔ | — | — | Read only |
| Employee Change | ✔ | — | — | Read only |
| Password Reset | ✔ | Own floor | — | Read only |
| Account Unlock | ✔ | Own floor | Agents only | Read only |
| Hardware Requests | ✔ | — | — | Read only |
| Audit Log | ✔ | — | — | ✔ Full |
Floor Supervisors can only unlock accounts for employees in the Agents Security Group — not any account in their floor. This scope restriction is enforced by Power Automate checking both the requester’s role AND whether the target account is in the Agents group before executing. This prevents supervisors from unlocking accounts outside their operational scope, even accidentally.
Onboarding Workflow: 9 Steps, Zero Manual IT Actions
The onboarding flow is the most complex workflow in the portal — it chains together AD provisioning, ADSync, Graph API polling, M365 licensing, Exchange transport rules, hardware notification, and audit logging in a single automated sequence. Here is every step.
Form Submission
HR completes the Power Apps form embedded in SharePoint across 5 sections: Personal Details, Role & Location, Account Identity, Group Assignments, and Hardware Requirements. The form is conditionally structured — Hardware section only appears if the role requires physical equipment.
Real-Time Validations
Username uniqueness is checked in real time against both AD (via AD_UserCatalogue list) and Microsoft Graph API. The email address is auto-generated as username@[domain].com (read-only — not editable). Password complexity is enforced. Hardware Required By Date must be on or after the Start Date.
AD Account Creation
Power Automate triggers the CreateADUser Azure Automation runbook. The account is provisioned in the Staff-New OU with all attributes populated from the form. ChangePasswordAtLogon is set to True — the employee must set their own password on first login.
Group & Distribution List Assignment
The AddGroupMember runbook adds the new account to all Security Groups and Distribution Lists selected in the form. This is driven by the SecurityGroup_Catalogue SharePoint list, which is the master reference for all available groups in the portal.
ADSync & M365 Replication
A force delta sync is triggered via Azure Automation. Power Automate then polls the Microsoft Graph API — with a maximum of 5 retries — to confirm the account is present and active in Microsoft 365 before proceeding to licence assignment. This prevents licence assignment failures caused by replication lag.
M365 Licence Assignment
The AssignM365Licence runbook assigns either Business Standard or Business Basic — whichever was selected in the form — via the Microsoft Graph API. Only after Graph API confirms account presence in step 5 does this step execute.
Agent Mailbox Rules (Conditional)
If the new account is a member of the Agents Security Group, the ApplyAgentMailboxRules runbook fires. It applies 3 Exchange Online transport rules restricting the mailbox to internal-only communications. The runbook uses app-only Exchange authentication via a certificate stored in Azure Key Vault. It is idempotent — safe to re-run without creating duplicate rules.
Hardware Notification (Conditional, Parallel)
If Hardware Required = Yes in the form, a parallel branch fires immediately — not sequentially — sending an email to ithelpdesk@[domain].com with subject ‘Hardware required for new employee: First Last’. The email lists all hardware items, delivery location, and start date. A corresponding record is created in the Hardware_Requests SharePoint list for IT tracking.
Completion Email & Audit Log
A completion email is sent to ithelpdesk@[domain].com with the outcome (Successful / Unsuccessful), full action detail, Power Automate Flow Run ID, and a direct link to the SharePoint record. An immutable entry is written to the Audit_Log list capturing every action taken, the submitter’s role, and the Flow Run ID for traceability.
The Audit_Log SharePoint list is configured with item-level permissions that prevent deletion and editing of existing records — even by HR. Only Power Automate (via its service account) can write new entries. This ensures the audit trail cannot be tampered with after the fact, which is a core requirement for SOC 2 compliance.
Agent Mailbox Transport Rules: Locking Down Internal-Only Mailboxes
For organisations running contact centre or customer service operations, Agent mailboxes require specific restrictions — they should only ever communicate with internal systems and colleagues, never with external domains. These three Exchange Online transport rules are applied automatically to every new Agent account during onboarding.
Rejects all inbound messages from any domain other than the organisation’s own. External senders receive an NDR immediately — the message never reaches the Agent’s inbox.
Blocks all outbound messages from the Agent to any recipient outside the organisation’s domain. Prevents data exfiltration or accidental external communication from Agent accounts.
Closes the circumvention gap for Rule 2 — an Agent could otherwise send to an internal recipient with a Reply-To header pointing externally, routing replies outside the organisation. This rule blocks any message from an Agent where the Reply-To header references an external domain.
If the ApplyAgentMailboxRules runbook cannot apply the rules (e.g. mailbox not yet fully provisioned), the overall onboarding flow is not failed. The account is still created and usable. Power Automate sets MailboxRulesApplied = No on the SharePoint record and sends an ‘ACTION REQUIRED’ alert email to IT immediately. The runbook is idempotent and can be re-run manually or via a retry flow once the mailbox is ready.
SharePoint List Architecture: 9 Lists, One Source of Truth
All portal data lives in SharePoint lists — not in Power Automate variables, not in Excel files, not in email threads. Every request, every outcome, every audit entry, and every hardware work item has a defined list with structured columns, validation rules, and item-level permissions. This makes every action reportable, searchable, and auditable.
| List Name | Purpose | Key Fields / Notes |
|---|---|---|
AD_UserCatalogue |
AD user sync cache | Powers real-time username duplicate checking; source for People Picker fields; updated by scheduled ADSync flow |
Onboarding_Requests |
All new employee requests | Includes hardware fields, MailboxRulesApplied flag, licence type, group assignments |
Offboarding_Requests |
Departing employee requests | Group membership snapshot captured at submission, hardware collection fields, last working day |
EmployeeChange_Requests |
Change management requests | Title, department, group add/remove, manager update, licence change — all in one list |
PasswordReset_Requests |
Password reset requests | Encrypted password field — cleared post-execution for security; requester role captured |
AccountUnlock_Requests |
Account unlock requests | RequesterRole captured for RBAC audit; Supervisor scope validated before execution |
Hardware_Requests |
IT hardware work queue | Covers both provisioning (from Onboarding) and collection (from Offboarding); daily overdue reminder flow checks RequiredByDate |
SecurityGroup_Catalogue |
Master group reference | All AD Security Groups and Distribution Lists available for self-service; drives the Group Assignment picklist in forms |
Audit_Log |
Immutable transaction log | Every portal action, outcome, submitter role, Flow Run ID — write-once permissions; no deletions permitted |
Automated Email Notifications: Every Outcome, Every Edge Case
The portal sends structured email notifications to IT for every workflow outcome — success, failure, and edge cases. No request falls silently into a queue. Every email includes the Flow Run ID, which allows IT to trace any notification directly back to the specific Power Automate run and the exact SharePoint record that triggered it.
| Trigger | Recipient | Subject Pattern | Key Content |
|---|---|---|---|
| All workflow completions | IT Help Desk | HR Self-Service Portal | [Type] | [Username] | [Action] — Successful / Unsuccessful | Full action detail, Flow Run ID, SharePoint record link |
| Hardware provisioning (Onboarding) | IT Help Desk | Hardware required for new employee: First Last | Item list with specs, delivery location, required-by date, start date |
| Hardware collection (Offboarding) | IT Help Desk | Hardware collection required for departing employee: First Last | Item list with serials/IMEI, collection location, last working day |
| Agent mailbox rules failure | IT Help Desk | ACTION REQUIRED: Agent mailbox rules failed for First Last (UPN) | Manual intervention required — account still provisioned and usable |
| Hardware overdue reminder (Daily) | IT Help Desk | HR Self-Service Portal — Outstanding Hardware Requests | List of all items where RequiredByDate ≤ today and Status ≠ Completed |
Every email notification includes the Power Automate Flow Run ID. This single reference links the email notification → the Power Automate run history → the SharePoint list item → the Azure Automation job → the Audit_Log entry. When something goes wrong, IT can trace the exact sequence of events in under 60 seconds without trawling through logs manually.
Offboarding: Full Reversal, Automated and Audited
Offboarding is the mirror of onboarding — and in many organisations it’s handled far less rigorously. The portal treats offboarding with the same structured automation as onboarding, ensuring nothing is missed and everything is recorded.
-
✓AD account disabled immediately — the account is disabled (not deleted) in AD upon flow completion, preventing login while preserving the account for any post-departure data access requirements.
-
✓All group memberships removed — every Security Group and Distribution List membership is removed. A snapshot of the groups at time of offboarding is stored in the
Offboarding_Requestslist record for reference. -
✓M365 licence revoked — the licence is revoked immediately upon flow completion, freeing the seat for reassignment and stopping further M365 service access.
-
✓Optional email delegation — if selected, mailbox access can be delegated to the departing employee’s manager or a nominated account for a defined period before the mailbox is eventually deleted.
-
✓Hardware collection notification — an email fires automatically to IT with all hardware item serials/IMEI numbers, collection location, and the employee’s last working day. A record is created in the
Hardware_Requestswork queue. -
✓Full audit log entry — every offboarding action is recorded in the immutable
Audit_Logwith timestamp, submitter, outcome, and Flow Run ID.
Delivery Timeline: 6 Phases, 13 Weeks to Production
This is not a bolt-together solution. A full, tested, documented production deployment requires approximately 13 weeks across six structured phases. Each phase has defined deliverables — no phase completion is declared without its outputs being validated.
SharePoint Communication Site build, all 9 list schemas deployed with validation rules and item-level permissions, role-gated page structure, audience-targeted navigation configured for all 4 role groups.
Power Apps forms for Onboarding and Offboarding — the two most complex forms with all conditional sections, real-time username validation against AD and Graph API, hardware sub-forms, and group assignment picklists driven by SecurityGroup_Catalogue.
All 13 Azure Automation runbooks built and tested. Onboarding and Offboarding Power Automate flows. ADSync flow. M365 licence management. Exchange transport rule application. Key Vault credential integration across all runbooks.
Employee Change, Password Reset, and Account Unlock forms and flows. RBAC scope validation for Floor Managers (own floor) and Supervisors (Agents only). Password encryption in PasswordReset_Requests and post-execution field clearing.
Structured UAT with IT, HR, and Floor Supervisor participants. Edge case testing: username conflicts, ADSync failures, licence unavailability, mailbox rule failures. Security validation: direct URL access attempts by non-permitted roles. All findings addressed before Phase 6.
User training for HR, Floor Managers, and Floor Supervisors. Full technical documentation handover covering UI wireframes, workflow diagrams, SharePoint schema, runbook specifications, and email templates. Hypercare period with rapid-response support post-launch.
Production-Grade Security: Built In, Not Bolted On
Every architectural decision in this portal has a security rationale. These are not afterthoughts — they are first-class design constraints built into the solution from the start.
All service account passwords and certificates are stored in Azure Key Vault. Runbooks retrieve credentials at runtime via managed identity. No password ever appears in a flow variable, runbook parameter, or SharePoint column.
Item-level permissions on the Audit_Log list prevent modification or deletion of existing records. Only the Power Automate service account can write new entries. Fully aligned with SOC 2 audit trail requirements.
Role enforcement at SharePoint page level (audience targeting), Power Apps form level (conditional availability), and Power Automate execution level (server-side group membership check). All three must pass. Direct URL access by unauthorised users is blocked at the flow layer regardless of SharePoint permissions.
The password field in PasswordReset_Requests is encrypted at column level. The field is programmatically cleared immediately after the reset runbook executes successfully. The password is never retained in the list in plaintext at any point after the operation completes.
Each Azure Automation runbook runs under a dedicated service account with the minimum permissions required for its specific function. No single service account has broad administrative rights across the entire system.
The combination of immutable audit logging, RBAC enforcement, credential management via Key Vault, and MFA enforcement across all portal access points directly addresses SOC 2 Trust Service Criteria for availability, confidentiality, and security.