Automating Employee Offboarding Across Microsoft 365

The Business Situation

Cedarvale Business Systems is a fictional 75-person B2B software and implementation services firm. Its workforce includes permanent employees and a small number of fixed-term workers who receive Microsoft 365 accounts, company devices, customer system access, and expense privileges.

The company processes an average of three offboarding cases per month. These include resignations, retirements, end-of-contract departures, and employer-initiated departures. The volume is not high enough to justify an immediate move to a large dedicated identity governance platform, but it is high enough that inconsistent coordination creates operational and compliance risk.

People Operations owns the offboarding process. The participants normally include:

• A People Operations manager who opens and closes the case.
• The departing worker’s manager, who owns customer and project handover.
• An IT administrator who inventories access, removes access, and preserves approved business records.
• A payroll specialist who confirms final payroll processing.
• A finance manager who reviews cards, expenses, advances, and recoverable assets.
• A legal and compliance lead who provides preservation instructions when a legal hold or sensitive departure requires review.

The existing environment already includes Microsoft Forms, Microsoft Lists, SharePoint, Power Automate, and Microsoft Teams. Payroll, endpoint management, and identity administration are separate systems, but the first implementation does not directly change those systems. Instead, it assigns controlled tasks, captures completion evidence, and records who confirmed each action.

This boundary is deliberate. A submitted form does not approve a termination, disable an account, release final pay, or decide whether records may be deleted. Those decisions remain with authorized people using the relevant systems.

Note: This case study is provided as a representative example of the types of AI integration and digital transformation solutions Intelligex designs and delivers. Actual engagements are tailored to each client’s goals, constraints, existing systems, timeline, and available resources, so the approach, tools, and outcomes may vary.

The Existing Process

Before the implementation, Cedarvale coordinated offboarding through email, individual calendars, a shared spreadsheet, and department-specific checklists. The process generally followed this sequence:

1. People Operations received notice that a departure had been authorized through the company’s existing HR process.
2. A coordinator copied employee details into an offboarding spreadsheet.
3. The coordinator emailed IT, payroll, finance, the manager, and sometimes legal.
4. Each department replied in a separate email thread or updated its own notes.
5. The manager prepared project and customer handover information in an independently stored document.
6. IT removed access at the scheduled time and sent a brief confirmation by email.
7. People Operations followed up on equipment, expenses, payroll, and missing confirmations.
8. The coordinator manually reconciled the email threads and marked the spreadsheet row complete.

The greatest concern was not the lack of a more sophisticated interface. It was the absence of a common record, explicit ownership, evidence requirements, and a reliable escalation path.

What the New System Needed to Do

The project team documented the requirements before choosing the implementation pattern.

Implementation Approaches Considered

Improved spreadsheet and email process

This option had the lowest initial configuration effort, but it did not solve duplicate entry, weak status history, inconsistent evidence, or dependency on a coordinator. It was retained only as the temporary fallback process during deployment.

Microsoft 365 workflow

The selected approach reused tools already familiar to employees. Microsoft Lists provided structured records, SharePoint held controlled evidence, Power Automate handled workflow, Forms provided restricted intake, and Teams delivered operational notices.

No-code database and external automation platform

This approach could have provided a polished interface and flexible relationships. It was not selected because the company would have needed an additional security review, vendor agreement, permission model, and integration layer for information already held in Microsoft 365.

Dedicated offboarding software

A dedicated platform would become more attractive if Cedarvale required direct identity governance, automated device commands, formal certification campaigns, complex multi-country rules, or substantially higher volume. At the current scale, the company first needed a reliable coordination and evidence process.

Custom application

A custom application offered the greatest flexibility but the highest ownership burden. It was unnecessary for a workflow with modest volume, internal users, and requirements supported by native Microsoft 365 connectors.

The Selected Solution

Cedarvale selected a Microsoft 365 implementation that retained its existing productivity environment. The core solution connects two Microsoft Forms, four Microsoft Lists, a SharePoint document library, Power Automate cloud flows, the Microsoft Approvals connector, and Microsoft Teams.

The workflow coordinates work but does not directly disable Microsoft 365 accounts, issue endpoint management commands, post payroll entries, or make legal retention decisions. These actions remain in the systems controlled by IT, payroll, finance, and legal. Task owners record evidence after completing them.

The new implementation removes repeated case entry, manually constructed email checklists, manual folder creation, informal reminder tracking, and spreadsheet reconciliation. It preserves human control over termination authorization, access execution, payment release, record preservation, exceptions, and final closure.

System Architecture and Data Flow

• Intake: An organization-restricted Microsoft Form captures the authorized offboarding schedule and conditional requirements.
• System of record: Microsoft Lists stores cases, tasks, task templates, status history, configuration, and errors.
• Automation layer: Power Automate validates input, creates records, routes approvals, monitors deadlines, and updates rollups.
• Document storage: A private SharePoint library stores evidence in case and workstream folders.
• Notifications: Microsoft Teams sends restricted operational notices and escalation messages.
• Reporting: Filtered Microsoft Lists views and a restricted SharePoint operations page show workload and exceptions.
• AI layer: An optional approved AI endpoint summarizes sanitized open-task data for human review.

1. Submission: A People Operations user submits the organization-restricted Offboarding Intake form. The form provides employee identifiers, manager, last working date, access-removal time, asset indicators, customer handover requirements, and review flags. The Power Automate trigger receives the Forms response ID. If response details cannot be retrieved, the flow writes an error record and alerts the process owner.

2. Validation: Power Automate retrieves the complete response and validates required values, the submitter’s identity, email domains, date order, approved time-zone values, and allowed choices. Invalid submissions are placed in Needs Information rather than being allowed to continue.

3. Duplicate check: The flow checks both the Forms response ID and a case key consisting of normalized employee UPN plus last working date. A duplicate trigger exits safely. A possible duplicate business case is routed to People Operations for review.

4. Case creation: Power Automate creates a Microsoft Lists case item, receives the numeric list item ID, and formats the case identifier as OB-year-six-digit number. It then updates the case with the generated identifier and automation correlation ID.

5. Folder creation: SharePoint creates a folder named only with the case ID. Subfolders are created for HR, IT, manager handover, payroll, finance, legal, and device evidence. The case receives the folder URL and SharePoint item identifier. A fixed-name case manifest is created only if one does not already exist.

