Tracking Business Continuity Tests and Recovery Actions

The Business Situation

Harborstone Components is a fictional 145-person industrial components manufacturer with a production facility, warehouse operations, and a small corporate team. Its continuity program covers IT services, production operations, shipping, facilities, utilities, suppliers, and administrative processes.

The continuity coordinator works within the strategy function. Process ownership is distributed across IT, operations, manufacturing, warehouse management, finance, and facilities. An IT infrastructure manager supports technical recovery, while department managers own process workarounds and corrective actions.

The company has identified 28 critical processes. Each process has a business continuity plan, but most plans exist as Word documents. An Excel workbook holds review dates, test dates, recovery time objectives, and owner names. Supporting evidence is spread across email, Teams conversations, and shared folders.

In a typical month, the business handles approximately 12 continuity requests or incidents, conducts nine plan tests, and records or closes 26 recovery actions. This creates about 47 workflow transactions requiring ownership, follow-up, documentation, or reporting.

The problem is not the absence of continuity documentation. The problem is the lack of a controlled workflow around that documentation. Owners, dependencies, approvals, tests, evidence, issues, and corrective tasks cannot be reliably traced from initiation through closure.

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

The original process followed a recognizable pattern, but each department executed it differently.

1. A department manager opened the latest continuity plan from a shared folder.
2. The manager emailed the continuity coordinator if a plan change, test, or recovery issue was required.
3. The coordinator copied information from the email into a tracking spreadsheet.
4. The coordinator searched the plan document for the current owner, recovery target, workaround, and dependencies.
5. Test participants exchanged schedules, instructions, and evidence through email or Teams.
6. Test results were added to a separate document or spreadsheet tab.
7. Corrective actions were assigned by email, usually without a consistent due-date or escalation rule.
8. The coordinator manually followed up with action owners and updated the spreadsheet.
9. At reporting time, the coordinator reconciled plan documents, email messages, test records, and action statuses.

Because records were disconnected, the business could not answer several basic questions without manual research: Which critical processes have not been tested? Which tests failed? Which recovery actions are overdue? Which plans have unapproved changes? Which incidents exceeded acknowledgement targets? Which process depends on a particular application or supplier?

The continuity coordinator also represented a concentration risk. The process depended on one employee knowing the spreadsheet structure, document locations, department contacts, and informal follow-up rules.

What the New System Needed to Do

The implementation team defined the requirements before choosing the platform. The system needed to structure continuity governance without attempting to replace every plan document or operational recovery tool.

The team also decided that the first release would use continuous elapsed time for incident acknowledgement targets. Business-calendar calculations were not necessary for continuity incidents because critical events could occur outside normal working hours.

Implementation Approaches Considered

Improved spreadsheets

A better workbook could add data validation, protected columns, standardized tabs, and overdue formulas. It would reduce inconsistency, but it would not provide reliable ticket routing, approvals, file links, reminders, or record-level history. It would also retain the dependency on one workbook owner.

Airtable

Airtable could model linked processes, plans, tests, and actions effectively. Its forms and automations would support a relatively quick implementation. Harborstone Components did not select it because the company already governed identity, files, collaboration, and access within Microsoft 365. Introducing another data platform would require additional privacy, access, retention, and procurement work.

Microsoft 365

Microsoft Lists provided structured records, person fields, lookup relationships, views, version history, and SharePoint-backed storage. Microsoft Forms provided simple controlled intake. Power Automate supplied routing, approvals, reminders, and escalations. Microsoft Teams became the operational workspace.

This option retained familiar tools and aligned with the company’s existing identity controls. It was selected for the initial implementation.

Dedicated governance software

A dedicated business continuity platform could provide advanced scenario management, dependency mapping, regulatory reporting, exercise libraries, and vendor support. Harborstone Components did not yet need that level of specialization. Procurement and migration would also have delayed the immediate need for visible ownership and corrective-action control.

Custom application

A custom application offered the greatest flexibility but was disproportionate to 28 critical processes and approximately 47 monthly workflow transactions. It would introduce software engineering, hosting, security, support, and release-management obligations that the current program did not require.

The Selected Solution

The selected implementation connected Microsoft Forms, Microsoft Lists, Power Automate, Microsoft Teams, and a SharePoint document library associated with the continuity Team.

Existing Word continuity plans were retained. The implementation did not attempt to convert every plan into a database record. Instead, Microsoft Lists held the metadata required to govern each plan, while the controlled document library retained the approved files.

Manual copying, reminder emails, action reconciliation, and routine status reporting were removed. Process owners still controlled plan content, recovery decisions, action completion, and approval of material changes.

System Architecture and Data Flow

