Safety Incident Reporting and Corrective Action Automation

The Business Situation

This representative case study follows a 145-person precision components manufacturer operating two production sites. The business records approximately 35 safety events each month, including near misses, unsafe conditions, minor injuries, equipment-related events, and environmental concerns.

The Quality department owns the safety event process. Two site safety coordinators conduct triage, six Operations supervisors contribute to investigations, the Quality manager approves corrective action plans, and an HR safety liaison manages restricted injury information. An Operations director participates in approval and escalation for high-severity events.

Employees previously reported events through telephone calls, direct messages, email, and conversations with supervisors. A Quality coordinator copied available details into an Excel workbook and followed up for photographs, witness information, action owners, and completion evidence.

This process created delays at the point where speed mattered most. Quality could not rely on receiving immediate notice of a serious event, Operations could not see a consistent action queue, and HR sometimes received injury information after investigation work had already started.

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 business already used Microsoft 365, so the implementation retained that environment. The proposed system connected Microsoft Forms, Microsoft Lists, Power Automate, SharePoint, Microsoft 365 Approvals, and Outlook notifications. Optional AI summarization was considered only after the rule-based workflow was stable.

The Existing Process

The original process usually followed this sequence:

1. An employee reported an event to a supervisor by telephone, message, email, or conversation.
2. The supervisor decided whether to contact Quality immediately.
3. A Quality coordinator asked for the event time, location, people involved, injury details, photographs, and witness information.
4. The coordinator created or updated a row in a shared Excel workbook.
5. Photographs and documents were saved in email, chat, local folders, or a shared drive.
6. A safety coordinator assigned the investigation through email.
7. The investigator documented findings in a Word document or email thread.
8. Corrective actions were added to the spreadsheet, often as free text in a single cell.
9. Quality sent manual reminders to action owners.
10. The Quality manager reviewed the event and supporting evidence before marking the spreadsheet row closed.

These problems had practical consequences. Missing information delayed investigation, unclear ownership increased follow-up work, and disconnected files made it difficult to demonstrate why an event was closed. Restricted employee information was also harder to govern when it appeared in email threads and general-purpose folders.

The process depended heavily on one Quality coordinator knowing where records and messages were stored. When that employee was unavailable, other staff had difficulty reconstructing the current state of an investigation.

What the New System Needed to Do

The team documented the business and technical requirements before selecting the final design.

The form also needed to state that it was not a substitute for calling the site emergency number or initiating an emergency stop. A digital workflow can improve notification, but it must not delay immediate safety action.

Implementation Approaches Considered

Improved spreadsheet process

Standardizing the workbook and creating email templates would have reduced some variation, but it would not have provided reliable intake validation, controlled child action records, structured approvals, or dependable workflow monitoring.

Microsoft 365 workflow

This approach used services already familiar to employees. Microsoft Lists could represent incidents and corrective actions as related records, Power Automate could orchestrate routing and approvals, and SharePoint could retain evidence with version history and permissions.

No-code database

A no-code database could provide a strong user interface and relational structure. It was less suitable for this scenario because the business wanted to keep identity, documents, and sensitive records within its established Microsoft 365 governance boundary.

Dedicated safety software

A specialist safety platform would become appropriate if the manufacturer required broader environmental, health, audit, training, permit, inspection, and regulatory functions. For the current volume and scope, procurement and migration effort were difficult to justify without first proving the workflow requirements.

Custom application

A custom application offered the greatest flexibility but introduced unnecessary development and support responsibilities. The required workflow could be implemented with native Microsoft 365 components and standard connectors.

The Selected Solution

The selected design used a restricted SharePoint team site as the security and document boundary. Microsoft Lists provided the operational records within that site, while Power Automate connected the form, lists, approvals, files, and notifications.

The business retained Microsoft 365 identity, SharePoint, and Outlook. The shared Excel incident register was retired after migration and retained as a read-only historical file according to the organization’s retention policy.

Manual re-entry, routine routing emails, standard reminders, folder creation, and approval tracking were removed. Human staff continued to control severity confirmation, root-cause findings, regulatory classification, action-plan acceptance, injury decisions, and final closure.

System Architecture and Data Flow

The architecture separated intake, operational records, restricted injury details, action tracking, evidence, and workflow history. Power Automate acted as the orchestration layer rather than the permanent system of record.

1. Submission: An employee submits Microsoft Forms data. The trigger receives the response ID and form ID. Power Automate retrieves the full response and creates a submission key. If the key already exists, the flow records a duplicate event and stops without creating a second incident.
2. Incident creation: Power Automate validates required values and creates a Microsoft Lists item with the temporary status Intake Processing. SharePoint returns its numeric item ID.
3. Controlled identifier: The flow converts the SharePoint item ID into an incident identifier such as INC-2026-000418 and writes it back to the list.
4. Restricted injury record: If injury is reported, the flow writes employee and injury details to the restricted Injury Details list. The general incident record receives only an injury indicator and the restricted record ID.
5. Evidence folder: Power Automate creates a folder in the Safety Evidence library using the incident ID. Uploaded photographs are copied from the Forms upload location into the controlled folder.
6. Routing: The flow reads the location routing list, assigns the site safety coordinator, calculates the internal triage target, and stores the routing version used.
7. Alerting: Immediate danger, urgent medical attention, High, or Critical selections create an urgent Outlook alert. The alert does not make a final severity or regulatory determination.
8. Investigation: The assigned coordinator confirms severity, records investigation findings, and creates one Corrective Actions item for each required action.
9. Approval: The Quality manager reviews the investigation and action plan. High or Critical records then route to the Operations director and HR safety liaison when applicable.
10. Action tracking: A scheduled flow sends reminders, escalates overdue actions, and moves the incident to verification only when all required action records are complete.
11. Closure: Quality verifies evidence and submits the incident for closure approval. The flow records the approval response, closure date, and processing time.
12. Failure path: Any failed or timed-out stage updates AutomationStatus, increments RetryCount, records a concise error, and places the item in a manual-review view.