6. Task generation: Power Automate reads active Task Templates. It creates every applicable task using explicit condition codes such as ALWAYS, HAS_DEVICE, HAS_CUSTOMER_HANDOVER, HAS_PRIVILEGED_ACCESS, HAS_FINANCE_ASSET, and LEGAL_REVIEW. Each created task returns a Microsoft Lists item ID, which is stored with a unique task key.

7. Conditional review: The case is marked for the required manager, finance, IT-risk, and legal reviews. Approval identifiers, outcomes, responders, comments, and response dates are written back to the case. Rejected or timed-out reviews move the case to a visible exception state.

8. Task execution: Owners receive private Teams notifications containing a case ID, task ID, due date, and authorized link. They perform the actual work in the appropriate business system, upload required evidence to SharePoint, and submit the Task Completion form.

9. Task validation and rollup: Power Automate verifies that the task exists, the responder is authorized, the case ID matches, and required evidence is present. It updates the task and recalculates open, blocked, and overdue task counts on the case.

10. Reminders and escalation: A scheduled flow identifies tasks approaching their due date or already overdue. Notifications go first to the owner, then to the workstream lead, and finally to People Operations for unresolved high-risk items.

11. Closure: When all required approvals and tasks are complete, the case moves to Ready for HR Closure. People Operations reviews the evidence and provides final closure confirmation. The system writes a closure summary, records the status change, and marks the case Closed.

12. Failure path: A failed action updates Automation Status when a case exists. If no case was created, the response ID and error details are written to the Automation Errors list. A controlled retry flow reprocesses eligible records without creating duplicates.

Data Structure

The implementation uses related Microsoft Lists rather than one large checklist. The numeric SharePoint item ID is retained as the stable internal key. Human-facing IDs are generated after record creation.

Offboarding Cases list

Offboarding Tasks list

Supporting lists

Task Templates

Stores Task Code, Task Title, Workstream, Condition Code, Due Anchor, Offset Days, Evidence Required, Assignment Rule, Criticality, Active, and Sort Order.

Status History

Stores Case ID, Case Item ID, Event Type, Previous Status, New Status, Actor, Event Time, Details, Flow Run ID, and Correlation ID.

Automation Errors

Acts as a manual-review and dead-letter queue. It stores source response ID, case ID when known, flow name, failed scope, error summary, payload reference, retry count, owner, resolution status, and timestamps.

Automation Configuration

Stores non-secret settings such as queue addresses, private Team and channel references, reminder intervals, approved time zones, SharePoint host, and maximum retries. Secrets are not stored in Lists.

One case has many tasks and many history events. Task Templates are configuration records rather than case data. Automation Errors can reference either a Forms response or an existing case, allowing failures before and after case creation to be recovered.

Workflow Statuses and Ownership

A record may move backward when an approval is rejected, required evidence is missing, a completion submission is unauthorized, or People Operations returns a case for correction. A case cannot close solely because the open-task count reaches zero. Final human closure confirmation is required.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

Cedarvale first confirmed that its Microsoft 365 subscriptions and Power Platform policies supported Microsoft Forms, SharePoint, Lists, Teams, standard connector use, and Approvals. Licensing terms change, so the implementation team verified current entitlements rather than assuming that every feature was included.

1. Create separate test and production SharePoint sites. Use a private site for production, such as People Operations Automation.
2. Create a private Teams team or private operations channel for HR, IT, payroll, finance, and legal process owners.
3. Designate an automation owner account and at least one co-owner. Use YOUR_AUTOMATION_OWNER_EMAIL and YOUR_BACKUP_OWNER_EMAIL when configuring connections.
4. Confirm how the organization licenses and governs shared or service identities. Do not create an unlicensed account solely to avoid assigning accountable flow ownership.
5. Create connection references for Microsoft Forms, SharePoint, Teams, and Approvals using the approved automation identity.
6. Restrict the intake and task-completion Forms to authenticated people in the organization.
7. Create test users representing People Operations, a manager, IT, payroll, finance, legal, an unauthorized employee, and a delegated approver.
8. Apply the organization’s data loss prevention policies so offboarding data cannot be sent to unapproved consumer connectors.
9. Confirm that SharePoint audit and version-history settings meet the organization’s legal and privacy requirements.
10. Document who can edit flows, who can view run history, and who may retry failed records.

The production flows were not built using one employee’s personal connections without a backup owner. Connection ownership, credential rotation, and departure procedures for the automation owner were included in the operating documentation.

Step 2: Build the Intake

Create an organization-restricted Microsoft Form named Offboarding Intake. Make the form available only to the People Operations group. Record the responder’s identity and do not accept anonymous responses.

Use Forms branching to show a short reminder when privileged access, legal review, a device, or finance assets are selected. The reminder explains which supporting information will be requested later. Do not use form branching as the only validation mechanism because submitted values must still be validated in Power Automate.

The confirmation message should state that the request was received, that submission does not itself disable access or approve termination, and that People Operations will receive the generated case ID through the controlled workflow.

Create a second organization-restricted form named Offboarding Task Completion with these fields:

• Case ID.
• Task ID.
• Completion status: Completed, In Progress, Blocked, or Needs Clarification.
• Evidence URL.
• Completion notes.
• Delegation reference, if applicable.

The task update flow captures the authenticated responder. A submission is rejected if the responder does not match the task owner, approved delegate, or People Operations administrator.

Attachments are not accepted through the intake form. Task owners first upload evidence to the appropriate SharePoint folder and then submit the evidence URL. This avoids copying sensitive files through multiple storage locations.

Step 3: Create the System of Record

On the production SharePoint site, create these Lists:

• Offboarding Cases.
• Offboarding Tasks.
• Task Templates.
• Status History.
• Automation Errors.
• Automation Configuration.

Configure the fields defined in the Data Structure section. Enable version history on Cases, Tasks, Task Templates, Configuration, and the evidence library.

Enforce unique values on Case ID, Form Response ID, Task ID, and Task Key. Index Case ID, Case Key, Case Status, Access Removal At UTC, Task Status, Task Due Date, and Automation Error status. These indexes become more important as retained case history grows.

Populate Task Templates with controlled definitions. A representative set is shown below.

The offsets use calendar days for reproducibility. If the business requires business-day calculations, implement a maintained holiday-calendar list rather than assuming weekdays are always working days.