1. Submission: An authenticated employee submits a continuity incident or request through Microsoft Forms. Forms records the response ID and requester identity. If the trigger fails, the response remains available in Forms for reconciliation.
2. Retrieval: Power Automate receives the new-response event and retrieves the full response. Required values are normalized, dates are converted to UTC, and process codes are checked against the Critical Processes list.
3. Duplicate control: The flow searches for the form response ID. A unique Source Response ID column prevents a second case from being created from the same event.
4. Record creation: Power Automate creates an item in the Continuity Cases list. The returned Microsoft List item ID is used to create a unique ticket ID such as BC-202607-317.
5. Assignment: The flow reads the process owner and alternate owner from the Critical Processes list. Incident assignments are immediate. Requests that change plan content can enter approval before assignment.
6. Document handling: The flow creates an evidence folder using the process code, year, and ticket ID. Uploaded files are copied into the folder, and its link is written back to the case.
7. Notification: Power Automate posts a structured notification to the appropriate Microsoft Teams channel and sends a direct notification to the assigned owner when required.
8. Monitoring: A scheduled flow checks acknowledgement deadlines, due dates, pending approvals, test dates, and recovery actions. It records reminders and increases the escalation level only when the next threshold is reached.
9. Testing and actions: A second Form captures test results. Failed tests and tests that pass with actions create Recovery Actions records linked to the test and process.
10. Closure: Owners submit completion evidence. A process owner or continuity coordinator validates closure. Final timestamps, status, validator, and evidence links are retained.
11. Failure path: A Catch scope updates the source record when possible and creates an Automation Failures item. If Microsoft Lists is unavailable, Power Automate run history remains the fallback diagnostic record.

• Intake: Microsoft Forms for internal continuity requests, incidents, and test results
• System of record: Microsoft Lists on one Team-connected SharePoint site
• Automation layer: Power Automate cloud flows using Microsoft 365 connectors
• Document storage: SharePoint Continuity Evidence library
• Notifications: Microsoft Teams channels and direct messages
• Reporting: Microsoft Lists views, Teams tabs, and scheduled summaries
• AI layer: Optional governed language model for suggestions and summaries only

Data Structure

All related lists are created on the same SharePoint site so that Microsoft Lists lookup columns can reference one another. Dates are stored in UTC and displayed according to the user’s Microsoft 365 regional settings.

Relationships

Critical Process to Continuity Plan

One critical process can have several plan versions, but only one plan is marked Approved and Current.

Critical Process to Dependency

One process can have multiple application, supplier, facility, utility, data, and people dependencies.

Critical Process to Test

Each test references one process and one plan version.

Test or Case to Recovery Action

An action references its originating test or case and the affected process.

Record to Evidence

Each case, test, and action stores a hyperlink to its controlled evidence folder.

Workflow Statuses and Ownership

A record can move backward when evidence is incomplete, a test result is challenged, an owner requests more information, or a validator determines that the corrective action did not address the original issue. Only designated coordinators can cancel or administratively close records.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Create a Microsoft Team named for the continuity program. Use its associated SharePoint site for all lists and the evidence library.
2. Confirm that the organization’s Microsoft 365 licensing supports Microsoft Forms, Microsoft Lists, Teams, SharePoint, Power Automate, approvals, and the required standard connectors. Licensing should be verified against the tenant’s current agreements.
3. Create security groups for Continuity Administrators, Continuity Coordinators, Process Owners, Test Coordinators, Action Owners, and Read-Only Reviewers.
4. Assign list and library access through groups rather than individual users wherever practical.
5. Create a nonpersonal automation owner account or approved service identity. Protect it with organizational sign-in controls and assign only the permissions needed for the site, forms, Team, and flows.
6. Add at least two flow co-owners so that employee absence or departure does not leave the automation unmanaged.
7. Create a shared continuity mailbox if email confirmations or fallback alerts are required. Do not use a personal mailbox as the only notification route.
8. Create a private test channel and test copies of the lists, library, and forms. Use test users representing a requester, process owner, approver, coordinator, and unauthorized employee.
9. If the organization uses managed Power Platform environments or solution packaging, create connection references and environment-specific configuration values. Otherwise, document each flow connection and export protected flow packages before production deployment.
10. Apply the organization’s data-loss prevention policies so continuity information cannot be sent to unapproved consumer connectors.

The automation identity needs permission to read and update the continuity lists, create folders and files in the evidence library, read the group-owned Forms, post to approved Teams channels, and create approval records. It should not receive unrelated site-wide or tenant-wide privileges.

Step 2: Build the Intake

Create two group-owned Microsoft Forms. A group-owned form avoids dependence on one employee and stores internal file uploads within the Microsoft 365 group’s storage context. Interface labels can vary, but the required behavior is an organization-only form that records identity.

Microsoft Forms choices are not automatically synchronized with Microsoft Lists. With 28 processes, the coordinator can maintain the process-code choices as a controlled monthly task. The Not Listed value prevents an employee from selecting an incorrect process merely to submit the form. If dynamic lookup values become essential, a Power Apps intake application would be a more appropriate upgrade.

The confirmation message displays the expected response process and explains that urgent safety, emergency, or cybersecurity reporting procedures must still be followed. It also instructs users not to include passwords, credentials, medical details, or unnecessary personal information.

Spam risk is reduced by restricting forms to authenticated employees. Incomplete submissions are rejected by required fields where possible. Conditional omissions that Forms cannot validate are marked Manual Review by Power Automate.

Step 3: Create the System of Record

Create the following Microsoft Lists on the same site:

• Critical Processes
• Continuity Plans
• Process Dependencies
• Continuity Cases
• Continuity Tests
• Recovery Actions
• Continuity Contacts
• Owner Delegations
• Automation Failures

Use short internal column names when initially creating fields, such as ProcessCode, SourceResponseId, and AcknowledgementDeadline. Display names can later be expanded without changing the internal names used by Power Automate.