• Intake: Microsoft Forms group-owned safety event form.
• System of record: Microsoft Lists stored in a restricted SharePoint site.
• Automation layer: Power Automate cloud flows using standard Microsoft 365 connections.
• Document storage: A SharePoint Safety Evidence library organized by incident ID.
• Notifications: Outlook email and Microsoft 365 approval notifications.
• Reporting: Microsoft Lists views displayed on controlled SharePoint pages.
• AI layer: Optional tenant-approved Azure OpenAI deployment for draft summaries after redaction and human request.

Data Structure

The implementation used related lists instead of storing an investigation and all corrective actions in one record. The SharePoint numeric item ID served as the stable technical key. The formatted incident ID served as the business-facing identifier.

Safety Incidents list

Restricted Injury Details list

This list used separate list-level permissions. Only designated HR and Quality roles could access it.

Corrective Actions list

Supporting lists and relationships

• Routing Matrix: One active row per location containing the safety coordinator, backup coordinator, Operations manager, HR contact, and routing version.
• Workflow Log: One-to-many entries linked to an incident, with event type, timestamp, actor, flow run ID, approval ID, outcome, comments, and sanitized details.
• Safety Evidence library: One folder per incident with metadata for IncidentID, EvidenceType, Restricted, SourceFileID, and CapturedDate.

Indexes were added to IncidentID, ExternalSubmissionKey, Status, Owner, LocationCode, AutomationStatus, DueDate, and the incident lookup on child lists. Unique-value enforcement was enabled for ExternalSubmissionKey, IncidentID, ActionID, and the injury list’s incident relationship.

Workflow Statuses and Ownership

Automation could move a record only when required fields and child records met defined conditions. It could not confirm severity, determine root cause, decide regulatory reportability, accept a corrective action as effective, or approve final closure.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Create separate test and production SharePoint sites. Use a naming convention such as Safety Case Management - Test and Safety Case Management.
2. Confirm that the Microsoft 365 tenant provides the required Forms, SharePoint, Microsoft Lists, Power Automate, Outlook, and Approvals capabilities. Licensing and connector availability should be verified for the specific tenant rather than assumed from a plan name.
3. Create a group-owned Microsoft Form so ownership does not depend on one employee account. Restrict form ownership to the Safety System Owners group.
4. Create security groups for Safety System Owners, Safety Case Managers, Site Investigators, HR Restricted Reviewers, Action Owners, and Reporting Readers.
5. Give Safety System Owners full control over the site and flows. Give Safety Case Managers edit access to the incident, action, routing, log, and evidence resources.
6. Give HR Restricted Reviewers access to the injury list. Do not grant Site Investigators access to that list unless their job requires it.
7. Limit Routing Matrix editing to system owners. Investigators may read the active routing information but should not change assignment rules.
8. Create a shared mailbox or approved sender identity represented by YOUR_SAFETY_SHARED_MAILBOX. Grant only the automation connection and designated safety administrators permission to send from it.
9. Use organization-managed Power Automate connections. If tenant policy permits a dedicated automation account, protect it with multifactor authentication, conditional access, monitored ownership, and a documented backup owner.
10. Create two test users: one standard employee submitter and one site investigator. Create separate test approver accounts or use approved staff who understand that test notifications are not operational events.
11. Document production and test resource identifiers, including YOUR_FORM_ID, YOUR_SITE_URL, list names, library paths, and mailbox address. Store the document in an administrator-only location.

The flows should have at least two co-owners. Departing employees must not be the sole owners of forms, connections, or production flows.

Step 2: Build the Intake

Create a group-owned Microsoft Form named Safety Incident Report. Restrict responses to authenticated employees if responder identity and file upload are required. Configure the form so the employee’s identity is available to the flow.

Place a notice at the beginning of the form:

If there is immediate danger, injury requiring urgent assistance, fire, spill, or another emergency, follow the site emergency procedure first. Submitting this form does not replace calling the emergency contact, alerting a supervisor, or stopping unsafe work where authorized.

Place a privacy notice before the submit action. Explain who can access the report, why employee and injury information is collected, how long it is retained, and where employees can ask privacy questions.

Microsoft Forms does not trigger the flow until a response is submitted. An abandoned or incomplete form therefore creates no controlled record. Required fields reduce incomplete submissions, but employees still need an alternative reporting channel for accessibility, connectivity failure, or emergencies.

Duplicate prevention has two levels. The technical level uses the unique Forms response ID. The business level allows a safety coordinator to mark two distinct employee submissions as reports of the same event and link one to the retained incident.

For spam prevention, restrict the form to authenticated organization users. If external contractor reporting is required later, create a separate controlled intake with additional validation rather than weakening the employee form.

Submit one test response with a photograph. In the SharePoint document library associated with the group form, locate the actual upload path. It commonly follows a folder structure for Microsoft Forms, the form name, and the upload question, but the production flow should use the path observed in that tenant.

Step 3: Create the System of Record