Create filtered views including New Cases, Upcoming Access Removal, Awaiting Review, Blocked Cases, Ready for Closure, Open Tasks by Owner, Overdue Tasks, Missing Evidence, Automation Failures, and Recently Closed.

Do not give all task owners direct access to browse the Cases list. Managers complete tasks through the controlled form and receive access only to their case-specific SharePoint subfolder. Standing operational teams receive only the access required for their workstream.

Step 4: Connect the Tools

Microsoft Lists data is accessed through the SharePoint connector because Lists are stored on the SharePoint site. Each Power Automate connection uses the approved automation identity and is documented in the connection inventory.

Forms to Power Automate

Use the Microsoft Forms trigger When a new response is submitted, followed immediately by Get response details. Select the production form explicitly. The returned response ID is the first idempotency key.

Power Automate to Microsoft Lists

Use SharePoint Create item, Get items, Get item, and Update item actions. Returned list item IDs are stored before later actions run. If a later action fails, the case can therefore be updated with an Automation Error status.

Power Automate to SharePoint

Use Create new folder for the case and workstream folders. Use Create file for the case manifest and closure summary. Use Grant access to an item or a folder only for specific internal users who require case-folder access.

Power Automate to Teams

Use a Teams action that posts a message in a private chat or restricted channel. Interface labels may vary by connector version. The important configuration is the sender connection, destination Team or recipient, case ID, task ID, due date, and restricted record link.

Power Automate to Approvals

Use Create an approval followed by Wait for an approval. Store the approval identifier before waiting. This allows timeout, cancellation, escalation, and reconciliation logic to reference the original approval.

Returned identifiers and source updates

Every connection must write its returned identifier back to the source case or task. Examples include the case list item ID, task list item ID, SharePoint folder URL, SharePoint file identifier, Forms response ID, approval ID, and Power Automate run ID.

Use exponential retry for transient SharePoint, Teams, and Approvals failures. Do not retry validation failures or rejected approvals automatically.

Step 5: Build the Core Automation

Flow OB-01: Intake and Case Creation

• Trigger: A new response is submitted to the Offboarding Intake form.
• Conditions: The respondent is authorized, required fields are present, choices are allowed, dates are valid, and the response ID has not already been processed.
• Actions: Retrieve details, normalize values, check duplicates, create the case, generate the case ID, create folders and a manifest, read task templates, create applicable tasks, initialize approval statuses, post a private Teams notice, and update Automation Status.
• Fields updated: Case ID, Case Key, status fields, folder link, task counts, flow run ID, last automation time, and external identifiers.
• Notification: People Operations receives a restricted case-created message. Task owners receive notices only after validation.
• Exception: Validation problems create a Needs Information record. Technical failures create or update an Automation Errors item.

The exact action order is:

1. Initialize variables for the response ID, correlation ID, normalized employee UPN, dates, Boolean flags, and current run ID.
2. Retrieve response details.
3. Validate the submitter against the approved People Operations group or configuration list.
4. Validate mandatory fields and allowed values.
5. Query Cases for the Forms response ID. If found, terminate successfully as an already-processed event.
6. Calculate the Case Key and query open cases using the same key.
7. If an open matching case exists, create an Automation Error or manual-review record and stop before creating a second case.
8. Create the case with a temporary title such as PENDING plus the response ID.
9. Capture the returned list item ID.
10. Generate the Case ID and update the case immediately.
11. Create the year folder if it is not already present.
12. Create the case folder only if Document Link is blank.
13. Create each required workstream subfolder.
14. Create the case manifest only if the fixed-name file is absent.
15. Read active Task Templates in Sort Order.
16. Use an explicit switch on Condition Code to determine whether each task applies.
17. Create the task using a unique Task Key. If it already exists, retrieve and reuse it.
18. Calculate initial open-task counts.
19. Set each approval status to Pending or Not Required.
20. Set Case Status to Awaiting Conditional Review when at least one review is required; otherwise set it to Scheduled.
21. Set Approval Automation State to Queued when approvals are required.
22. Post a restricted Teams notification.
23. Set Automation Status to Succeeded and record the run time.

Flow OB-02: Conditional Review Orchestration

• Trigger: A case is created or modified with Approval Automation State equal to Queued.
• Conditions: The case is not Cancelled or Closed, and no approval-orchestration run is already processing it.
• Actions: Mark the case Processing, create required approvals in parallel branches, store IDs, wait for responses, evaluate all gates, update statuses, and append history.
• Fields updated: Individual approval statuses, approval IDs, responder details, response dates, approval comments, case status, and approval automation state.
• Notification: Approvers receive approval requests and a restricted Teams notice. People Operations receives rejection or timeout alerts.
• Exception: A timed-out branch marks the relevant review Timed Out, attempts to cancel the pending approval where supported, and moves the case to Blocked or Manual Review.

Set trigger concurrency to one for this flow. As its first action, update Approval Automation State from Queued to Processing. This prevents repeated modifications from starting overlapping approval runs.

Manager, finance, IT-risk, and legal reviews can run in parallel because one does not depend on another. Final People Operations closure is sequential and happens only after all required tasks and reviews are complete.

Flow OB-03: Task Completion Processing

• Trigger: A response is submitted to the Offboarding Task Completion form.
• Conditions: Case ID and Task ID match, the task is open, the responder is the owner, delegate, or People Operations administrator, and required evidence is valid.
• Actions: Retrieve the task, validate the SharePoint URL, update status, store completion evidence, append history, and invoke rollup logic.
• Fields updated: Task Status, Evidence Link, Completion Notes, Completed By, Completed At, Last Automation Run, and task error fields.
• Notification: The owner receives confirmation. Blocked tasks notify the workstream lead and People Operations.
• Exception: Unauthorized, mismatched, or incomplete submissions are logged and do not alter the task.

For tasks requiring evidence, completion is rejected unless the URL begins with the approved SharePoint host and includes the matching Case ID path. URL validation does not prove the evidence is adequate. The final People Operations closure review confirms adequacy.

Flow OB-04: Task and Case Rollup

• Trigger: An Offboarding Tasks item is created or modified.
• Conditions: The parent Case Item ID exists.
• Actions: Retrieve all tasks for the case, count open, blocked, overdue, and completed tasks, evaluate mandatory evidence, and update the case.
• Fields updated: Open Task Count, Blocked Task Count, Overdue Task Count, last automation time, and Case Status.
• Notification: People Operations is notified when a case first becomes Ready for HR Closure.
• Exception: If rollup fails, the task remains updated but the case is marked for reconciliation.