Enable unique values for Process Code, Plan Code, Source Response ID, Ticket ID, Test ID, Action ID, and Schedule Key where applicable. Index Process Code, Status, Owner, Due Date, Next Test Date, Source Response ID, and Automation Status.

After a case item is created, use the returned list ID to generate the ticket ID. Apply the same pattern to tests and actions. This avoids dependence on random values or a separate sequence table.

Create a unique Schedule Key for automatically generated tests. A value such as SHIP-01|2026-09-30|Tabletop prevents a weekly scheduling flow from creating the same test more than once.

Enable version history for operational lists and the document library. Version history provides useful change evidence, but it does not replace a formal audit platform when regulations require immutable logs or specialized retention.

Use list views rather than volatile calculated date formulas for current overdue status. A scheduled flow can also write an explicit SLA State value such as On Track, Due Soon, or Overdue.

Step 4: Connect the Tools

Store the returned list item ID, ticket ID, test ID, action ID, approval ID, and document link in their source records. These identifiers make synchronization and troubleshooting explicit.

Step 5: Build the Core Automation

Automation 1: Intake and ticket creation

• Trigger: Microsoft Forms reports a new response.
• Conditions: The response ID is not already present, required fields exist, and the process code is valid.
• Actions: Retrieve response, normalize values, locate process, determine owner, create case, generate ticket ID, create folder, copy files, calculate deadlines, notify owner, and confirm receipt.
• Fields updated: Ticket ID, Owner, Status, SLA dates, Document Link, Automation Status, Last Automation Run.
• Notification: Teams channel message and requester confirmation.
• Exception: Mark Manual Review and create an Automation Failures record when routing cannot be completed.

Build the flow in this order:

1. Trigger on a new Form response.
2. Retrieve response details.
3. Initialize variables for Response ID, Process Code, Submission Type, Severity, and Requester Email.
4. Use a Try scope for all business actions.
5. Search Continuity Cases for the Source Response ID.
6. Terminate successfully if the response has already been processed.
7. Read the Critical Processes record matching the submitted process code.
8. If no process matches, create the case with Manual Review status and assign the continuity coordinator.
9. If a process matches, select the process owner or active delegate.
10. Calculate the acknowledgement deadline for incidents.
11. Create the Continuity Cases item with Automation Status set to Processing.
12. Capture the returned list item ID.
13. Generate and write the Ticket ID.
14. Create the evidence folder.
15. Copy each uploaded file and record file failures separately.
16. Branch by request type.
17. For incidents, set Assigned and notify immediately.
18. For material plan changes, set Pending Approval and start the approval workflow.
19. For other requests, set Assigned and notify the owner.
20. Update Automation Status to Completed.
21. Use a Catch scope configured to run after failure, timeout, or skipped critical action.
22. In Catch, update the case to Failed or Manual Review and create an Automation Failures item.
23. Use a Finally scope to write Last Automation Run when the case exists.

Automation 2: Test scheduling

• Trigger: Weekly recurrence.
• Conditions: An approved plan has a Next Test Date within 30 days and no matching Schedule Key.
• Actions: Create test, generate Test ID, assign coordinator, create evidence folder, and notify participants.
• Fields updated: Test ID, Status, Coordinator, Schedule Key, Evidence Folder Link.
• Notification: Teams message to the process owner and test coordinator.
• Exception: Invalid or missing owner enters Manual Review.

Automation 3: Test-result processing

• Trigger: New response to the Test Result Form.
• Conditions: Test ID exists and has not already received the same response ID.
• Actions: Update test dates and result, copy evidence, compare recovery time with the RTO, and create actions when needed.
• Fields updated: Test Result, Actual Recovery Minutes, RTO Achieved, Issues Summary, Status, Evidence Link.
• Notification: Result summary to the process owner and continuity coordinator.
• Exception: Conflicting test ID or malformed result enters Manual Review.

Automation 4: Corrective-action creation

• Trigger: A test result is Fail or Pass with Actions, or a case owner requests corrective work.
• Conditions: At least one actionable issue exists.
• Actions: Create one Recovery Actions record per approved issue, generate Action ID, assign owner, set due date, create evidence folder, and notify owner.
• Fields updated: Source Test or Case, Action ID, Owner, Priority, Due Date, Validation Required, Status.
• Notification: Teams assignment containing the action and source record links.
• Exception: Missing action owner routes to the continuity coordinator.

For the initial release, test coordinators enter corrective actions as separate numbered responses or create them directly in the Recovery Actions list. Free-text splitting is not used to create final assignments without human review because line formatting can be inconsistent.

Step 6: Add Approvals, Reminders, and Escalations

Incident response is never held for approval. Approval applies to proposed plan changes, changes to recovery targets, acceptance of overdue corrective-action risk, and administrative closure without normal evidence.

For sequential approval, create the process-owner approval first. Only after an Approve outcome should the flow create the continuity-coordinator approval. For parallel approval, use an approval type that requires all designated approvers when all responses are mandatory.

Store the approval ID, requested date, response date, outcome, approver identity, and comments on the case or related plan record. Configure the approval branch so rejection updates the status to Rejected and sends the requester the recorded reason.

The Owner Delegations list contains Owner, Delegate, Effective From, Effective To, and Active fields. Before creating an approval or assignment, the flow checks for a current delegation. If neither owner nor delegate is available, it assigns the continuity coordinator and marks the item Manual Review.