1. Create the Safety Incidents list using simple initial column names such as IncidentID and ExternalSubmissionKey. This keeps SharePoint internal names predictable even if display names are changed later.
2. Disable list attachments. Evidence must be stored in the controlled library so file management follows one process.
3. Enable version history and configure retention according to the organization’s legal, regulatory, insurance, employment, and privacy requirements.
4. Set ExternalSubmissionKey to enforce unique values. SharePoint creates an index when unique-value enforcement is enabled.
5. Create the Restricted Injury Details list and remove inherited access that is not required. Grant access only to the approved Quality and HR groups.
6. Create Corrective Actions with a required lookup to Safety Incidents. Configure delete behavior to prevent accidental removal of a parent incident while child actions exist.
7. Create Workflow Log with a lookup to Safety Incidents. Users should not edit log entries after creation except through a documented administrator correction process.
8. Create Routing Matrix with one active row for each site. Add EffectiveFrom, EffectiveTo, and RoutingVersion so the system can retain which rule was applied.
9. Create the Safety Evidence library. Add metadata columns for IncidentID, EvidenceType, Restricted, SourceFileID, and CapturedDate.
10. Create indexes on fields used by flow filters and operational views.

The formatted incident ID cannot be generated until SharePoint returns the numeric list item ID. The intake flow therefore creates the item first and then updates it using this expression:

concat(
  'INC-',
  formatDateTime(utcNow(),'yyyy'),
  '-',
  padLeft(string(outputs('Create_incident')?['body/ID']),6,'0')
)

For corrective actions, create the action item first and use its list ID to produce a unique suffix:

concat(
  outputs('Get_incident')?['body/IncidentID'],
  '-A',
  padLeft(string(outputs('Create_corrective_action')?['body/ID']),2,'0')
)

Create filtered views for each major role. Views improve usability but are not security boundaries. Sensitive information must be protected with site, library, and list permissions.

Step 4: Connect the Tools

Connections use Microsoft 365 OAuth authentication managed by the tenant. Credentials are never placed in expressions, list columns, email bodies, or flow descriptions.

Step 5: Build the Core Automation

Automation 1: Form intake and controlled record creation

• Trigger: Microsoft Forms receives a new response.
• Conditions: Response ID exists, the site is allowed, required answers are present, and the submission key is not already stored.
• Actions: Get response details, validate values, create incident, generate incident ID, create restricted injury record when needed, create evidence folder, copy files, read routing, update status, send confirmation, and write the workflow log.
• Fields updated: IncidentID, FormsResponseID, owner, due dates, restricted record ID, evidence URL, status, routing version, and automation fields.
• Notification: Employee confirmation, owner assignment, and urgent role alerts when the rule is met.
• Exception: Set Manual Review, increment RetryCount, record a sanitized error, and alert the automation support owner.

The exact action order is:

1. Receive the Forms response ID.
2. Retrieve response details.
3. Compose ExternalSubmissionKey.
4. Query Safety Incidents for that key.
5. Terminate successfully if a completed incident already exists.
6. Validate site, date, severity, injury, and danger values.
7. Create the incident with Status = Intake Processing and AutomationStatus = Running.
8. Generate and save IncidentID.
9. Create the restricted injury item if required and save its returned ID.
10. Create the evidence folder.
11. Parse the uploaded-file array and copy each file.
12. Query Routing Matrix for one active matching row.
13. Assign the owner and calculate TriageDue.
14. Send urgent alerts if the deterministic alert condition is true.
15. Update IntakeComplete = Yes, Status = New, and AutomationStatus = Succeeded.
16. Create a Workflow Log entry and send the reporter confirmation.

Automation 2: Triage routing

• Trigger: A Safety Incidents item is created or modified with IntakeComplete set to Yes, Status equal to New, and TriageRouted equal to No.
• Conditions: Owner is populated and the routing row is active.
• Actions: Mark TriageRouted, notify the owner, and create a log entry.
• Fields updated: TriageRouted, LastAutomationRun, AutomationStatus.
• Notification: Assignment email containing the controlled incident link and internal target.
• Exception: Missing owner or routing rule sends the incident to Manual Review.

Automation 3: Investigation submission

• Trigger: Investigator sets SubmitActionPlan = Yes.
• Conditions: ConfirmedSeverity, investigation summary, owner, InvestigationDue, and regulatory assessment are complete. Required actions exist unless a no-action rationale is approved.
• Actions: Validate child actions, lock the draft submission fields, update status, and start action-plan approval.
• Fields updated: Status, ApprovalStatus, ApprovalRequestedDate, PlanVersion.
• Notification: Quality manager receives an approval request.
• Exception: Missing fields return the item to the investigator with a list of validation failures.

Automation 4: Corrective action monitoring

• Trigger: Corrective action created or modified, plus a daily scheduled flow.
• Conditions: Action has an owner, due date, valid status, and related incident.
• Actions: Generate ActionID, send assignment, schedule reminders, update escalation level, and aggregate child status.
• Fields updated: ActionID, LastReminderDate, EscalationLevel, parent incident status when all actions reach the required state.
• Notification: Assignment, upcoming due date, overdue notice, and manager escalation.
• Exception: An invalid owner or missing parent moves the action to the exception view.

Automation 5: Closure

• Trigger: Safety coordinator sets SubmitForClosure = Yes.
• Conditions: All required actions are Verified, regulatory review is complete, required evidence exists, and no unresolved exception remains.
• Actions: Start closure approval, capture response, update closure fields, calculate processing time, and write the log.
• Fields updated: ApprovalStatus, Status, ClosureDate, ProcessingTimeHours, LastAutomationRun.
• Notification: Investigator, action owners, reporter when appropriate, and Quality receive closure confirmation.
• Exception: Rejection returns the incident for information and preserves the approver’s comments.