The flow does not close a case. If every required task is Completed or an authorized People Operations user has marked it Not Applicable with a reason, and all approval gates are satisfied, the flow moves the case to Ready for HR Closure.

Flow OB-05: Reminders and Escalations

• Trigger: Scheduled recurrence, every weekday at 08:00 and every hour on known departure days.
• Conditions: Task is open, due date is within the configured reminder window or overdue, and the minimum notification interval has elapsed.
• Actions: Send owner reminder, increment Reminder Count, update escalation level, notify the lead, and flag critical cases.
• Fields updated: Last Reminder At, Reminder Count, Escalation Level, Overdue Task Count, and possibly Case Status.
• Notification: Private Teams chat for owners; restricted channel escalation for workstream leads and People Operations.
• Exception: Failed notifications are logged, but critical task status remains visible in Lists.

Access removal is treated differently from routine tasks. If the recorded access-removal deadline passes without completion evidence, the system immediately escalates to the IT lead and People Operations. It does not attempt to disable the account itself.

Flow OB-06: Status History

• Trigger: A case is created or modified.
• Conditions: Case Status differs from Last Recorded Status.
• Actions: Create a Status History item, then set Last Recorded Status to the current Case Status.
• Fields updated: Last Recorded Status and Last Automation Run.
• Notification: None for routine transitions.
• Exception: A failed history write creates an Automation Error and leaves the two status values different so reconciliation can detect it.

Set trigger concurrency to one. The update to Last Recorded Status triggers the flow again, but the second run exits because the statuses now match. SharePoint version history provides a secondary record of item changes.

Flow OB-07: Final Closure

• Trigger: A case enters Ready for HR Closure.
• Conditions: All mandatory tasks are complete or formally excepted, all approvals are satisfied, the access task has evidence, and the case is not on hold.
• Actions: Request final People Operations approval, store the response, create a closure summary, set Closed Date, update Case Status, and create a history item.
• Fields updated: Final Approval ID, Final Approval Status, Closed Date, Document Link, Case Status, and Automation Status.
• Notification: Workstream leads receive a restricted closure confirmation.
• Exception: Rejection returns the case to In Progress with comments. Timeout keeps the case Ready for HR Closure and escalates it.

Flow OB-08: Controlled Retry

• Trigger: An authorized user runs a selected-item recovery flow from Automation Errors or Offboarding Cases.
• Conditions: Retry Count is below the configured maximum, the case is not Closed or Cancelled, and the error is eligible for retry.
• Actions: Increment Retry Count, mark Retry Scheduled, replay the failed stage using existing identifiers, and update the error record.
• Fields updated: Retry Count, Automation Status, Last Automation Run, Resolution Status, and Error Message.
• Notification: The automation owner receives retry outcome details.
• Exception: An exhausted retry limit moves the item to Manual Review.

The retry flow never creates tasks or files blindly. It first checks unique keys and stored identifiers, making the operations idempotent.

Step 6: Add Approvals, Reminders, and Escalations

The approvals do not authorize termination, provide legal advice, disable access, or release payments. They confirm that an operational plan or completed evidence has been reviewed by the accountable person.

Configure each required parallel branch in this order:

1. Create the approval and assign it to the configured approver.
2. Update the case with the returned approval ID and requested timestamp.
3. Post a restricted Teams message containing the case ID, review purpose, due time, and approval link where available.
4. Wait for the approval response with a two-day timeout for normal cases.
5. For departures scheduled within two days, apply the shorter urgent-review interval approved by the business, such as four hours before reminder and eight hours before escalation.
6. On approval, store responder, response time, comments, and Approved status.
7. On rejection, store comments, mark Rejected, and move the case to Needs Information.
8. On timeout, mark Timed Out, attempt cancellation of the outstanding approval where supported, and notify People Operations.

The daily monitoring flow sends a reminder after 24 hours and escalation after 48 hours for standard reviews. Interface labels and timeout settings may vary between Power Automate versions, but the trigger, stored approval ID, response status, and run-after behavior remain the same.

If an approver is unavailable, People Operations enters a delegate in the approved delegate field. The prior request is cancelled where possible, the earlier approval ID remains in history, and Approval Automation State is set back to Queued. The new approval is not allowed to overwrite the old evidence.

A rejected review is treated as a request for correction unless the approver’s comments explicitly require cancellation. People Operations corrects the case, records what changed, and requeues only the affected review.

Step 7: Add Documents and File Management

Create a SharePoint document library named Offboarding Evidence. Disable anonymous sharing and restrict external sharing according to the organization’s policy. Enable version history.

Use this folder pattern:

/Offboarding Evidence/
  /2026/
    /OB-2026-000184/
      /01 HR/
      /02 IT/
      /03 Manager/
      /04 Payroll/
      /05 Finance/
      /06 Legal/
      /07 Device/
      Case Manifest.txt
      Closure Summary.txt

Use only the Case ID in folder names. Employee names are available inside restricted metadata and do not need to appear in URLs or broad navigation.

Use naming conventions such as:

OB-2026-000184_IT_AccessRemoval_2026-08-28.pdf
OB-2026-000184_Device_CourierReceipt_2026-08-29.pdf
OB-2026-000184_Manager_HandoverPlan_v1.docx

The intake flow creates a text manifest containing the case ID, employee ID, manager, scheduled access-removal time, required workstreams, and creation timestamp. It excludes the detailed departure reason, payroll amounts, legal advice, credentials, and customer names.

Task owners upload evidence to the appropriate workstream folder. They then submit the exact document or folder URL through the Task Completion form. SharePoint version history handles file replacement, but owners should upload a new version rather than deleting prior evidence.

If a file with the expected fixed name already exists during a retry, the flow retrieves its identifier rather than creating a duplicate. User-provided evidence files are never overwritten automatically.

Configure maximum upload sizes and file types based on current Microsoft 365 limits and company policy. Do not invent a hard-coded limit in the flow unless the organization has approved one.

Retention Review Date and Sensitivity metadata are applied to the case folder or documents. Legal defines the retention schedule. If Microsoft Purview retention features are licensed and configured, approved labels can be applied. Otherwise, the workflow creates a retention-review task rather than automatically deleting records.

When the case closes, People Operations reviews direct folder permissions and removes temporary manager access. The automation records that this permission review was completed.