A five-minute scheduled flow monitors open incident acknowledgements. A daily flow monitors approvals, tests, and corrective actions. Each eligible item has a Next Reminder At value. After sending a reminder, the flow writes Last Reminder At and calculates the next threshold.

Escalation Level begins at zero. The first overdue notification sets it to one. Later escalation occurs only if the record remains open and the next escalation time has passed. This prevents the scheduled flow from sending the same escalation on every run.

Step 7: Add Documents and File Management

Create a SharePoint document library named Continuity Evidence. Use the following folder structure:

Continuity Evidence/
  PROCESS_CODE/
    Plans/
      PLAN_CODE/
    Tests/
      YEAR/
        TEST_ID/
    Incidents/
      YEAR/
        TICKET_ID/
    Actions/
      YEAR/
        ACTION_ID/

File names use the record ID, document category, date, and a sanitized original name. For example:

TEST-2026-84_RecoveryLog_20260715.xlsx
BC-202607-317_Screenshot_20260715.png
ACT-2026-91_ValidationEvidence_20260728.pdf

Power Automate removes or replaces characters that SharePoint does not accept in file names. Files are created in the destination folder before their links are written to the record.

Versioning is enabled for plan documents. Approved plans are not overwritten in place without a new version value and approval evidence. Superseded versions remain subject to the organization’s retention policy.

Access is granted at the library or controlled sub-library level wherever possible. Excessive unique folder permissions are avoided because they are difficult to review and maintain. Highly sensitive cyber or personnel-related continuity evidence can be stored in a separate restricted library while the case record retains only an authorized link.

If an upload fails, the case or test still exists. Evidence Status changes to Failed, the file name and error are logged, and the owner receives instructions to upload the evidence directly to the folder. Duplicate file names are handled by adding the record ID and timestamp rather than silently replacing an existing file.

Step 8: Add Reporting and Operational Views

Create the following Microsoft Lists views and add the most frequently used views as Teams tabs:

• New Cases
• Incidents Awaiting Acknowledgement
• Pending Approvals
• Overdue Cases
• Tests Due in 30 Days
• Tests Without Evidence
• Failed or Qualified Tests
• Open Recovery Actions
• Actions by Owner
• Overdue Critical and High Actions
• Waiting for Information
• Manual Review Queue
• Rejected Requests
• Recently Closed Records
• Automation Failures

Views filter on structured Status, Owner, Due Date, Test Result, Automation Status, and Escalation Level fields. They do not attempt to infer state from free-text notes.

A weekly Power Automate digest summarizes new incidents, overdue actions, tests due, failed tests, pending approvals, and automation failures. The continuity coordinator owns the dashboard definitions, while list owners are responsible for data accuracy.

Processing time is calculated from Created to Acknowledged, Created to Resolved, and Resolved to Closed timestamps. Monthly reporting compares planned tests with completed tests and groups overdue work by process owner and priority.

Alert thresholds are conservative. One failed Critical incident workflow or one unassigned Critical action creates an immediate operational alert. Lower-priority automation failures appear in the daily review queue.

Step 9: Add Security and Governance Controls

• Use Microsoft 365 groups for role-based access.
• Restrict continuity Forms to authenticated employees.
• Limit plan editing to process owners and continuity coordinators.
• Separate sensitive evidence from broadly accessible operational records.
• Do not store passwords, recovery credentials, private keys, or emergency access codes in Microsoft Lists.
• Store connector credentials in managed Power Platform connections, not in list columns or flow text.
• Turn on secure input and output settings for actions that may contain sensitive values.
• Review sharing links and prohibit anonymous evidence links.
• Retain List and library version history according to approved policy.
• Remove former employees from Teams, SharePoint groups, flow ownership, and approval mappings promptly.
• Export or back up critical configuration according to the organization’s recovery process.
• Restrict AI processing to approved fields and services.
• Keep final plan approval, risk acceptance, recovery authorization, and action validation human-controlled.
• Retain approval responses, file links, timestamps, and status history as audit evidence.

Regulatory and contractual requirements vary. Organizations subject to formal resilience, privacy, financial, healthcare, defense, or critical-infrastructure obligations should have legal, privacy, security, and audit specialists review the data model, retention, evidence, and access controls.

Step 10: Deploy and Test

1. Build the lists, forms, library, and flows in a test site or controlled development environment.
2. Populate five representative critical processes with test owners, alternates, plans, and dependencies.
3. Create test users for each role and verify that unauthorized users cannot view restricted evidence.
4. Run every normal, error, approval, reminder, escalation, and recovery test in the Testing Checklist.
5. Conduct user acceptance testing with the continuity coordinator, IT infrastructure manager, two process owners, and one operations manager.
6. Correct field labels, notification wording, views, and ownership rules before production migration.
7. Pilot the system with five critical processes for two weeks.
8. Reconcile all pilot Form response IDs against created List records.
9. Export flow packages and document connections, owners, configuration values, permissions, and recovery procedures.
10. Activate production Forms and flows in phases: intake first, then reminders, approvals, test scheduling, and reporting.
11. Keep the previous workbook read-only during a defined transition period.
12. Communicate the new intake links, emergency exclusions, owner responsibilities, and support contact.
13. Assign a launch support owner and review failed runs daily during the first month.
14. If a critical defect appears, disable the affected flow, retain Form responses, use the documented manual intake procedure, and reprocess records after correction.