Trigger conditions and processing flags prevent the flows from repeatedly responding to their own list updates. The unique submission key and unique action identifiers provide a second idempotency layer.

Step 6: Add Approvals, Reminders, and Escalations

The action-plan approval used a sequential and conditional structure:

1. The Quality manager receives the first approval.
2. If the Quality manager rejects it, the incident moves to Returned for Information. No later approval is created.
3. If the Quality manager approves a Low or Medium event with no injury, the action plan becomes approved.
4. If severity is High or Critical, the flow creates a second approval requiring responses from the Operations director and Quality manager’s designated senior backup where policy requires.
5. If injury information is involved, the HR safety liaison receives a parallel review focused on restricted employment and injury controls.
6. Only after all required human responses are approved does the incident move to Actions Open.

The final closure approval uses similar logic, but the approval details include verified actions, evidence links, investigation findings, and regulatory review state.

Unavailable approvers are handled through a maintained delegation record. If an approval has already been created for an unavailable person, the system owner cancels it, records the reason, updates the designated approver, and launches a replacement. The flow never treats elapsed time as approval.

Every approval writes the approval ID, assigned users, requested date, outcome, response date, and comments to Workflow Log. This preserves business evidence outside transient flow run history.

Step 7: Add Documents and File Management

Create a library named Safety Evidence. Use a folder for each incident:

Safety Evidence/
  INC-2026-000418/
    Intake/
    Investigation/
    Corrective Actions/
    Regulatory/
    Closure/

Power Automate creates the incident folder and the Intake subfolder during initial processing. Other folders may be created when the corresponding workflow stage starts.

Use filenames that preserve context while avoiding collisions:

INC-2026-000418_8f31a270_original-file-name.jpg

The eight-character value comes from a generated GUID. The original filename remains visible, but a second upload with the same name does not overwrite the first file.

After creating a file, update its library metadata with IncidentID, EvidenceType, Restricted, SourceFileID, and CapturedDate. Save the incident folder URL on the parent list item rather than placing multiple file links in a long text field.

Initial photographs marked as containing a person, injury, or uncertain content are treated as restricted. Access is reviewed before broader investigator sharing. SharePoint links must use organization-only or specific-person access, not anonymous sharing.

Enable version history. Replacing a document should create a new version when it is the same logical record. A materially different item should be uploaded as a new file. Investigators should not delete prior evidence to make a corrected document appear original.

File-size and file-type limits vary by tenant configuration and Microsoft service settings. Test the allowed formats and practical sizes before launch. The form should direct employees to contact Safety if an upload fails or a file exceeds the permitted limit.

Retention and disposition must follow the organization’s approved safety, employment, insurance, legal-hold, and privacy policies. Automation should not invent a retention period.

Step 8: Add Reporting and Operational Views

Place selected list views on a restricted SharePoint operations page. The views read live list data, so there is no separate refresh process. Monthly summaries can use grouped list views or an approved reporting tool later, but copied spreadsheets should not become a competing system of record.

Calculate processing time when an incident closes rather than relying on a dynamic calculated column using the current date. The closure flow stores a stable number of hours for reporting.

The dashboard owner is the Quality systems manager. Alert thresholds, severity definitions, and overdue periods require documented approval before they are changed.

Step 9: Add Security and Governance Controls

• Least privilege: Grant only the permissions required for each role. Do not make all supervisors site owners.
• Restricted injury data: Store detailed injury information in the separate restricted list and avoid copying it into general notifications.
• Notification minimization: Urgent emails should identify the incident, location, danger indicator, and controlled record link. They should not reproduce unnecessary medical details.
• Shared links: Disable anonymous sharing for the site. Use organization-only or specific-person links according to policy.
• Credential storage: Keep credentials in managed Power Automate connections. Never place secrets in list columns or flow variables.
• Flow ownership: Maintain two owners and record who can edit production flows.
• Audit evidence: Enable list and library versioning, retain Workflow Log entries, and preserve approval outcomes.
• Former employees: Remove site, group, mailbox, form, and flow access through the normal offboarding process.
• Backups and retention: Use Microsoft 365 retention and backup arrangements approved by the organization. Test restore procedures rather than assuming version history is a complete backup.
• Privacy: Collect the minimum necessary personal data and document access, purpose, retention, and data-subject handling requirements.
• AI restrictions: Do not send names, employee identifiers, medical descriptions, photographs, witness contact data, or regulatory conclusions to the optional AI service.
• Human control: Require qualified staff to confirm severity, findings, regulatory obligations, action effectiveness, and closure.

Regulatory reporting requirements vary by jurisdiction and event type. The workflow tracks a qualified human decision and deadline, but it is not a substitute for legal, safety, employment, or regulatory advice.

Step 10: Deploy and Test

1. Build the form, lists, library, views, and flows in the test site.
2. Use synthetic names and events. Do not use real injury or employee data during development.
3. Run normal, urgent, injury, duplicate, rejected, overdue, failed-file, and failed-approval scenarios.
4. Verify permissions by signing in as the standard submitter, investigator, Quality manager, HR reviewer, reporting reader, and unauthorized user.
5. Conduct user acceptance testing with one safety coordinator, one Operations supervisor, one HR reviewer, and the Quality manager.
6. Pilot the system at one site for two reporting cycles while retaining the old process only as a monitored contingency.
7. Reconcile every pilot form response against the Safety Incidents list and every attachment against the evidence library.
8. Correct defects in test, export or document the flow changes, obtain approval, and apply the controlled version to production.
9. Activate production flows in sequence: intake, routing, action monitoring, approvals, reminders, closure, and reporting.
10. Communicate the launch procedure, emergency warning, form location, owner responsibilities, and support contact.
11. Monitor every production run during the first week and review the failure queue daily during the initial month.
12. Keep a rollback plan that can disable flows, preserve received Forms responses, and temporarily route new reports to the safety shared mailbox without deleting records already created.