Step 8: Add Reporting and Operational Views

Use Microsoft Lists views and a restricted SharePoint operations page. Add the relevant Lists as tabs in the private Teams operations channel.

The daily monitoring flow updates overdue counts and open-task rollups. This avoids depending on calculated columns that may not refresh merely because the current date changed.

The operations page should show case volume by status, overdue tasks by workstream, departures in the next seven days, and unresolved automation errors. People Operations owns business reporting. The automation owner owns failed-run reporting.

Alert thresholds are configured rather than embedded in every flow. An access-removal task becomes critical immediately after its exact deadline. Routine device-return escalation may wait until the approved grace period has expired.

Step 9: Add Security and Governance Controls

• Apply least-privilege permissions to Lists, libraries, Forms, Teams, and flow ownership.
• Use authenticated internal Forms and capture responder identity.
• Restrict flow editing to named owners and approved administrators.
• Store credentials in managed Power Automate connections, not Lists, code blocks, task notes, or Teams messages.
• Keep employee names, UPNs, departure types, legal notes, payroll details, and customer information out of broad channel messages.
• Use case IDs and task IDs in operational notifications whenever possible.
• Enable SharePoint version history and retain Power Automate run history according to approved policy.
• Review direct folder permissions before case closure.
• Remove former employee and former administrator access promptly through established identity procedures.
• Document connection-owner succession so the automation is not disabled when an owner leaves.
• Back up list definitions, task templates, flow exports, configuration values, and operating documentation.
• Separate test data from production personal information.
• Require human approval for access execution, payment release, legal preservation, exceptions, and closure.
• Do not send offboarding data to an AI service until privacy, contractual, regional, and security reviews are complete.
• When AI is enabled, exclude employee names, UPNs, reasons, credentials, payroll values, legal advice, customer names, and document contents unless separately approved.

The workflow supports evidence collection but does not replace legal advice or an organization’s formal records-retention program. Retention periods, deletion restrictions, legal holds, and employee privacy rights must be defined by authorized legal and compliance personnel.

Step 10: Deploy and Test

1. Build Lists, libraries, Forms, and flows in a non-production SharePoint site.
2. Use fabricated employees, account names, device identifiers, and approval records.
3. Create at least one sample for each conditional branch.
4. Test normal, urgent, rejected, blocked, delegated, duplicate, unauthorized, and failed-connection scenarios.
5. Have People Operations, IT, payroll, finance, legal, and a manager complete user acceptance testing.
6. Export or document the tested flow versions and configuration.
7. Create production Forms and rebind all flow connections to production resources.
8. Populate production Task Templates and Configuration records through a controlled review.
9. Run a pilot with one or two low-risk, scheduled departures while retaining the existing checklist as a verification control.
10. Compare the generated tasks and evidence with the approved manual checklist.
11. Resolve discrepancies before expanding use.
12. Activate the reminder, history, rollup, and error-monitoring flows.
13. Publish a short operating guide covering intake, task completion, delegation, exceptions, evidence, retry, and closure.
14. Assign a launch support owner and backup owner.
15. Review every run during the first month and sample completed cases afterward.

If the deployment must be rolled back, disable the intake trigger, retain all created records, continue using the documented fallback checklist, and reconcile every open case before restarting automation. Do not delete partial case evidence during rollback.

Code and Configuration

The core implementation does not require custom code. Microsoft Forms, SharePoint, Lists, Teams, Approvals, and Power Automate provide the required triggers and actions through native connectors. The configuration below supplies the expressions and control structure needed to reproduce the workflow.

Central configuration values

Store only non-secret values in the Configuration list. Credentials remain in Power Automate connection objects or the organization’s approved secret-management process.

Normalization and key expressions

Populate variables from Forms dynamic content before using these expressions. This avoids dependence on generated internal question identifiers.

Normalized employee UPN:
toLower(trim(variables('varEmployeeUPN')))

Case key:
toLower(
  concat(
    trim(variables('varEmployeeUPN')),
    '|',
    formatDateTime(variables('varLastWorkingDate'), 'yyyy-MM-dd')
  )
)

Power Automate run ID:
workflow()?['run']?['name']

The Case Key identifies possible duplicate offboarding requests for the same account and date. It is a review key, not a substitute for the unique Forms response ID.

Case ID and folder expressions

Rename the Create item action to Create_case before using this expression.

Case ID:
concat(
  'OB-',
  formatDateTime(utcNow(), 'yyyy'),
  '-',
  formatNumber(outputs('Create_case')?['body/ID'], '000000')
)

Case folder:
concat(
  '/Offboarding Evidence/',
  formatDateTime(utcNow(), 'yyyy'),
  '/',
  variables('varCaseId')
)

Local time conversion

The form uses controlled time choices and approved Windows time-zone identifiers. Build the local timestamp and convert it to UTC.

Local date and time:
concat(
  formatDateTime(variables('varAccessRemovalDate'), 'yyyy-MM-dd'),
  'T',
  variables('varAccessRemovalTime'),
  ':00'
)

UTC access-removal timestamp:
convertToUtc(
  outputs('Compose_Local_Access_Time'),
  variables('varSourceTimeZone'),
  'yyyy-MM-ddTHH:mm:ssZ'
)

Test dates on both sides of daylight-saving changes for every allowed time zone.

Explicit task-condition mapping

Inside Apply to each Task Template, use a Switch action on Condition Code. Do not evaluate arbitrary expressions stored as text.

ALWAYS
Result: true

HAS_DEVICE
Result: equals(variables('varHasDevice'), true)

HAS_CUSTOMER_HANDOVER
Result: equals(variables('varHasCustomerHandover'), true)

HAS_PRIVILEGED_ACCESS
Result: equals(variables('varHasPrivilegedAccess'), true)

HAS_FINANCE_ASSET
Result: equals(variables('varHasFinanceAsset'), true)

LEGAL_REVIEW
Result: equals(variables('varLegalReviewRequired'), true)

Due-date configuration

Use a Switch action on Due Anchor. Store the template Offset Days as an integer.

Submission anchor:
addDays(utcNow(), int(items('Apply_to_each_template')?['OffsetDays']))

Last Working Date anchor:
addDays(
  variables('varLastWorkingDate'),
  int(items('Apply_to_each_template')?['OffsetDays'])
)

Access Removal anchor:
addDays(
  variables('varAccessRemovalAtUtc'),
  int(items('Apply_to_each_template')?['OffsetDays'])
)