Code and Configuration

The core implementation does not require custom code. Microsoft Forms, Microsoft Lists, Power Automate, Teams, Approvals, and SharePoint provide the required triggers and actions through native connectors.

The following configuration values should be documented centrally. Values shown are placeholders.

SITE_URL=https://YOUR_TENANT.sharepoint.com/sites/YOUR_CONTINUITY_SITE
CASE_LIST=Continuity Cases
PROCESS_LIST=Critical Processes
TEST_LIST=Continuity Tests
ACTION_LIST=Recovery Actions
FAILURE_LIST=Automation Failures
EVIDENCE_LIBRARY=Continuity Evidence
TEAM_ID=YOUR_TEAM_ID
OPERATIONS_CHANNEL_ID=YOUR_CHANNEL_ID
CONTINUITY_COORDINATOR=YOUR_EMAIL_ADDRESS
SHARED_MAILBOX=YOUR_EMAIL_ADDRESS

Ticket ID expression

Place this expression in a Compose action named Compose_Ticket_ID after the Create_case action. It combines the year and month with the returned Microsoft List item ID.

concat(
  'BC-',
  formatDateTime(utcNow(),'yyyyMM'),
  '-',
  string(outputs('Create_case')?['body/ID'])
)

Test and action ID expressions

concat(
  'TEST-',
  formatDateTime(utcNow(),'yyyy'),
  '-',
  string(outputs('Create_test')?['body/ID'])
)

concat(
  'ACT-',
  formatDateTime(utcNow(),'yyyy'),
  '-',
  string(outputs('Create_action')?['body/ID'])
)

Incident acknowledgement deadline

Normalize the Form severity into a Compose action named Compose_Severity. Use the following expression in Compose_Acknowledgement_Deadline. The selected assumptions are Critical 15 minutes, High 60 minutes, Medium 240 minutes, and Low 1,440 minutes.

if(
  equals(outputs('Compose_Severity'),'Critical'),
  addMinutes(utcNow(),15),
  if(
    equals(outputs('Compose_Severity'),'High'),
    addMinutes(utcNow(),60),
    if(
      equals(outputs('Compose_Severity'),'Medium'),
      addMinutes(utcNow(),240),
      addMinutes(utcNow(),1440)
    )
  )
)

Duplicate-event condition

Use Get items against the Continuity Cases list with Source Response ID as the filter. After that action, this condition is true only when no prior record exists:

equals(
  length(body('Get_existing_case')?['value']),
  0
)

The list column’s unique-value constraint remains the authoritative duplicate protection if two flow runs reach the create action at nearly the same time.

Scheduled overdue filter

After retrieving active cases, use a Filter array action. Internal field names can differ, so verify them from a test run’s raw output.

@and(
  not(empty(item()?['AcknowledgementDeadline'])),
  not(
    or(
      equals(item()?['Status'],'Resolved'),
      equals(item()?['Status'],'Closed'),
      equals(item()?['Status'],'Cancelled')
    )
  ),
  lessOrEquals(item()?['AcknowledgementDeadline'],utcNow()),
  equals(int(coalesce(item()?['EscalationLevel'],0)),0)
)

Evidence folder path

concat(
  '/',
  outputs('Compose_Process_Code'),
  '/Incidents/',
  formatDateTime(utcNow(),'yyyy'),
  '/',
  outputs('Compose_Ticket_ID')
)

Power Automate scope configuration

1. Create a Scope named Try and place validation, lookups, record creation, file handling, routing, and notification actions inside it.
2. Create a Scope named Catch.
3. Configure Catch to run after Try has failed, timed out, or been skipped unexpectedly.
4. Inside Catch, create an Automation Failures record containing Flow Name, Source Response ID, Record ID, Stage, Timestamp, and available error details.
5. If the case exists, update Automation Status to Failed and Status to Manual Review.
6. Create a Scope named Finally.
7. Configure Finally to run after both successful and failed paths.
8. Write Last Automation Run when a source record is available.
9. For connector actions, retain or configure exponential retry for transient failures. Do not retry validation errors that require corrected data.
10. Mark sensitive connector actions with secure inputs and outputs where supported.

Trigger-loop prevention

Flows triggered by list modification must not run on every automation update. Add a trigger condition that requires the intended status and an empty processing key. For example, an approval dispatcher can require Approval Status to equal Pending and Approval Run Key to be empty.

As field internal names vary, generate the trigger condition from confirmed list metadata rather than copying an unverified display name. The approval flow should immediately write the returned approval ID into Approval Run Key before waiting for the response.

Native deployment and testing

Save each flow with descriptive action names before copying expressions. Turn on the flow, submit a test response, and inspect the run history. Expand each action to compare input and output values. Confirm that person fields receive valid directory email addresses and that choice values match list choices exactly.

Common configuration errors include using a display name instead of an internal field name, passing an array where a single value is required, using a personal Form instead of the group-owned Form, and configuring the flow owner without access to the destination Team or library.

Failure Handling and Operational Reliability

The Automation Failures list acts as a lightweight dead-letter queue. It records the source, flow, stage, record identifier, retry count, error summary, owner, and resolution status.