Implementation documentation should include the architecture, data dictionary, routing rules, flow inventory, permission matrix, test evidence, recovery procedure, and named primary and backup owners.

Code and Configuration

The core implementation does not require a conventional software application or standalone script. Microsoft Forms, SharePoint, Microsoft Lists, and Power Automate provide the required triggers and actions. The configuration below contains the expressions, schemas, conditions, and failure structure needed to reproduce the flows.

Power Automate interface labels can vary by tenant and product release. The important configuration is the trigger, condition, action, field mapping, returned identifier, and run-after behavior.

Submission key

Place this expression in a Compose action after the Forms trigger. If the tenant exposes Response Id only as dynamic content, insert that token in place of the final trigger expression.

concat(
  'FORMS:',
  'YOUR_FORM_ID',
  ':',
  string(triggerBody()?['responseId'])
)

Use the result in a SharePoint Get items filter against ExternalSubmissionKey. Because the generated value contains only a controlled prefix, form identifier, and response identifier, it can be safely used after normal connector encoding.

Incident ID

Place this in an Update item action immediately after Create item returns the SharePoint ID:

concat(
  'INC-',
  formatDateTime(utcNow(),'yyyy'),
  '-',
  padLeft(string(outputs('Create_incident')?['body/ID']),6,'0')
)

Urgent alert condition

Use a Condition after values have been normalized. Replace action names with the names used in the flow.

@or(
  equals(outputs('Normalized_ImmediateDanger'),'Yes'),
  equals(outputs('Normalized_MedicalAttention'),'Emergency Response'),
  equals(outputs('Normalized_PreliminarySeverity'),'High'),
  equals(outputs('Normalized_PreliminarySeverity'),'Critical')
)

This condition creates an alert. It does not confirm final severity or regulatory reportability.

Triage target expression

The following nested expression applies representative internal targets. The business should replace these durations with its approved operating policy.

if(
  equals(outputs('Normalized_PreliminarySeverity'),'Critical'),
  addHours(utcNow(),1),
  if(
    equals(outputs('Normalized_PreliminarySeverity'),'High'),
    addHours(utcNow(),4),
    if(
      equals(outputs('Normalized_PreliminarySeverity'),'Medium'),
      addHours(utcNow(),24),
      addHours(utcNow(),48)
    )
  )
)

Routing trigger condition

Add a trigger condition to the incident-created-or-modified flow so it does not respond to every update made by itself:

@and(
  equals(triggerOutputs()?['body/IntakeComplete'],true),
  equals(triggerOutputs()?['body/TriageRouted'],false),
  equals(triggerOutputs()?['body/Status/Value'],'New')
)

Inspect the trigger’s raw output during testing. Depending on column configuration, a choice value may be exposed as a direct string or as a value property. Adjust only the property path, not the condition’s logic.

Uploaded-file schema

The Forms file-upload answer is normally returned as a JSON array. Add Parse JSON using a sample response from the tenant. The following schema accepts the commonly returned fields while allowing optional values:

{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "name": {
        "type": "string"
      },
      "link": {
        "type": "string"
      },
      "id": {
        "type": "string"
      },
      "type": {
        "type": [
          "string",
          "null"
        ]
      },
      "size": {
        "type": [
          "integer",
          "null"
        ]
      },
      "referenceId": {
        "type": [
          "string",
          "null"
        ]
      },
      "driveId": {
        "type": [
          "string",
          "null"
        ]
      },
      "status": {
        "type": [
          "integer",
          "null"
        ]
      },
      "uploadSessionUrl": {
        "type": [
          "string",
          "null"
        ]
      }
    },
    "required": [
      "name",
      "link",
      "id"
    ]
  }
}

Inside Apply to each, build the source path using the exact upload location found during the test submission:

concat(
  '/Shared Documents/Apps/Microsoft Forms/Safety Incident Report/Photographs or supporting files/',
  item()?['name']
)

Generate the destination filename:

concat(
  variables('IncidentID'),
  '_',
  substring(guid(),0,8),
  '_',
  item()?['name']
)

Use SharePoint Get file content using path for the observed source path, then Create file in the incident’s Intake folder. Update the new file’s metadata using the returned file item identifier.

Processing-time calculation

When closure is approved, calculate elapsed hours from the SharePoint Created value:

div(
  sub(
    ticks(utcNow()),
    ticks(outputs('Get_incident_for_closure')?['body/Created'])
  ),
  36000000000
)

Approval evidence snapshot

Store a concise approval entry in Workflow Log. The exact approval output paths should be selected from the dynamic content returned by the tested approval action.

{
  "incidentId": "@{outputs('Get_incident')?['body/IncidentID']}",
  "approvalId": "@{outputs('Create_quality_approval')?['body/name']}",
  "approvalStage": "Action Plan",
  "outcome": "@{outputs('Wait_for_quality_approval')?['body/outcome']}",
  "responses": "@{string(outputs('Wait_for_quality_approval')?['body/responses'])}",
  "recordedAtUtc": "@{utcNow()}",
  "flowRunId": "@{workflow()?['run']?['name']}"
}