Approval gate evaluation

First place each choice value into a text Compose action. Then evaluate whether every required review is either Not Required or Approved.

and(
  or(
    equals(outputs('Manager_Approval_Value'), 'Not Required'),
    equals(outputs('Manager_Approval_Value'), 'Approved')
  ),
  or(
    equals(outputs('Finance_Approval_Value'), 'Not Required'),
    equals(outputs('Finance_Approval_Value'), 'Approved')
  ),
  or(
    equals(outputs('IT_Risk_Approval_Value'), 'Not Required'),
    equals(outputs('IT_Risk_Approval_Value'), 'Approved')
  ),
  or(
    equals(outputs('Legal_Approval_Value'), 'Not Required'),
    equals(outputs('Legal_Approval_Value'), 'Approved')
  )
)

Evidence URL validation

and(
  startsWith(
    toLower(variables('varEvidenceUrl')),
    concat('https://', toLower(variables('varApprovedSharePointHost')))
  ),
  contains(
    toLower(variables('varEvidenceUrl')),
    toLower(variables('varCaseId'))
  )
)

This verifies the expected host and case path. People Operations must still review whether the linked document is the correct evidence.

Power Automate scope and run-after configuration

Place each major flow inside three Scopes named Try, Catch, and Finally.

1. Try contains validation and business actions.
2. Catch is configured to run after Try has failed, timed out, or been skipped unexpectedly.
3. Catch updates the case when a case ID exists. Otherwise, it creates an Automation Errors item keyed by the Forms response ID.
4. Finally runs after both successful and failed outcomes and records the final run timestamp.

Use this expression to capture a bounded diagnostic summary. Never include connection secrets or full sensitive payloads in the error field.

take(
  string(result('Try')),
  1800
)

Configure transient connector actions with exponential retry where the action supports it. A representative policy is three attempts beginning at a short interval. Validation failures, authorization failures, approval rejection, and duplicate cases should not be retried as technical errors.

Test each flow by submitting sample data, reviewing the run history, opening each action’s inputs and outputs, confirming returned IDs, and verifying that duplicate replays do not create additional cases, tasks, folders, manifests, or approvals.

Failure Handling and Operational Reliability

The Automation Errors list functions as a dead-letter queue. New errors remain visible until they are Resolved, Retrying, or Accepted as a documented manual outcome. Every resolved error records who resolved it, what action was taken, and whether reconciliation was completed.

A daily reconciliation flow compares active cases with their tasks and folder links. It identifies cases with no tasks, tasks with no parent case, missing folders, mismatched status rollups, and unresolved errors.

Idempotency is enforced with Forms response IDs, Case Keys, Case IDs, Task Keys, fixed manifest names, stored folder links, and approval automation states. These controls allow recovery after partial completion without creating duplicate operational work.

A Complete Example

On August 17, 2026, a People Operations coordinator submits the Offboarding Intake form for Jordan Lee, employee ID E-1047, in Client Delivery. The final working date is August 28, 2026. Access must be removed at 17:00 Eastern Standard Time on that date.

The form records these conditions:

• Departure type: Voluntary.
• Company device: Yes.
• Customer handover: Yes.
• Privileged access: No.
• Company card or outstanding finance item: Yes.
• Legal hold review requested: No.

Microsoft Forms returns response ID 284. Power Automate retrieves the response, verifies the submitter, normalizes the UPN, converts the access-removal time to UTC, and calculates the Case Key.

No matching response ID or active Case Key exists. Power Automate creates Cases list item 184 and generates:

Case ID: OB-2026-000184
Form Response ID: 284
Case Key: normalized-user-upn|2026-08-28
Initial Case Status: Intake Validation

SharePoint creates:

/Offboarding Evidence/2026/OB-2026-000184/

The flow creates the seven workstream folders and Case Manifest.txt. It stores the returned folder URL in the case.

Nine applicable tasks are generated. They include HR validation, IT access inventory, access removal, record preservation, manager customer handover, final payroll, finance clearance, device return, and final HR review. No privileged-access or legal-preservation task is created.

The manager and finance approval statuses are Pending. IT-risk and legal statuses are Not Required. The case moves to Awaiting Conditional Review.

The manager receives a review request confirming that the handover plan has an owner and secure storage location. Finance receives a separate review concerning the company card and open expenses. Representative approval identifiers are stored with the case.

Both reviewers approve. Power Automate records their identities, response dates, and comments, then moves the case to Scheduled. The approval actions do not approve Jordan’s departure. That authorization already occurred through the company’s HR process.

Seven days before departure, task owners receive private Teams reminders. The manager uploads the handover plan to the Manager folder and submits the Task Completion form. The flow verifies the manager’s identity, Task ID, Case ID, and SharePoint link before marking the task Completed.

At the scheduled time on August 28, the IT administrator removes access through the company’s identity and application administration procedures. The administrator uploads the approved evidence report and completes task OB-2026-000184-IT_DISABLE_ACCESS. The flow records the completion time and responder but does not perform the access-removal action itself.

Payroll records final-pay confirmation without placing payroll amounts in the case. Finance records card cancellation and expense reconciliation. The company device is delayed in transit and becomes one day overdue. The monitoring flow raises Escalation Level 2, notifies the asset owner and People Operations, and marks the case Blocked.

The courier receipt and returned-device confirmation are uploaded the next day. The device task is completed, the blocked count returns to zero, and the case moves back to In Progress.

Once every mandatory task is complete and all evidence links are present, the rollup flow moves the case to Ready for HR Closure. The People Operations manager reviews the evidence, confirms temporary folder permissions were removed, and approves closure.

Power Automate creates Closure Summary.txt, stores the final approval identifier, records the closed date, and changes the status to Closed. Status History contains the transitions from Intake Validation through Awaiting Conditional Review, Scheduled, In Progress, Blocked, Ready for HR Closure, and Closed.

Implementation Cost

The following amounts are representative planning assumptions, not verified client costs. Cedarvale is assumed to have existing Microsoft 365 licensing that supports the required Forms, Lists, SharePoint, Teams, standard connector, and approval features. Organizations must verify current licensing and storage entitlements.

If the tenant requires premium connectors, additional Power Automate capacity, advanced retention, or additional SharePoint storage, those costs must be quoted using current Microsoft terms. A nominally free configuration still requires design, testing, documentation, monitoring, and maintenance effort.