A separate recovery flow can process failure records marked Approved for Retry. It increments Retry Count and uses the existing Source Response ID or record ID. It must update the existing record rather than create a new one.

Power Automate run history is the fallback when the failure prevents writing to Microsoft Lists. The automation owner reviews failed runs daily and reconciles Form response IDs against case and test records weekly.

Rate limits and connector throttling are controlled by using filtered queries, indexed fields, limited result sets, and scheduled batches. The selected volume is modest, but flows should still avoid retrieving entire lists on every run.

A Complete Example

A warehouse supervisor submits an internal incident stating that the shipping-label service is unavailable and outbound staging is slowing. The supervisor selects process code SHIP-01, operational impact Degraded, and suggested severity High. Microsoft Forms records response ID 842.

1. The Forms trigger starts the intake flow and retrieves response 842.
2. The flow searches Source Response ID and finds no existing case.
3. It locates SHIP-01 in Critical Processes and retrieves the shipping process owner, alternate owner, four-hour process RTO, and dependency references.
4. The deterministic severity rule accepts High because service is degraded but shipping has not stopped. The acknowledgement deadline is set to 60 elapsed minutes after submission.
5. Power Automate creates Continuity Cases item 317.
6. The generated ticket ID is BC-202607-317.
7. The folder /SHIP-01/Incidents/2026/BC-202607-317 is created, and the submitted screenshot is copied into it.
8. The case is assigned to the IT service owner associated with the application dependency. The shipping process owner remains accountable and is copied on the Teams notification.
9. The Teams message includes the ticket ID, process, impact, acknowledgement deadline, description, case link, and evidence link.
10. The assigned owner acknowledges the incident after 38 minutes. Status changes from Assigned to In Progress, and the acknowledgement timestamp stops the SLA escalation.
11. The technical service is restored after 96 minutes, within the process RTO. The case moves to Resolved.
12. During validation, the process owner finds that the plan contains an outdated application-support contact. The coordinator creates action item 91, generating ACT-2026-91.
13. The action requires a plan update. The process owner approves the wording and contact change. Because no RTO, RPO, or dependency design changes, a second approval is not required.
14. The updated plan document is stored as a new version, the evidence link is attached to the action, and the process owner validates completion.
15. The action closes, followed by the incident case. The response ID, ticket ID, action ID, timestamps, approval response, and file links remain available for reporting.

If the first flow had run twice, the Source Response ID uniqueness control would have stopped the second ticket. If the process owner had been unavailable, the active delegation record would have routed the assignment to the alternate owner.

Implementation Cost

All amounts below are representative planning assumptions for this fictional scenario. They are not verified client results or published software prices.

An organization should not add the full internal implementation cost and the full professional implementation range unless both are genuinely incurred. Professional implementation usually replaces part of the internal build effort, although internal participation is still required.

Estimated Time and Cost Savings

The calculation uses 47 monthly workflow transactions, representing 12 cases, nine tests, and 26 recovery-action updates or closures.

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

47 × 28 ÷ 60 = 21.93 hours

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

47 × 8 ÷ 60 = 6.27 direct hours

47 × 10 percent × 15 ÷ 60 = 1.18 exception hours

6.27 + 1.18 + 4 maintenance hours = 11.45 hours

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

21.93 – 11.45 = 10.48 hours

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

10.48 × $55 = $576.40

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

$576.40 – $0 incremental software = $576.40

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

$6,600 ÷ $576.40 = approximately 11.5 months

If the implementation used a $12,000 professional-services assumption instead, the same simplified payback calculation would be approximately 20.8 months. These calculations exclude risk reduction, avoided disruption, and regulatory benefits because those values require business-specific evidence.

Recovered time does not automatically reduce payroll. It may provide additional capacity, quicker follow-up, reduced overtime, less administrative work, and the ability to manage more tests and actions without adding coordination effort at the same rate.

Non-financial benefits include clearer ownership, fewer follow-up emails, better test evidence, more consistent escalation, improved auditability, reduced dependence on one coordinator, and faster visibility into overdue recovery work.

Readers should replace the volume, handling time, exception rate, maintenance time, labour rate, licensing assumptions, and implementation cost with their own measured figures.

Adding AI to the Automation

AI is optional and should be introduced only after the rule-based workflow, data fields, permissions, and failure handling are reliable.

Potential uses include summarizing incident narratives, suggesting categories, identifying missing information, extracting proposed actions from test notes, comparing plan versions, and supporting semantic search across approved documents.

AI should not be used for fields that can be handled more reliably with required questions, lookup tables, exact process codes, date comparisons, thresholds, ownership mappings, or status rules.

The core automation already creates tickets, assigns owners, calculates deadlines, stores evidence, sends reminders, escalates overdue work, and records approvals. AI does not create those benefits. Its value is limited to interpreting unstructured text and producing suggestions for human review.

The Recommended AI Enhancement

The recommended enhancement analyzes incident and test narratives to produce a short summary, a suggested continuity category, a list of missing fields, and a routing suggestion. It does not replace the submitted severity, deterministic SLA rules, or owner approval.