Try, catch, and final scopes

Each production flow uses three Power Automate scopes:

1. Try: Contains validation and business actions.
2. Catch: Configured to run after Try has failed, timed out, or been skipped due to an upstream failure. It updates AutomationStatus, RetryCount, ErrorMessage, and Workflow Log, then sends a support alert.
3. Finally: Runs after Try or Catch. It updates LastAutomationRun and records the flow run ID where an incident record exists.

Use exponential retry for safe read operations and transient notification actions where the connector supports it. Create operations require idempotency checks because an uncertain response could mean that the destination committed the record even though Power Automate did not receive confirmation.

To test the configuration, submit one test response for each severity, one with an injury, one with multiple files, and one repeated trigger event. Review the Power Automate run inputs and outputs, SharePoint version history, Workflow Log, list records, evidence metadata, emails, and approval responses.

Failure Handling and Operational Reliability

The Automation Failures view acts as a business-facing dead-letter queue. A dead-letter queue is a controlled collection of records that could not be processed automatically and require review or retry.

A Power Automate instant flow named Retry Failed Incident can use the For a selected item trigger. It should require AutomationStatus to be Failed or Manual Review, verify that RetryCount is below the approved limit, set Retry Requested, and invoke the same idempotent processing stages. It must not delete and recreate the incident.

Daily reconciliation compares the Forms response count with incident submission keys, identifies incidents stuck in Intake Processing, finds files without an IncidentID, and lists records whose LastAutomationRun is unexpectedly old.

A Complete Example

An employee at Plant 2 observes unusual movement in a machine guard on Press Line 3. The employee stops the equipment according to site procedure, informs the supervisor, and submits the safety form.

• Forms response ID: 762
• Event type: Unsafe Condition
• Immediate danger: Yes
• Injury: No
• Preliminary severity: High
• Files: guard-front.jpg and mounting-point.jpg

The Forms trigger passes response ID 762 to Power Automate. The flow retrieves the answers and creates this submission key:

FORMS:YOUR_FORM_ID:762

No matching key exists, so the flow validates the controlled values and creates Safety Incidents item 418 with status Intake Processing. SharePoint returns item ID 418, and the flow generates:

INC-2026-000418

Because Injury is No, no Restricted Injury Details item is created. The flow creates the SharePoint folder Safety Evidence/INC-2026-000418/Intake and copies the two photographs with incident-prefixed filenames.

The Routing Matrix returns the Plant 2 safety coordinator, backup coordinator, and Operations manager. The incident receives its owner and a four-hour internal triage target because the preliminary severity is High.

The urgent alert condition evaluates to true because ImmediateDanger is Yes and PreliminarySeverity is High. Outlook sends a controlled alert to the Plant 2 safety coordinator, Operations manager, Quality manager, and backup coordinator. The message contains the incident ID, location, immediate-danger indicator, and controlled SharePoint link. It does not contain injury or medical details.

The safety coordinator opens the record, confirms High severity, starts the investigation, and records that the machine remains isolated. After reviewing maintenance records and physical evidence, the investigator documents the observed mounting condition without relying on AI to determine fault or root cause.

Three corrective action records are created:

1. Inspect the affected guard assembly and replace damaged mounting hardware.
2. Inspect comparable presses for the same condition.
3. Update the preventive maintenance check to include documented guard-fastener verification.

Each action receives an owner, due date, and ActionID. The Quality manager approves the investigation and proposed plan. Because severity is High, the Operations director also approves the action plan. Regulatory review is set to No by an authorized reviewer, so the workflow records that decision without initiating an external reporting task.

When action owners mark work complete, they attach evidence to the incident folder. The safety coordinator verifies each action independently. One incomplete photograph is rejected and returned to the action owner, while the other actions remain complete.

After replacement evidence is uploaded, all three actions become Verified. The incident moves to Awaiting Closure Approval. The Quality manager reviews the evidence and approves closure.

Power Automate records the approval ID, approver, comments, response time, closure date, and processing hours. The final status becomes Closed. The incident, actions, approvals, files, routing information, and workflow history remain linked through INC-2026-000418.

Implementation Cost

All amounts below are representative planning assumptions, not verified client costs or Microsoft pricing. The business must confirm licensing, internal labour rates, storage requirements, and implementation scope.

The optional AI integration may require an approved Azure resource, a premium Power Automate capability, a custom connector, or another licensed integration method. Those costs must be confirmed within the specific Microsoft tenant and are not included in the core $35 recurring tool assumption.

Estimated Time and Cost Savings

The estimates below value administrative capacity. They do not assume a reduction in payroll and do not place a financial value on avoided injuries, compliance issues, or operational disruption.

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

35 × 48 ÷ 60 = 28.00 hours

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

(35 × 10 ÷ 60) + (35 × 10% × 12 ÷ 60) + 3
= 5.83 + 0.70 + 3.00
= 9.53 hours

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

28.00 - 9.53 = 18.47 hours

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

18.47 × $42 = $775.74

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

$775.74 - $35 = $740.74

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

$9,774 ÷ $740.74 = 13.2 months

Recovered time may provide additional investigation capacity, quicker response, reduced overtime, fewer administrative tasks, and lower dependency on one coordinator. It does not automatically reduce payroll expense.

Non-financial benefits include clearer ownership, fewer follow-up messages, faster urgent alerts, better separation of injury information, consistent action tracking, improved audit evidence, more reliable reporting, and a more predictable reporting experience for employees.

Readers should replace the following assumptions with their own figures:

• Monthly event volume and seasonal variation.
• Current intake, re-entry, filing, follow-up, and reporting time.
• Expected automation exception rate.
• Investigator and administrator labour rates.
• Microsoft licensing and storage costs.
• Implementation and testing effort.
• Maintenance time and support model.
• Approval delay and reminder frequency.

Adding AI to the Automation

AI is an optional enhancement added only after the core workflow, permissions, data validation, and failure handling operate reliably.

Normal automation already provides structured intake, unique records, deterministic urgent alerts, routing, reminders, approvals, evidence links, and reporting. None of those functions requires AI.

Potential AI uses include summarizing long narratives, suggesting an event category, identifying potentially missing information, comparing investigation documents, and supporting semantic search across approved summaries.

AI should not be used where a required field, exact match, lookup table, threshold, permission, or workflow rule provides a more reliable result. Immediate-danger alerts, due-date calculations, access control, status transitions, and duplicate response prevention remain rule-based.

The Recommended AI Enhancement

The recommended enhancement creates a draft summary from a redacted event narrative and identifies information the investigator may need to request. It does not determine root cause, blame, reportability, diagnosis, final severity, or closure.

• Trigger: An authorized coordinator sets AIReviewRequested to Yes after placing a redacted narrative in AIReadyNarrative.
• AI input: Incident ID, general event type, location code, immediate-danger indicator, injury indicator, preliminary severity, and redacted narrative.
• Prohibited data: Names, employee IDs, contact details, medical descriptions, photographs, witness identifiers, approval comments, legal advice, and regulatory submission content.
• Expected output: Draft summary, missing-information list, suggested category, suggested priority, rationale, and confidence score.
• Validation: Parse JSON, enforce allowed categories, check confidence range, and reject blank or oversized fields.
• Human review: Investigator accepts, edits, or rejects every draft.
• Low confidence: Confidence below 0.75 is labeled Low Confidence and cannot populate an approved summary.
• Failure behavior: Set AIStatus to Failed and continue the standard investigation process.

Reusable system instruction

You assist a qualified occupational safety investigator by summarizing supplied information.

Use only the facts in the input. Do not infer root cause, fault, intent, legal liability, regulatory reportability, medical diagnosis, final severity, or whether an incident should be closed.

Do not introduce names or identifying details. If information is missing, list the missing category rather than inventing an answer.

Return one valid JSON object only. Do not include Markdown or explanatory text outside the JSON.

Allowed suggested_event_type values:
Near Miss
Unsafe Condition
Injury
Equipment
Environmental
Other
Unclear

Allowed suggested_priority values:
Low
Medium
High
Critical
Unclear

The priority is a non-binding suggestion for human review. Immediate danger or emergency response should be highlighted, but the human reviewer makes the final decision.

Reusable user prompt

Incident ID: {{IncidentID}}
Location code: {{LocationCode}}
Reported event type: {{EventType}}
Immediate danger reported: {{ImmediateDanger}}
Injury reported: {{InjuryFlag}}
Preliminary severity: {{PreliminarySeverity}}

Redacted narrative:
{{AIReadyNarrative}}

Return:
1. A factual summary of no more than 80 words.
2. Missing information selected only from:
   event_time
   exact_location
   equipment_identifier
   immediate_controls
   witness_information
   sequence_of_events
   injury_indicator
   photo_or_evidence
3. A suggested event type.
4. A suggested priority.
5. A short rationale.
6. A confidence value from 0 to 1.

Expected structured output

{
  "summary": "An employee observed movement in a machine guard during operation and stopped the equipment. The area was isolated and a supervisor was notified. No injury was reported.",
  "missing_information": [
    "equipment_identifier",
    "witness_information"
  ],
  "suggested_event_type": "Unsafe Condition",
  "suggested_priority": "High",
  "rationale": "Immediate danger was reported and equipment was stopped pending review.",
  "confidence": 0.88
}

Parse JSON schema

{
  "type": "object",
  "properties": {
    "summary": {
      "type": "string"
    },
    "missing_information": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "event_time",
          "exact_location",
          "equipment_identifier",
          "immediate_controls",
          "witness_information",
          "sequence_of_events",
          "injury_indicator",
          "photo_or_evidence"
        ]
      }
    },
    "suggested_event_type": {
      "type": "string",
      "enum": [
        "Near Miss",
        "Unsafe Condition",
        "Injury",
        "Equipment",
        "Environmental",
        "Other",
        "Unclear"
      ]
    },
    "suggested_priority": {
      "type": "string",
      "enum": [
        "Low",
        "Medium",
        "High",
        "Critical",
        "Unclear"
      ]
    },
    "rationale": {
      "type": "string"
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    }
  },
  "required": [
    "summary",
    "missing_information",
    "suggested_event_type",
    "suggested_priority",
    "rationale",
    "confidence"
  ],
  "additionalProperties": false
}

If Azure OpenAI is used through an approved Power Automate HTTP or custom connector, configure the resource endpoint with placeholders rather than embedding credentials:

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

Headers:
Content-Type: application/json
api-key: stored in the managed connection, not in the flow body

The request body can be configured as follows. The active API version and model deployment must be taken from the organization’s Azure resource configuration.

{
  "messages": [
    {
      "role": "system",
      "content": "@{variables('AI_System_Instruction')}"
    },
    {
      "role": "user",
      "content": "@{variables('AI_User_Prompt')}"
    }
  ],
  "temperature": 0.1
}

Extract the returned content using the tested response shape for the deployed API version, then pass it to Parse JSON. A commonly used chat-completions content path is:

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