Estimated Time and Cost Savings

The estimate measures administrative coordination, duplicate entry, reminder work, evidence reconciliation, and status reporting. It excludes substantive work that still must happen, such as conducting a customer handover, physically shipping a device, reviewing a legal hold, or actually removing access.

Current monthly labour hours: Monthly volume × current minutes per record ÷ 60

3 × 300 ÷ 60 = 15.00 hours

New monthly labour hours: Monthly volume × new minutes per record ÷ 60, plus exception handling and maintenance

Base handling:
3 × 95 ÷ 60 = 4.75 hours

Exception handling:
3 × 20% × 45 ÷ 60 = 0.45 hours

Maintenance:
2.50 hours

Total new monthly labour:
4.75 + 0.45 + 2.50 = 7.70 hours

Monthly hours recovered: Current monthly labour hours minus new monthly labour hours

15.00 - 7.70 = 7.30 hours

Estimated monthly labour value: Monthly hours recovered × loaded hourly labour cost

7.30 × $52 = $379.60

Net estimated monthly value: Monthly labour value minus recurring tool costs

$379.60 - $0 = $379.60

Estimated payback period: One-time implementation cost ÷ net estimated monthly value

$7,498 ÷ $379.60 = 19.75 months

Recovered time does not automatically reduce payroll. It may create additional capacity, reduce overtime, shorten turnaround, decrease administrative follow-up, and allow the same team to manage more cases without proportional coordination effort.

Non-financial benefits include clearer ownership, more timely access-removal preparation, fewer incomplete records, consistent escalation, centralized evidence, improved auditability, reduced dependence on one coordinator, and a more predictable experience for managers and departing workers.

Readers should replace the case volume, handling time, exception rate, loaded labour rate, software entitlement, maintenance requirement, implementation cost, and storage assumptions with their own measured values.

Adding AI to the Automation

AI is an optional enhancement added only after the rule-based workflow is stable. The core benefits, including task creation, assignments, due dates, approvals, access deadlines, evidence validation, reminders, escalation, and status history, come from ordinary automation.

Potential AI applications include summarizing open tasks, classifying unstructured blocker notes, extracting task candidates from manager handover documents, suggesting categories for unusual requests, and identifying potentially incomplete descriptions.

AI should not be used where deterministic controls are more reliable. Required fields, date validation, exact identity matching, duplicate keys, access deadlines, approval thresholds, permission checks, status transitions, and evidence requirements remain rule-based.

The Recommended AI Enhancement

The recommended enhancement is a sanitized summary of open tasks and blockers. It supports People Operations review without changing tasks, approving termination, disabling access, or deciding whether a case can close.

• Trigger: A user requests a summary or a scheduled flow detects a material task change or escalation.
• AI input: Case ID, generic task ID, workstream, status, due date, escalation level, and sanitized blocker notes.
• Excluded input: Employee name, employee UPN, departure reason, payroll amount, medical information, allegations, legal advice, credentials, customer names, document contents, and access secrets.
• Output: A JSON summary, overdue task references, blockers, follow-up questions, source task IDs, and confidence estimate.
• Record update: Store the validated summary in a separate AI Summary field with generated time and model reference.
• Human review: People Operations verifies the summary against the task list before using it.
• Failure behavior: Display the deterministic Lists view instead of an AI summary.

Reusable system instruction

You summarize operational offboarding tasks for an authorized People Operations reviewer.

Use only the task data supplied by the user.
Do not infer a termination reason, employee intent, legal conclusion, access state, payroll outcome, or employment decision.
Do not recommend terminating employment, disabling access, releasing payment, deleting records, or closing the case.
Do not invent tasks, owners, dates, evidence, or customer information.
Identify overdue items only from the supplied due dates and supplied current UTC time.
Reference every task by its supplied task_id.
Return valid JSON matching the required schema and no additional text.
If the data is incomplete or contradictory, describe the limitation and lower confidence.

Reusable user prompt

Current UTC time:
{{CURRENT_UTC_TIME}}

Case ID:
{{CASE_ID}}

Open task data:
{{TASKS_JSON}}

Create a concise operational summary for human review.

The summary must:
1. State the number of open, blocked, and overdue tasks.
2. Identify immediate deadlines.
3. List blockers using only supplied notes.
4. Suggest neutral follow-up questions.
5. Include only task IDs present in the input.
6. Avoid employment, legal, payroll, and access decisions.
7. Return JSON matching the required schema.

Required JSON schema

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "case_id",
    "summary",
    "open_task_count",
    "blocked_task_count",
    "overdue_task_count",
    "immediate_task_ids",
    "blockers",
    "follow_up_questions",
    "source_task_ids",
    "confidence",
    "limitations"
  ],
  "properties": {
    "case_id": {
      "type": "string"
    },
    "summary": {
      "type": "string",
      "maxLength": 1200
    },
    "open_task_count": {
      "type": "integer",
      "minimum": 0
    },
    "blocked_task_count": {
      "type": "integer",
      "minimum": 0
    },
    "overdue_task_count": {
      "type": "integer",
      "minimum": 0
    },
    "immediate_task_ids": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "blockers": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": [
          "task_id",
          "description"
        ],
        "properties": {
          "task_id": {
            "type": "string"
          },
          "description": {
            "type": "string",
            "maxLength": 300
          }
        }
      }
    },
    "follow_up_questions": {
      "type": "array",
      "items": {
        "type": "string",
        "maxLength": 300
      }
    },
    "source_task_ids": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "limitations": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  }
}

Optional API configuration

An organization may connect Power Automate to an approved Azure OpenAI deployment through a governed custom connector. A custom connector may require additional Power Platform entitlement. Verify licensing before implementation.

The known endpoint pattern for a chat-completions deployment is:

POST https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/chat/completions?api-version=YOUR_SUPPORTED_API_VERSION

Use the API version supported by the organization’s deployed Azure resource. Do not guess or hard-code a version copied from an unrelated environment.

Configure the connector to store YOUR_AZURE_OPENAI_API_KEY as an API-key credential named api-key, or use approved Microsoft Entra authentication where the organization’s architecture supports it. Never place the credential in a List, prompt, Teams message, or flow variable.