• Trigger: A valid case or test record is created and AI Processing Allowed equals Yes.
• AI input: Ticket ID, process name, request type, impact selection, and sanitized narrative text.
• Expected output: Strict JSON containing summary, suggested category, suggested severity, missing fields, confidence, and a sensitive-data flag.
• Validation: Parse JSON, validate allowed values, and reject confidence outside zero to one.
• Record update: Store suggestions in separate AI fields without overwriting human-entered values.
• Human review: The continuity coordinator accepts or rejects the suggestion.
• Low confidence: Confidence below 0.75 enters Manual Review.
• Prohibited data: Attachments, credentials, health details, and unnecessary personal information are excluded.
• Failure behavior: Set AI Status to Failed and continue the core workflow.

Reusable system instruction

You support a business continuity coordinator.

Analyze only the supplied record. Do not infer facts that are not present. Do not make final incident severity, safety, legal, personnel, recovery authorization, or risk-acceptance decisions.

Return only JSON matching the supplied schema.

Allowed categories:
Application
Data
Facility
People
Supplier
Utility
Production Equipment
Communications
Other

Allowed suggested severity values:
Critical
High
Medium
Low
Unknown

The suggested severity is advisory. Human-selected severity and deterministic workflow rules remain authoritative.

Only identify missing fields from this list:
process
impact
observed_time
affected_dependency
workaround
owner
requested_outcome
evidence

If credentials, medical details, private personal information, or other prohibited data appear, set prohibited_data_detected to true. Do not repeat prohibited content in the summary.

Set confidence between 0 and 1. Use lower confidence when the narrative is ambiguous, contradictory, or incomplete.

Reusable user prompt

Ticket ID: {{TICKET_ID}}
Request type: {{REQUEST_TYPE}}
Critical process: {{PROCESS_NAME}}
Submitted impact: {{IMPACT}}
Submitted severity: {{SUBMITTED_SEVERITY}}
Narrative: {{SANITIZED_NARRATIVE}}

Return a concise factual summary, one suggested category, one advisory severity, missing fields, a routing suggestion, confidence, and the prohibited-data flag.

Structured JSON schema

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "summary": {
      "type": "string",
      "maxLength": 600
    },
    "suggested_category": {
      "type": "string",
      "enum": [
        "Application",
        "Data",
        "Facility",
        "People",
        "Supplier",
        "Utility",
        "Production Equipment",
        "Communications",
        "Other"
      ]
    },
    "suggested_severity": {
      "type": "string",
      "enum": [
        "Critical",
        "High",
        "Medium",
        "Low",
        "Unknown"
      ]
    },
    "missing_fields": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "process",
          "impact",
          "observed_time",
          "affected_dependency",
          "workaround",
          "owner",
          "requested_outcome",
          "evidence"
        ]
      },
      "uniqueItems": true
    },
    "routing_suggestion": {
      "type": "string",
      "maxLength": 200
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "prohibited_data_detected": {
      "type": "boolean"
    }
  },
  "required": [
    "summary",
    "suggested_category",
    "suggested_severity",
    "missing_fields",
    "routing_suggestion",
    "confidence",
    "prohibited_data_detected"
  ]
}

Power Automate AI configuration

Use an organization-approved AI connector or a governed custom connector. If Azure OpenAI is selected through an HTTP-based integration, the endpoint pattern is:

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

Authenticate using the organization’s approved Azure method. If an API key is required, store it in an approved secret-management mechanism and use secure inputs and outputs. Never place it in a Microsoft List, Teams message, or visible flow variable.

A representative request body is:

{
  "messages": [
    {
      "role": "system",
      "content": "YOUR_SYSTEM_INSTRUCTION"
    },
    {
      "role": "user",
      "content": "YOUR_RENDERED_USER_PROMPT"
    }
  ],
  "temperature": 0.1,
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "continuity_intake_analysis",
      "strict": true,
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "summary": {
            "type": "string"
          },
          "suggested_category": {
            "type": "string"
          },
          "suggested_severity": {
            "type": "string"
          },
          "missing_fields": {
            "type": "array",
            "items": {
              "type": "string"
            }
          },
          "routing_suggestion": {
            "type": "string"
          },
          "confidence": {
            "type": "number"
          },
          "prohibited_data_detected": {
            "type": "boolean"
          }
        },
        "required": [
          "summary",
          "suggested_category",
          "suggested_severity",
          "missing_fields",
          "routing_suggestion",
          "confidence",
          "prohibited_data_detected"
        ]
      }
    }
  }
}

The selected model and API version must support the requested structured-output feature. If they do not, request JSON-only output and validate it with Power Automate’s Parse JSON action before using any field.

After parsing, apply these conditions in order:

1. If prohibited_data_detected is true, store no generated summary and route the record to privacy review.
2. If confidence is below 0.75, set AI Status to Manual Review.
3. If the category or severity is outside the allowed values, set AI Status to Invalid Output.
4. If validation succeeds, write AI Summary, AI Suggested Category, AI Suggested Severity, AI Confidence, and AI Missing Fields.
5. Do not overwrite Severity, Owner, Approval Status, or final workflow decisions.
6. Log model deployment, processing time, token or usage data when available, outcome, and reviewer decision.

Benefits of the AI Enhancement

• Less time spent reading long incident narratives
• More consistent initial categorization of unstructured reports
• Quicker identification of missing process, impact, workaround, or evidence details
• Short summaries for Teams notifications and review queues
• Better analysis of recurring issue themes after human validation
• Faster preparation of test-result summaries

These benefits are specifically related to text interpretation. Ticket creation, ownership, reminders, escalation, document linking, approvals, and reporting continue to come from normal automation.