Save the draft in AIDraftSummary, not the approved investigation summary. Also save AIStatus, AIConfidence, AIPromptVersion, AIRequestID, AIRequestedDate, AIReviewedBy, and AIReviewedDate.

Log model deployment, prompt version, request identifier, response status, token usage when available, and estimated cost. Do not write the prohibited source data into Workflow Log.

Benefits of the AI Enhancement

• Reduces the time required to draft a concise summary from a long narrative.
• Applies a consistent summary structure across investigators.
• Highlights potentially missing information for follow-up.
• Provides a non-binding category and priority suggestion for human review.
• Supports reporting based on approved summaries rather than raw free text.
• Allows investigators to focus more time on evidence and corrective action quality.

These benefits are specific to interpreting unstructured text. Record creation, alerts, routing, approvals, reminders, document control, access restrictions, and failure recovery are benefits of the core automation and do not depend on AI.

What Remains Rule-Based or Human-Controlled

Estimating the Additional Value of AI

The following assumptions compare the original process, core automation, and optional AI enhancement.

Expected AI handling time per record
= 10 - 4 + 1 + (10% × 2) + (3% × 4)
= 7.32 minutes

Additional monthly hours recovered
= 35 × (10 - 7.32) ÷ 60
= 1.56 hours

Additional labour capacity value
= 1.56 × $42
= $65.52

Net additional monthly value
= $65.52 - $6
= $59.52

This estimate treats AI as a modest capacity improvement, not as a replacement for investigators. Actual correction and failure rates must be measured through reviewed production samples.

Testing Checklist

Use synthetic sample data before processing real employee, injury, or safety information.

Ongoing Maintenance

The Quality systems manager owns the business process. A Microsoft 365 administrator is the technical backup, and a second Quality employee owns operational continuity.

Flow edits should follow a controlled release process. Changes are built and tested outside production, reviewed by the business owner, documented with a version number, and monitored after deployment.

When to Move to Dedicated Software

The Microsoft 365 implementation may remain appropriate while event volume, permissions, workflow complexity, and reporting needs remain manageable. Replacement should be based on evidence rather than an assumption that every workflow requires a specialist platform.

Signs that the implementation may have been outgrown include:

• Transaction volume creates slow list queries, complex indexing, or excessive flow runs.
• Many locations require different legal rules, languages, forms, and approval paths.
• Employees need a full mobile application with offline reporting.
• Contractors or customers need a secure external reporting portal.
• Fine-grained record permissions become too difficult to administer safely.
• Formal regulatory submissions require certified interfaces or jurisdiction-specific content.
• Safety events must connect deeply with training, inspections, permits, equipment maintenance, occupational health, claims, or enterprise risk systems.
• Exception rates and manual repair effort continue to increase.
• Reporting requires advanced trend analysis, leading indicators, cross-site benchmarking, or formal audit packages.
• Vendor support commitments and validated release controls become mandatory.
• Security risk increases because too many users, unique permissions, flows, and document paths must be maintained manually.
• The business requires complex mobile evidence capture, offline synchronization, geolocation, or barcode scanning.

Relevant categories include environment, health, and safety management systems, quality management systems, governance and risk platforms, and industry-specific incident management applications. A move should include requirements validation, data migration planning, retention controls, integration design, and a comparison against the actual cost of maintaining the Microsoft 365 workflow.

Implementation Checklist

• Confirm business scope, event definitions, owners, severity levels, and regulatory responsibilities.
• Approve Microsoft Forms, Microsoft Lists, Power Automate, SharePoint, Outlook, and Approvals as the selected tools.
• Verify licenses, connectors, storage, retention, and tenant policies.
• Create test and production accounts, sites, forms, mailboxes, and security groups.
• Define least-privilege permissions and restricted injury access.
• Build the form with required fields, branching, emergency guidance, privacy notice, and upload controls.
• Create the Safety Incidents, Restricted Injury Details, Corrective Actions, Routing Matrix, and Workflow Log lists.
• Create the Safety Evidence library, metadata, folders, permissions, and versioning.
• Configure unique keys, indexes, relationships, statuses, defaults, and controlled choices.
• Document every source-to-destination field mapping.
• Build intake, routing, investigation, corrective action, approval, closure, reminder, and recovery flows.
• Add idempotency checks, trigger conditions, run-after scopes, logging, and retry limits.
• Configure human approval thresholds, sequential approvals, parallel reviews, rejection, and delegation.
• Configure reminders, escalations, overdue rules, and unavailable-approver handling.
• Create urgent, assignment, reminder, failure, and closure notifications.
• Create operational views for new, overdue, incomplete, rejected, regulatory, verification, and failed records.
• Confirm evidence naming, duplicate-file handling, version control, retention, and archiving.
• Review privacy, security, shared-link, audit, backup, and former-user controls.
• Validate all expressions, JSON schemas, connection references, and environment-specific identifiers.
• Run normal, exception, security, approval, file, retry, and reporting tests with sample data.
• Complete user acceptance testing and a phased pilot.
• Document activation, monitoring, rollback, support, and manual recovery procedures.
• Replace representative cost assumptions with confirmed licensing and labour figures.
• Replace representative savings assumptions with measured handling times and exception rates.
• Add AI only after the core workflow is reliable and governance approval is complete.
• Require redaction, structured output validation, human review, and AI cost monitoring.
• Name the primary system owner, technical backup, and business continuity owner.
• Define the volume, security, reporting, integration, and maintenance criteria that would justify dedicated software.