{
  "messages": [
    {
      "role": "system",
      "content": "You summarize operational offboarding tasks for an authorized People Operations reviewer. Use only supplied data, make no employment or access decisions, and return valid JSON only."
    },
    {
      "role": "user",
      "content": "@{outputs('Compose_AI_User_Prompt')}"
    }
  ],
  "temperature": 0.1
}

The expected chat-completions response contains generated content in the first choice’s message content. Extract it in Power Automate, then pass the returned text to Parse JSON using the schema above.

body('Call_Approved_AI')?['choices'][0]?['message']?['content']

After parsing, validate these conditions deterministically:

• The returned Case ID equals the source Case ID.
• Every source task ID and blocker task ID exists in the input set.
• Returned counts match counts calculated by Power Automate.
• Overdue task references match deterministic due-date comparisons.
• Confidence is at least the approved review threshold, such as 0.75.
• No prohibited fields or unexpected properties are present.

If validation fails, discard the generated summary, log a malformed-output event, and post a deterministic task list instead. Configure exponential retry for HTTP 429 and temporary server errors. After three unsuccessful attempts, use the non-AI fallback and notify the automation owner without delaying the core offboarding workflow.

Benefits of the AI Enhancement

• Reduces the time needed to read several open-task notes.
• Produces a consistent short summary for a human reviewer.
• Highlights supplied blocker notes and immediate deadlines.
• Supports handover between People Operations coordinators.
• Improves review of unstructured notes without changing deterministic records.

AI does not create the case, determine required tasks, calculate due dates, identify authorized responders, approve the plan, disable access, or close the case. Those benefits and controls already exist in the core automation.

What Remains Rule-Based or Human-Controlled

Estimating the Additional Value of AI

The AI estimate uses nine summary events per month, representing three summaries for each of three monthly cases.

Core automation review time:
9 × 7 minutes = 63 minutes

AI human review:
9 × 3 minutes = 27 minutes

Expected correction time:
9 × 12% × 4 minutes = 4.32 minutes

Expected fallback time:
9 × 5% × 7 minutes = 3.15 minutes

Expected AI-assisted total:
27 + 4.32 + 3.15 = 34.47 minutes

Additional time recovered:
63 - 34.47 = 28.53 minutes
28.53 ÷ 60 = 0.4755 hours

Estimated labour value:
0.4755 × $52 = $24.73

Estimated AI usage:
9 × $0.10 = $0.90

Net additional monthly value:
$24.73 - $0.90 = $23.83

These correction and failure rates are planning assumptions, not measured results. Cedarvale would replace them with pilot observations. At this volume, AI offers modest additional capacity rather than being necessary for the business case.

Testing Checklist

Use fabricated sample data before processing any real employee information.

Ongoing Maintenance

The People Operations manager is the primary business owner. The automation owner is the primary technical owner. Each role has a named backup.

Documentation should include field definitions, task templates, flow diagrams, connection owners, retry instructions, exception procedures, retention rules, test records, and the date of the last successful recovery test.

When to Move to Dedicated Software

The Microsoft 365 implementation remains appropriate while the volume, integration complexity, and control requirements are manageable. It should not be replaced merely because a dedicated product exists.

Reassess the architecture when one or more of these conditions emerge:

• Monthly transaction volume makes unique permissions, flow runs, or manual evidence review difficult to maintain.
• The company requires direct identity governance across many applications and tenants.
• Device commands, account suspension, session revocation, mailbox transfer, and license recovery must be coordinated transactionally.
• Formal access-certification campaigns or segregation-of-duties controls are required.
• Multiple legal entities, countries, payroll systems, or retention regimes create complex branching.
• Formal regulatory audits require stronger immutable evidence or certified controls.
• Exception rates grow because the underlying workflow has become more complex.
• SharePoint list performance, unique permissions, or storage architecture becomes difficult to manage.
• The business needs a customer-facing or employee-facing portal.
• Offline or specialized mobile workflows are required.
• Dedicated vendor support and contractual service levels become necessary.
• Maintenance time is growing faster than transaction volume.
• Security risk increases because too many systems depend on manual confirmation.
• Advanced analytics require a dedicated data model and reporting layer.

Relevant categories include identity governance and administration platforms, HR service-delivery systems, IT service-management platforms, endpoint lifecycle platforms, and dedicated employee lifecycle applications. A later migration should preserve the Case ID, task history, evidence links, approval records, and retention metadata established by the Microsoft 365 implementation.

Implementation Checklist

• Confirm the business definition of an offboarding case.
• Document which employment decisions occur before workflow intake.
• Identify People Operations, IT, payroll, finance, legal, and manager responsibilities.
• Confirm monthly volume, deadlines, exceptions, and evidence requirements.
• Verify Microsoft 365 and Power Automate entitlements.
• Create test and production sites, Lists, Forms, libraries, Teams destinations, and connections.
• Assign primary and backup business and technical owners.
• Configure least-privilege permissions and private operational channels.
• Build the Offboarding Intake and Task Completion forms.
• Create Cases, Tasks, Task Templates, Status History, Configuration, and Automation Errors lists.
• Enable unique values, indexes, version history, and controlled choices.
• Define Case ID, Case Key, Task Key, and Forms response idempotency rules.
• Map every intake field to the system of record.
• Configure folder structure, naming conventions, evidence metadata, and retention review.
• Build intake validation, case creation, folder creation, and task-generation automation.
• Build manager, finance, IT-risk, legal, and final closure approvals.
• Configure parallel review branches and sequential closure approval.
• Configure reminders, escalation, delegation, rejection, and timeout behavior.
• Build task-completion validation and owner authorization.
• Build task rollups, case status transitions, and status history.
• Configure Teams notifications using minimum necessary information.
• Create operational views for new, open, overdue, blocked, incomplete, failed, and closed records.
• Implement Try, Catch, Finally, retry limits, and the Automation Errors queue.
• Test duplicate events, partial failures, expired credentials, unauthorized users, and recovery.
• Test every conditional task and approval branch with sample data.
• Complete user acceptance testing with all participating departments.
• Document rollout, fallback, support, rollback, and reconciliation procedures.
• Record representative implementation and recurring cost assumptions.
• Replace savings assumptions with measured internal handling times and labour rates.
• Deploy the rule-based workflow before adding AI.
• If AI is enabled, approve the endpoint, prohibited-data rules, prompt, schema, validation, fallback, and cost monitoring.
• Assign maintenance owners and a review schedule.
• Define the volume, security, integration, and regulatory criteria that would justify dedicated software.