What Remains Rule-Based or Human-Controlled

• Final incident severity: A human confirms severity because it affects urgency and escalation.
• Safety response: Emergency and safety procedures must not depend on generated text.
• Recovery authorization: Process and technical owners decide whether to activate recovery procedures.
• RTO and RPO changes: Process owners and continuity governance approve changes to recovery objectives.
• Plan approval: Accountable owners approve controlled plan content.
• Risk acceptance: Authorized management decides whether to accept overdue or incomplete corrective work.
• Action closure: A human validator reviews completion evidence and effectiveness.
• Access decisions: Security and data owners control permissions.
• Legal and regulatory conclusions: Qualified specialists determine compliance obligations.

These decisions remain human-controlled because they can affect safety, operational risk, legal obligations, resource allocation, and accountability.

Estimating the Additional Value of AI

The AI estimate is deliberately conservative. It assumes only 21 of the 47 monthly transactions contain narratives long enough to benefit from summarization or classification.

Gross time reduction is 21 × 2.5 minutes = 52.5 minutes.

Correction effort is 21 × 15 percent × 2 minutes = 6.3 minutes.

Failure fallback is 21 × 5 percent × 4 minutes = 4.2 minutes.

Net additional capacity is 52.5 – 6.3 – 4.2 = 42 minutes, or 0.7 hours per month.

At $55 per hour, the additional labour value is $38.50. After the representative $15 usage allowance, estimated additional monthly value is $23.50.

At this volume, AI provides modest financial value. Its stronger justification may be consistency and faster review, subject to pilot evidence. It does not eliminate errors or human involvement.

Testing Checklist

Use fictional or sanitized sample data before processing real continuity information.

Ongoing Maintenance

The primary system owner is the continuity coordinator. The backup owner is the IT infrastructure manager. A Power Platform administrator owns connection health, environment controls, and flow administration.

Maintenance includes archiving old operational records, confirming backup procedures, updating notification templates, rotating credentials when applicable, monitoring connector changes, testing delegated ownership, reviewing storage use, and removing former employees.

Documentation should include list schemas, internal field names, flow diagrams, configuration values, owners, approval rules, test scripts, failure recovery, and deployment history.

When to Move to Dedicated Software

The Microsoft 365 implementation can remain appropriate while volumes, relationships, permissions, and reporting requirements are manageable. Replacement should be based on specific limitations rather than a general preference for a larger platform.

Signals that the implementation may have been outgrown include:

• Hundreds or thousands of critical processes, tests, or active actions
• Complex many-to-many dependency mapping across business units
• Formal regulatory evidence requiring specialized immutable audit records
• Advanced scenario modeling and impact analysis
• Multiple entities, locations, languages, or regulatory jurisdictions
• Frequent need for complex record-level permissions
• External supplier or customer portals
• Mobile or offline exercise requirements
• Integration with emergency notification, configuration, incident, risk, or asset platforms
• High exception rates caused by platform constraints
• Excessive flow maintenance or connector throttling
• Database or list performance concerns
• Need for formal vendor support and validated continuity-specific features
• Advanced analytics beyond operational list views
• Increasing security risk from numerous custom permissions and flows

Relevant upgrade categories include dedicated business continuity management systems, governance and risk platforms, enterprise service-management platforms, and custom applications backed by a relational database. A migration is not automatically necessary if the current system remains controlled, supportable, secure, and proportionate to the organization’s needs.

Implementation Checklist

• Confirm business continuity scope, priorities, volumes, and recovery terminology.
• Document current plans, tests, dependencies, evidence, and corrective-action processes.
• Select Microsoft Forms, Microsoft Lists, Power Automate, Teams, and document storage roles.
• Verify licensing and required connector features.
• Create administrative, coordinator, owner, reviewer, and test-user accounts.
• Establish least-privilege groups and permission boundaries.
• Create critical process, plan, dependency, case, test, action, contact, delegation, and failure records.
• Define unique IDs, indexes, choices, dates, relationships, and audit fields.
• Build authenticated incident, request, and test-result intake forms.
• Validate required fields, process codes, dates, impact, severity, and attachments.
• Document every source-to-destination field mapping.
• Build idempotent ticket, test, and action creation flows.
• Configure deterministic owner assignment and delegation.
• Configure sequential and parallel approvals where required.
• Set reminder timing, SLA thresholds, escalation levels, and unavailable-owner handling.
• Create evidence folders, naming rules, version control, retention, and missing-file recovery.
• Build operational, overdue, exception, rejected, completed, and failure views.
• Configure Teams notifications and fallback communication.
• Apply secure connection, credential, privacy, sharing, and retention controls.
• Add Try, Catch, Finally, retries, logging, and manual-recovery procedures.
• Test normal, duplicate, invalid, unavailable, rejected, overdue, failed, and unauthorized scenarios.
• Run user acceptance testing with realistic sample data.
• Pilot with a limited group of critical processes.
• Document deployment, support, rollback, and ownership.
• Replace representative cost and savings assumptions with measured internal figures.
• Add AI only after the core workflow is reliable and governed.
• Keep AI outputs advisory, validated, logged, and subject to human review.
• Assign primary and backup maintenance owners.
• Define volume, security, integration, audit, and complexity thresholds for future upgrades.