Digital Shift Handover with Microsoft Lists and Teams

The Business Situation

Alder Peak Components is a fictional 90-person manufacturer operating one production facility with six lines and three eight-hour shifts. The plant runs seven days per week, producing approximately 21 formal shift handovers each week, or 91 in an average month.

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 operations department owns the shift handover process. The people involved include outgoing and incoming shift leads, production supervisors, maintenance technicians, quality technicians, an environmental health and safety coordinator, and the operations manager.

The company already uses Microsoft 365. Microsoft Teams supports internal communication, while SharePoint stores controlled operational documents. Shift handovers, however, still depend on paper logbooks, verbal discussions, spreadsheets, and Teams message threads.

Each outgoing shift reports production performance, downtime, quality concerns, staffing gaps, safety items, material constraints, and open work. An average handover contains eight notable operational events and two or three follow-up actions.

The process needs to change because information cannot be reliably traced from the original event to its owner, supporting evidence, acknowledgment, escalation, and final resolution. Supervisors also have difficulty answering basic questions such as which actions are overdue, which handovers were acknowledged late, and whether a quality hold was communicated to the next shift.

The proposed system does not replace the plant’s emergency procedures, machine controls, maintenance management system, quality management system, or safety incident process. Urgent safety, environmental, and equipment events must still follow established immediate-response procedures. The handover system records and carries forward operational context after those procedures have been initiated.

The Existing Process

The original handover process follows this sequence:

1. Operators write machine issues, production counts, and quality observations in paper line logs during the shift.
2. Shift leads collect information from the line logs, verbal updates, maintenance conversations, and Teams messages near the end of the shift.
3. The outgoing lead writes a summary in a shared spreadsheet or sends a message to the incoming lead.
4. The two leads discuss the shift during a short face-to-face meeting.
5. Photographs, inspection sheets, and temporary work instructions remain in message threads, personal folders, or paper binders.
6. The incoming lead verbally accepts the handover. There is no consistent timestamp or acknowledgment record.
7. Open actions are copied into personal notes or a separate spreadsheet. Ownership and due dates are not always captured.
8. Supervisors follow up through messages and meetings. Closed actions are not consistently reconciled with the original event.

These issues have practical effects. Incoming leads spend time reconstructing events, supervisors repeatedly ask for status updates, quality staff search for evidence, and open work can cross several shifts without a clear owner. Dependence on individual memory also increases when an experienced shift lead is absent.

The messaging channel is useful for rapid collaboration, but it is not suitable as the system of record. Messages can be edited, deleted, buried by later discussion, or disconnected from the action that eventually resolves an issue.

What the New System Needed to Do

The implementation team defined the operating requirements before selecting the detailed design.

The design also needed to work on shared production terminals, tablets, and mobile devices. It had to retain familiar collaboration in Teams while keeping structured data in Microsoft Lists and documents in SharePoint.

Implementation Approaches Considered

Improving the existing manual process

A more structured paper or spreadsheet template would reduce variation, but it would not create dependable reminders, evidence links, acknowledgments, or status history. It was considered an interim fallback rather than the target design.

Using Microsoft Forms

Microsoft Forms was a credible option for a single submission at the end of each shift. Its mobile form experience is straightforward. The limitation is that a handover contains multiple related operational events and actions that need to be updated after submission. A submission-oriented form is less effective as a continuing operational workspace.

Using Microsoft Lists and Teams

Microsoft Lists provides editable records, filtered views, person fields, choices, attachments, version history, and SharePoint-backed storage. Teams can expose the lists as channel tabs and deliver notifications. Power Automate can validate records, create related actions, manage acknowledgments, and write status history.

Purchasing dedicated software

A dedicated electronic shift logbook, manufacturing execution system module, or quality management platform may become appropriate if Alder Peak Components requires equipment telemetry, electronic signatures subject to formal regulation, offline operation, or integration with many plants. The current scope does not yet justify replacing the existing Microsoft environment.

The Selected Solution

The selected implementation uses Microsoft Lists as the operational system of record, Microsoft Teams as the collaboration interface, Power Automate as the workflow layer, and SharePoint as both the underlying list platform and controlled document repository.

Microsoft Teams remains the place where employees notice and discuss work. Microsoft Lists becomes the source of truth for status, ownership, due dates, and acknowledgment evidence. This distinction prevents a Teams message from becoming the only record of an operational decision.

The implementation removes manual copying into a separate action spreadsheet, manual folder creation, routine reminder messages, and manual reconciliation of acknowledgment timestamps. Shift leads still enter operational facts, review the handover, correct missing information, and discuss significant risks directly.

Quality release, equipment restart, safety clearance, and acceptance of material risk remain human-controlled. The workflow records those decisions but does not make them.

System Architecture and Data Flow

• Intake: Microsoft Lists forms opened from Microsoft Teams on tablets, shared terminals, or mobile devices.
• System of record: SharePoint-backed Microsoft Lists for handovers, events, actions, history, and exceptions.
• Automation layer: Power Automate cloud flows using SharePoint, Teams, and Approvals connections.
• Document storage: A versioned SharePoint document library named Handover Evidence.
• Notifications: Microsoft Teams channel posts and approval notifications.
• Reporting: Filtered Microsoft Lists views and a SharePoint operational dashboard page.
• AI layer: Optional Azure OpenAI request that drafts a summary and always routes it to a shift lead for review.

1. Schedule creation: An operations supervisor creates or imports a Shift Schedule item. Power Automate validates the shift start, end, shift name, outgoing lead, and incoming lead. It creates one Shift Handover record using the schedule key. A unique constraint prevents a duplicate handover.
2. Handover preparation: The outgoing lead opens the pre-created handover from a Teams tab. Production, staffing, quality, and safety fields are completed during the shift.
3. Event intake: A lead or authorized technician creates an Operational Event linked to the handover. The event includes its category, line, severity, description, time, containment, and action requirement.
4. Event processing: Power Automate assigns an Event ID, creates the SharePoint evidence folder, copies list attachments, and stores the folder URL on the event.
5. Action creation: If the event requires follow-up, the flow creates an Open Action record with an owner, priority, due date, and link to the original event. The returned list item ID is written back to the event.
6. Notification: The automation posts a concise message to the Shift Handover Teams channel. Critical safety or quality flags also notify the designated duty role. If posting fails, the record remains valid and a notification exception is logged.
7. Submission validation: The outgoing lead changes the handover to Ready for Validation. Power Automate checks required fields, event ownership, missing due dates, quality holds, critical safety references, and unresolved automation failures.
8. Acknowledgment: If validation passes, Power Automate creates an approval assigned to the incoming shift lead. Approve means the handover was acknowledged. Reject means clarification is required. The approval identifier and response evidence are stored on the handover.
9. Escalation: The flow sends a reminder if acknowledgment remains pending after 10 minutes and escalates to the operations supervisor after 20 minutes. The exact timings are configuration values.
10. Closure and history: Once acknowledgment and any required quality or safety control confirmations are complete, the handover is closed. Open actions remain active until individually completed. Every material status change is written to the Status History list.

Each flow uses a Try scope for primary processing, a Catch scope configured to run after failure or timeout, and a Finally scope for the last-run timestamp. Catch writes a Flow Errors record, updates the source item to Automation Failed where possible, and notifies the operational support owner.

Data Structure

All operational lists are created on one SharePoint site dedicated to plant operations. Column names are initially created without spaces so their stable internal names are easy to use in Power Automate. Friendly display labels can be applied afterward.

Shift Handovers

Operational Events

Open Actions

Supporting lists

Shift Schedule

Stores the schedule key, start and end times, shift name, outgoing lead, incoming lead, backup lead, and supervisor.

Status History

Stores the record type, source item ID, record ID, previous status, new status, previous owner, new owner, changed by, changed at, change source, comments, and Power Automate run ID.

Flow Errors

Stores the flow name, run ID, source list, source item ID, error category, safe error message, retry count, recovery status, and assigned support owner.

Configuration

Stores non-secret settings such as Team ID, channel ID, evidence library name, acknowledgment timing, escalation timing, and time zone identifier.

Notification Log

Stores a unique notification key, message purpose, source record, channel, send status, timestamp, and returned message identifier when available.

The relationship is one Shift Schedule item to one Shift Handover, one Shift Handover to many Operational Events, and one Operational Event to zero or more Open Actions. Status History and Flow Errors reference source records by type and item ID rather than using many different lookup columns.

Indexes are added to HandoverKey, HandoverStatus, ShiftStart, IncomingLead, EventType, LineCode, HandoverItem, ActionStatus, Owner, DueAt, OverdueFlag, and AutomationStatus. Unique values are enforced on HandoverKey, HandoverID, EventID, ActionID, and ActionKey.

Workflow Statuses and Ownership

A clarification request sends the handover backward to Needs Information. A late acknowledgment can move an Escalated record to Acknowledged after the incoming lead responds, but the history retains the original escalation.

Critical actions cannot move directly from In Progress to Completed. They first enter Awaiting Verification. The designated verification owner confirms the evidence before Power Automate sets CompletedAt.

Cancellation requires a reason and an authorized supervisor. The original action is retained rather than deleted.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Create a dedicated SharePoint site for plant operations or select an existing site whose membership already matches the required access boundary.
2. Create a Microsoft Team named for plant operations, with a standard channel named Shift Handover. Add shift leads, supervisors, quality staff, maintenance coordinators, and the workflow support owner.
3. Confirm that the Microsoft 365 subscriptions and Power Automate entitlements support the SharePoint, Teams, and Approvals connector features used by the design. Licensing varies by tenant and should be verified before implementation.
4. Create a dedicated automation owner identity or approved non-personal flow ownership arrangement. It needs permission to edit the operational lists, create folders and files in the evidence library, post to the selected Teams channel, and create approvals. The identity must comply with the company’s identity, licensing, and multifactor authentication policies.
5. Add at least two human co-owners to each production flow so the automation is not dependent on one employee.
6. Create SharePoint groups for Handover Contributors, Handover Readers, Operations Supervisors, Quality Reviewers, and Automation Owners.
7. Grant contributors the minimum permission needed to create and edit operational records. Grant ordinary users read-only access to Status History, Flow Errors, and Notification Log. Only automation owners and designated administrators should edit those lists.
8. Create a development site or separate development lists with the same schema. Do not build and test directly against production records.
9. Create test identities representing an outgoing lead, incoming lead, quality reviewer, supervisor, and unauthorized employee.
10. Document the site URL, list names, Team ID, channel ID, evidence library name, time zone, escalation recipients, and flow owners.

Microsoft Lists uses SharePoint storage, so Power Automate connects to the lists through the SharePoint connector. Microsoft Teams and Approvals require separate authenticated connections.

Passwords, API keys, and connection secrets must not be stored in a Configuration list. Power Automate connection objects, approved secret storage, or an organization-managed vault should hold credentials.

Step 2: Build the Intake

Create the Shift Handovers and Operational Events lists as tabs in the Shift Handover Teams channel. This gives users one consistent entry point while retaining the SharePoint-backed records.

The Shift Handover record is pre-created from the Shift Schedule. The outgoing lead does not create a blank handover manually. This prevents duplicate records for the same scheduled transition.

The Operational Event form contains Event Type, Line Code, Event Start, Event End, Severity, Description, Immediate Containment, Action Required, Proposed Owner, Action Due At, Lot or Reference, and attachments.

Configure conditional form visibility where the tenant’s current Lists interface supports it. Show Immediate Containment when severity is High or Critical. Show owner and due date when Action Required is Yes. If conditional display is not available in the tenant interface, keep the fields visible and enforce the same rules in Power Automate.

Use required fields for facts that are always needed. Do not use AI to infer line number, event time, owner, due date, severity, or whether an action is required.

The form description should include a short privacy and safety notice:

Use this record for operational shift communication. Do not include medical details, disciplinary information, passwords, access codes, or information unrelated to plant operations. Follow emergency, safety, quality, and maintenance procedures before relying on this handover record.

Anonymous submission is disabled. Only authenticated members of the operations site can submit records. This provides basic spam prevention and captures the SharePoint Created By and Modified By identities.

Incomplete submissions remain Draft or receive Needs Information. The form confirmation text directs the user back to the handover view and explains that changing the status to Ready for Validation starts the acknowledgment workflow.

Step 3: Create the System of Record

1. Create the Shift Schedule, Shift Handovers, Operational Events, Open Actions, Status History, Flow Errors, Configuration, and Notification Log lists.
2. Create columns using stable names such as HandoverID, HandoverKey, HandoverStatus, EventID, ActionID, ActionKey, and AutomationStatus.
3. Enable version history on operational lists. Version history is required for reliable change detection with the SharePoint Get changes action.
4. Enforce unique values on HandoverKey, HandoverID, EventID, ActionID, ActionKey, and NotificationKey.
5. Add indexes before the lists accumulate substantial history. Prioritize fields used in filters and scheduled flows.
6. Set default handover status to Draft, acknowledgment status to Not Required, automation status to Pending, and retry count to zero.
7. Set default event processing status to Pending.
8. Set default action status to New, overdue flag to No, and reminder level to zero.
9. Configure lookup relationships from Operational Events to Shift Handovers and from Open Actions to both Shift Handovers and Operational Events.
10. Retain denormalized text identifiers such as HandoverID on child records. This makes exports, folder naming, and recovery easier if a lookup is unavailable.

The Shift Schedule key uses a deterministic value supplied by scheduling or created by the schedule flow. A suitable pattern is the shift start in UTC plus shift name, such as 20260715T140000Z-B. The Shift Handovers list enforces uniqueness on this key.

Create the following initial views:

• My Current Handover
• Drafts Near Shift End
• Awaiting Acknowledgment
• Escalated Handovers
• Quality Holds
• Critical Safety Carry-Forward
• Open Actions by Owner
• Overdue Actions
• Automation Failures
• Recently Closed Handovers

Do not use a calculated SharePoint column that depends on the current time for operational escalation. Current-time calculations can become stale. A scheduled Power Automate flow should update OverdueFlag and reminder levels.

Step 4: Connect the Tools

For every Power Automate flow, select the SharePoint site and list from the authenticated connection. Select the Team and channel using stable identifiers where the connector exposes them. Do not depend on message text to identify the source record. Every message includes the Handover ID or Action ID and a direct record link.

Use the SharePoint item numeric ID as the collision-resistant component of generated identifiers. The flow obtains this ID from the create trigger or Create item action, formats it, and writes the human-readable ID back to the same record.

When a destination action succeeds, store the returned identifier wherever the connector provides one. Examples include the created list item ID, approval ID, file item ID, and Teams message ID. If a Teams action does not expose a usable message identifier in the selected connector version, store the notification key, send timestamp, flow run ID, and source record link instead.

Step 5: Build the Core Automation

Flow 1: Provision the handover from the schedule

• Trigger: SharePoint item created in Shift Schedule.
• Conditions: ScheduleKey, ShiftStart, ShiftEnd, OutgoingLead, and IncomingLead are present. ShiftEnd is later than ShiftStart.
• Actions: Search Shift Handovers for HandoverKey. If none exists, create the handover, compose HandoverID, create its evidence folder, update the schedule, and write history.
• Fields updated: HandoverID, HandoverKey, ScheduleItem, leads, shift times, Draft status, evidence URL, and automation timestamps.
• Notification: No routine notification is required at creation. A view shows upcoming records.
• Exception: A duplicate key retrieves the existing record. Invalid schedule data creates a Flow Errors item and marks the schedule for manual review.

The exact action order is:

1. Initialize the flow run ID and source item ID.
2. Validate required schedule fields.
3. Compose the HandoverKey.
4. Use Get items with a filter on HandoverKey and a top count of one.
5. If a record exists, update the schedule with the existing handover item ID and end successfully.
6. If no record exists, create the Shift Handover.
7. Compose HandoverID using the returned item ID.
8. Update the handover with HandoverID.
9. Create the year, month, and handover evidence folders if they do not exist.
10. Update EvidenceFolderURL and AutomationStatus.
11. Update the schedule with the created handover item ID.
12. Create the initial Status History item.

Flow 2: Process a new operational event

• Trigger: SharePoint item created in Operational Events.
• Conditions: A parent handover exists and required event fields are valid.
• Actions: Generate EventID, calculate downtime, create an event folder, create an action if required, and post a Teams notification.
• Fields updated: EventID, HandoverID, DowntimeMinutes, EvidenceFolderURL, CreatedActionItemID, ProcessingStatus, and LastAutomationRun.
• Notification: Post to the Shift Handover channel. High and Critical events mention the appropriate duty role according to configuration.
• Exception: Invalid fields move the event to Manual Review. Partial completion is recorded so a recovery flow can resume without creating a duplicate action.

The event flow follows this order:

1. Set ProcessingStatus to Processing.
2. Retrieve the parent handover and verify that it is not Archived.
3. Compose EventID from the event creation date and list item ID.
4. Calculate DowntimeMinutes when both timestamps exist.
5. Validate conditional requirements.
6. Create or retrieve the event evidence folder.
7. Write EventID, HandoverID, downtime, and folder URL to the event.
8. If ActionRequired is Yes, compose a unique ActionKey from the event item ID.
9. Search Open Actions for the ActionKey.
10. Create the action only when no matching record exists.
11. Store the returned action item ID on the event.
12. Create a unique Notification Log item before posting to Teams.
13. Post the event notification and update the Notification Log to Sent.
14. Set ProcessingStatus to Complete.
15. Create a Status History entry.

Flow 3: Synchronize evidence attachments

• Trigger: Operational Event item created or modified.
• Conditions: The item has attachments and an EvidenceFolderURL.
• Actions: Retrieve attachment metadata, retrieve attachment content, compare against existing evidence files, and copy missing files.
• Fields updated: Evidence synchronization timestamp and processing notes.
• Notification: No routine message. Failed evidence synchronization appears in the exception view.
• Exception: Unsupported or oversized files remain attached to the list item and create a manual evidence task.

Use a unique file key containing the event item ID and attachment name. Do not overwrite an existing evidence file silently. A later replacement should create a new version or use an explicit version suffix.

Flow 4: Validate and submit the handover

• Trigger: Shift Handover item created or modified.
• Conditions: Get changes confirms HandoverStatus changed and the current value is Ready for Validation.
• Actions: Validate the parent, retrieve events and actions, calculate open counts, create acknowledgment approval, and start reminder branches.
• Fields updated: Validation results, OpenActionCount, AcknowledgmentStatus, ApprovalID, CurrentOwner, and HandoverStatus.
• Notification: Approval request to the incoming lead and a Teams channel notification.
• Exception: Missing data returns the record to Needs Information. Connector failure creates a Flow Errors item.

Validation checks include:

• ProductionStatus and HandoverSummary are present.
• StaffingNotes are present when staffing is reduced.
• SafetySummary is present when SafetyFlag is Yes.
• QualitySummary is present when QualityHold is Yes.
• Every action-required event has an owner and due date.
• Every High or Critical quality or safety event has containment information.
• No event is still in Processing or Failed status.
• The incoming lead has a valid internal email address.
• The incoming and outgoing lead are not the same person unless a supervisor has documented an exception.

If validation fails, build a concise list of missing items, write it to ValidationMessage, set HandoverStatus to Needs Information, assign CurrentOwner to the outgoing lead, and post a direct notification.

If validation passes, set AcknowledgmentStatus to Pending, HandoverStatus to Awaiting Acknowledgment, and CurrentOwner to the incoming lead. Create an approval before starting the wait and reminder branches.

Flow 5: Record status and owner changes

• Trigger: Item created or modified in Shift Handovers or Open Actions.
• Conditions: Get changes confirms that a monitored status or owner field changed.
• Actions: Create a Status History item containing previous and new values, actor, timestamp, record link, and flow run ID.
• Fields updated: Status History only.
• Notification: None unless a separate business rule requires it.
• Exception: A failed history write is logged and reconciled from version history.

Use the trigger window start token supplied by the SharePoint trigger as the Since value for Get changes for an item or file. Version history must be enabled. The flow exits immediately when monitored fields did not change, preventing update loops.

Step 6: Add Approvals, Reminders, and Escalations

The acknowledgment uses Power Automate Approvals. It is an operational acknowledgment, not authorization to release product, restart equipment, or accept a safety risk.

1. Use Create an approval with the first-response approval type.
2. Set the title to include the HandoverID, shift, and end time.
3. Assign it to the IncomingLead email. If that account is unavailable, use the documented BackupLead from Shift Schedule.
4. Include the reviewed summary, quality and safety flags, open action count, and direct handover link.
5. Store the returned ApprovalID on the handover.
6. Create parallel branches after approval creation.
7. In the first branch, use Wait for an approval and process the response.
8. In the second branch, delay for 10 minutes, retrieve the current handover, and send a reminder only if acknowledgment remains pending.
9. Delay for another 10 minutes, retrieve the record again, and escalate only if it remains pending.
10. Configure the wait action with a finite timeout appropriate to the plant’s policy. A representative value is one hour.

Map approval responses as follows:

If QualityHold is Yes, a quality confirmation follows incoming-lead acknowledgment. The quality reviewer confirms that containment and carry-forward controls are documented. If SafetyFlag is Yes for a Critical event, the EHS coordinator receives a separate confirmation. When both are required, the quality and EHS confirmations can run in parallel after the incoming lead acknowledgment.

A rejected control confirmation moves ControlReviewStatus to Escalated. It does not automatically clear the hold, restart equipment, or close a safety action.

The scheduled Open Action reminder flow runs every 30 minutes:

• Send an approaching-due reminder for High and Critical actions according to configuration.
• Set OverdueFlag to Yes when DueAt has passed and the action is not Completed or Cancelled.
• Send the first overdue reminder to the owner.
• Escalate an overdue High action to the supervisor after the configured interval.
• Escalate a Critical overdue action immediately according to plant policy.
• Increment ReminderLevel so the same notification tier is not repeated on every scheduled run.

Delegation is maintained in Shift Schedule and a small duty-role configuration list. Users should not forward an approval informally and assume the forwarded message changes accountability.

Step 7: Add Documents and File Management

Create a SharePoint document library named Handover Evidence. Enable version history and restrict external sharing.

Use this folder structure:

Handover Evidence
  /2026
    /07
      /SH-20260715-001842
        /EV-20260715-004921
        /EV-20260715-004936

The handover provisioning flow creates the year, month, and handover folders. The event-processing flow creates the event folder. Each operation first attempts to retrieve the expected folder. If it does not exist, the flow creates it. If creation returns a conflict because another run already created the folder, the flow retrieves the existing folder and continues.

Prefix copied files with the EventID. A suitable pattern is:

EV-20260715-004921_sensor-inspection.jpg
EV-20260715-004921_quarantine-tag.pdf

SharePoint list attachments remain available as the original submission evidence. The evidence synchronization flow copies them into the controlled document library. After successful copying and verification, the organization can decide whether to retain both copies or remove list attachments according to its records policy.

Do not enable silent overwrite. Use SharePoint versioning for replacement files or add a version suffix when the file represents a separate piece of evidence. Store the original attachment name and source event item ID as document library metadata.

Keep the evidence library permission model as simple as possible. If a class of document requires a materially different access boundary, use a separate restricted library rather than breaking permissions on thousands of individual folders.

Connector and tenant file-size limits can vary. Test representative large files before launch. If an upload exceeds the supported limit, retain the source reference, create a Flow Errors item, and route the document to the approved manual storage process.

Archive folders according to the company’s approved retention schedule. Do not delete evidence merely because the associated action was completed.

Step 8: Add Reporting and Operational Views

Create the main operational dashboard as a SharePoint page and add list web parts for the most important filtered views. Add the page as a Teams tab.

For processing-time reporting, Power Automate writes SubmittedAt, AcknowledgedAt, and ClosedAt. It calculates acknowledgment minutes and total processing minutes when the relevant status transition occurs. This avoids relying on a volatile current-time formula.

Volume reporting can group events by EventType, LineCode, Severity, ShiftName, and week. Downtime totals use DowntimeMinutes. Quality reporting can count quality events and holds, but the handover list should not replace the quality system’s official nonconformance metrics.

The operations analyst owns dashboard definitions. The workflow support owner verifies that scheduled updates and source views remain healthy. Alert thresholds are stored in Configuration rather than embedded in multiple flows.

Step 9: Add Security and Governance Controls

• Use least-privilege SharePoint and Teams membership.
• Restrict Flow Errors, Notification Log, Configuration, and Status History editing to automation owners.
• Do not store passwords, machine access codes, private medical information, or disciplinary details.
• Use person fields instead of manually typed email addresses where possible.
• Disable anonymous links and external sharing for the operations site and evidence library.
• Review Teams membership and SharePoint groups when employees change roles or leave the company.
• Retain version history and approval response evidence.
• Protect flow connections with organizational identity controls and multifactor authentication.
• Keep secrets out of flow names, Compose actions, error messages, Teams posts, and list columns.
• Use a documented retention schedule for handovers, evidence, history, and errors.
• Export or back up configuration and flow definitions according to the company’s recovery policy.
• Review connector activity and Power Automate run history during operational support.

Microsoft Lists does not provide a complete field-level security model for every scenario. If users must be prevented from viewing specific columns rather than simply instructed not to edit them, use separate restricted lists, a controlled application layer, or dedicated software.

AI is optional. If enabled, the AI flow receives only the structured operational text required to draft a summary. It must not receive medical information, disciplinary information, credentials, access codes, or evidence files unless a separately approved document-processing design exists.

Formal regulatory requirements, electronic signature controls, and records obligations must be reviewed by qualified internal personnel. An approval response in Power Automate should not be assumed to satisfy a regulated electronic signature requirement without that assessment.

Step 10: Deploy and Test

1. Build the lists, library, views, and flows in the development site.
2. Create at least three weeks of synthetic shift records covering all shifts and lines.
3. Use test users to exercise outgoing lead, incoming lead, quality, supervisor, and unauthorized roles.
4. Complete technical tests for each flow, including duplicate triggers and partial failures.
5. Run user acceptance testing with one supervisor, two shift leads, one quality technician, and the workflow support owner.
6. Correct field names, form layout, notification wording, and mobile usability issues found during testing.
7. Export or otherwise document the production-ready flow definitions and configuration.
8. Create production lists using the validated schema.
9. Update site, list, Team, channel, and library references for production.
10. Run a pilot on one production area or one shift for one week while retaining the approved fallback process.
11. Review missed events, false reminders, acknowledgment timing, and user questions daily during the pilot.
12. Expand to all shifts after pilot acceptance.
13. Provide a one-page operating guide and a separate administrator runbook.
14. Assign a support owner and backup owner before activation.
15. Keep a rollback plan that can pause flows, preserve records, and temporarily return to the controlled manual template.

Launch communication should explain which system is authoritative, how urgent issues are handled, what information is prohibited, how to request correction, and where staff can see failed automation records.

Code and Configuration

The core implementation does not require custom code. Microsoft Lists, SharePoint, Teams, Power Automate, and Approvals provide the required triggers and actions. Power Automate expressions are still needed for identifiers, dates, conditions, and paths.

Configuration values

These values can be stored in a restricted Configuration list or as environment values in a solution-aware Power Automate deployment. Do not store passwords or API keys in the list.

Identifier expressions

Place this expression in a Compose action after a Shift Handover item has been created. It uses the SharePoint list item ID to prevent collisions.

concat(
  'SH-',
  formatDateTime(triggerBody()?['Created'], 'yyyyMMdd'),
  '-',
  formatNumber(int(triggerBody()?['ID']), '000000')
)

When the item was created earlier in the same flow, replace triggerBody references with the output of the Create item action.

Use the same pattern for events and actions:

concat(
  'EV-',
  formatDateTime(triggerBody()?['Created'], 'yyyyMMdd'),
  '-',
  formatNumber(int(triggerBody()?['ID']), '000000')
)

concat(
  'AC-',
  formatDateTime(utcNow(), 'yyyyMMdd'),
  '-',
  formatNumber(int(outputs('Create_Action')?['body/ID']), '000000')
)

Idempotency keys

The primary action created from an event uses this deterministic key:

concat(
  'EVENT:',
  string(triggerBody()?['ID']),
  ':PRIMARY'
)

Configure ActionKey to enforce unique values. Before Create item, query for the key. If two flow runs still race, the unique constraint rejects one create operation. The Catch scope then retrieves the existing action and writes its item ID back to the event.

A notification key can use the record and message purpose:

concat(
  'EVENT:',
  string(triggerBody()?['ID']),
  ':CREATED-TEAMS'
)

Downtime calculation

After validating that EventEnd is present and later than EventStart, calculate whole downtime minutes with:

div(
  sub(
    ticks(triggerBody()?['EventEnd']),
    ticks(triggerBody()?['EventStart'])
  ),
  600000000
)

A negative result indicates invalid timestamps and must route to Manual Review rather than being stored.

Evidence folder path

concat(
  '/',
  outputs('Evidence_Library_Name'),
  '/',
  formatDateTime(triggerBody()?['Created'], 'yyyy'),
  '/',
  formatDateTime(triggerBody()?['Created'], 'MM'),
  '/',
  outputs('Handover_ID'),
  '/',
  outputs('Event_ID')
)

Create or confirm each parent folder before creating the event folder. Interface labels can vary between Power Automate versions, but the required action is the SharePoint operation that creates a folder under a selected site and library path.

Flow run identifier

Store the Power Automate run name in history and error records:

workflow()?['run']?['name']

Local timestamp display

Store operational dates as date-time values and use local conversion only for message presentation:

convertTimeZone(
  utcNow(),
  'UTC',
  outputs('Time_Zone_ID'),
  'yyyy-MM-dd HH:mm'
)

Try, Catch, and Finally configuration

1. Create a Scope named Try and place validation, retrieval, transformation, creation, and update actions inside it.
2. Create a Scope named Catch.
3. Configure Catch to run after Try has failed or timed out.
4. In Catch, create a Flow Errors item containing the flow name, run ID, source record, error category, retry count, and a safe summary.
5. Attempt to update the source record to AutomationStatus Failed.
6. Post a concise support notification that contains the record ID and run ID, not raw connector output.
7. Create a Scope named Finally.
8. Configure Finally to run after Try succeeds and after Catch completes.
9. Update LastAutomationRun where possible.

Configure transient SharePoint and Teams actions with an exponential retry policy. A representative configuration is up to four attempts with increasing delay. Do not retry validation errors, unique-key conflicts that can be resolved by lookup, or permission failures without investigation.

Testing the expressions

Create a synthetic handover and confirm that the generated identifier uses the expected date and six-digit item ID. Create an event with known start and end times and compare the calculated downtime with a manual calculation. Test folder creation twice to confirm the second run retrieves the existing folder rather than failing permanently.

Inspect Power Automate run history for trigger inputs, Compose outputs, SharePoint responses, condition results, and Catch execution. Column internal names may differ from display labels. If an expression returns null, inspect the trigger body and replace the property reference with the actual internal name shown in the run data.

Failure Handling and Operational Reliability

The Flow Errors list acts as a practical dead-letter queue. A dead-letter queue is a controlled holding area for records that automation could not finish. Each error has Open, Retrying, Recovered, or Closed status.

A manual recovery flow is triggered from a selected Flow Errors item. It retrieves the source record, checks for existing destination identifiers, increments RetryCount, and resumes only missing operations. It never assumes that a failed Power Automate action performed no work.

For example, a Teams post might succeed even if the following Notification Log update fails. Recovery first checks the notification record and source timestamps. If delivery cannot be verified, the replacement message is labeled as a recovery notification rather than pretending it is the original.

A nightly reconciliation flow checks for:

• Events with ActionRequired set to Yes but no matching ActionKey.
• Events with attachments but no synchronized evidence files.
• Handovers awaiting acknowledgment beyond the escalation threshold.
• Closed handovers with Pending control review.
• Actions marked Completed without required verification.
• Flow Errors marked Retrying for too long.

Staff identify failed records through the Automation Failures view, Teams support alerts, and Power Automate run monitoring. The operating guide explains how to open the source item, inspect the safe error message, and request reprocessing.

A Complete Example

On July 15, 2026, Alder Peak Components has a scheduled Shift B handover from outgoing lead Lena Ortiz to incoming lead Marcus Lee. The shift covers 2:00 p.m. to 10:00 p.m.

1. The Shift Schedule item is created with key 20260715T140000Z-B. Power Automate finds no existing handover with that key.
2. The flow creates Shift Handover list item 1842 and assigns SH-20260715-001842.
3. SharePoint folders are created under Handover Evidence/2026/07/SH-20260715-001842.
4. During the shift, Line L-04 stops for 18 minutes because a sensor produced an intermittent reading. Lena creates Operational Event item 4921.
5. The event input includes EventType Downtime, LineCode L-04, Severity High, the start and end times, a factual description, immediate containment, and ActionRequired Yes.
6. The flow calculates 18 downtime minutes and assigns EV-20260715-004921.
7. A related quality check identifies 120 units requiring quarantine pending inspection. The event includes the affected lot reference and links to the plant’s formal quality record.
8. The flow creates the event evidence folder and copies a sensor photograph and quarantine-tag PDF.
9. The event requires follow-up by quality technician Evan Brooks before 11:00 p.m. Power Automate creates Open Action item 731 with ID AC-20260715-000731.
10. The ActionKey is EVENT:4921:PRIMARY, preventing duplicate creation if the event flow is retried.
11. A Teams message posts the Event ID, line, severity, current containment, action owner, due time, and record link.
12. Near shift end, Lena completes ProductionStatus, identifies reduced staffing on Line L-02, marks QualityHold Yes, and writes the handover summary.
13. She changes HandoverStatus from Draft to Ready for Validation.
14. Power Automate retrieves eight related events and three open actions. It confirms that all required owners, due dates, quality references, and containment fields are present.
15. The handover moves to Awaiting Acknowledgment. An approval is assigned to Marcus Lee.
16. Marcus reviews the handover in Teams, opens the source record, and selects Approve with the comment that the quarantine location and inspection owner were confirmed.
17. The approval response identity, time, comments, and ApprovalID are stored. The handover moves to Acknowledged.
18. Because QualityHold is Yes, Evan receives a control confirmation request. He confirms that the quarantine and inspection plan are documented. This does not release the product.
19. The handover moves to Closed. The quality action remains In Progress until inspection evidence is added and an authorized quality reviewer verifies completion.
20. Status History contains the Draft, Ready for Validation, Awaiting Acknowledgment, Acknowledged, and Closed transitions, including actors and timestamps.

If Marcus had not responded within 10 minutes, the reminder branch would have sent a Teams reminder. After 20 minutes, the record would have moved to Escalated and the operations supervisor would have been notified. A later acknowledgment would still be recorded without removing the history of the delay.

Implementation Cost

All amounts below are representative assumptions in US dollars. They are not verified client results or published software prices. Actual licensing depends on the organization’s Microsoft agreements, connector requirements, storage needs, security architecture, and implementation scope.

Representative total economic implementation cost: $8,400 professional implementation plus $1,680 internal labour, for a total of $10,080.

The $60 recurring core software allowance is used in the savings calculation. Internal maintenance is included as labour in the new-process hours and is not subtracted a second time.

Estimated Time and Cost Savings

The following calculation uses representative assumptions rather than observed client results.

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

91 × 25 ÷ 60 = 37.92 hours

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

Base handling:
91 × 9 ÷ 60 = 13.65 hours

Exception handling:
91 × 10% × 6 ÷ 60 = 0.91 hours

Maintenance:
3.00 hours

Total new monthly labour:
13.65 + 0.91 + 3.00 = 17.56 hours

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

37.92 - 17.56 = 20.36 hours

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

20.36 × $42 = $855.12

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

$855.12 - $60 = $795.12

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

$10,080 ÷ $795.12 = 12.68 months

Recovered time does not automatically reduce payroll. It may create additional capacity for supervision, production support, quality follow-up, improvement work, or higher transaction volume. It may also reduce overtime and repeated administrative follow-up.

Non-financial benefits include clearer ownership, faster access to evidence, fewer incomplete handovers, more consistent escalation, better auditability, less dependence on individual memory, and improved reporting across shifts.

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

Adding AI to the Automation

AI is an optional enhancement added only after the structured workflow is operating reliably. The core benefits of unique records, validation, ownership, reminders, evidence folders, acknowledgments, history, and reporting come from normal automation rather than AI.

Potential AI applications include summarizing event descriptions, identifying missing narrative context, categorizing unstructured notes, comparing related shift summaries, and supporting semantic search across completed handovers.

AI should not replace required fields, choice lists, due-date validation, exact lot matching, threshold rules, permission checks, or workflow statuses. These tasks are more reliable when implemented with deterministic rules.

For Alder Peak Components, the most practical enhancement is a draft shift summary generated from structured handover and event data. The outgoing shift lead must review, edit, and approve the text before submission.

The Recommended AI Enhancement

The optional flow uses Azure OpenAI through a Power Automate HTTP action or an approved organizational connector. The deployment must support structured JSON output. The exact endpoint and API version should be copied from the organization’s Azure resource rather than guessed.

• Trigger: The outgoing lead changes AISummaryStatus to Draft Requested.
• AI input: Structured handover fields, event descriptions, containment, open actions, owners, due dates, and identifiers.
• Expected output: A factual summary, grouped operational concerns, missing-information list, source event IDs, and uncertain statements.
• Validation: Parse JSON, verify allowed event IDs, reject unknown fields, and require human review.
• Record update: Write the draft to AISummaryDraft and set AISummaryStatus to Human Review Required.
• Human review: The outgoing lead edits or approves the draft before selecting Ready for Validation.
• Low-confidence handling: Any uncertain statement, unknown event reference, malformed output, or missing required section prevents automatic use.
• Prohibited data: Medical details, disciplinary information, credentials, access codes, unrelated personal data, and uncontrolled evidence files.
• Logging: Store prompt version, deployment name, request time, response status, token usage when returned, and flow run ID.
• Failure behavior: Leave the existing human-authored summary unchanged and route the record to manual drafting.

Reusable system instruction

You draft manufacturing shift handover summaries from structured operational records.

Use only facts present in the supplied JSON. Do not infer root cause, product disposition, safety clearance, quality release, equipment readiness, employee intent, or regulatory conclusions.

Preserve event IDs, action IDs, line codes, owners, due dates, quantities, and status values exactly as supplied.

If information is missing, list it under missing_information. If a statement is ambiguous, place it under uncertain_statements instead of resolving it yourself.

Do not include medical details, disciplinary conclusions, passwords, access codes, or unrelated personal information.

Return valid JSON matching the supplied schema. Do not return Markdown or explanatory text outside the JSON.

Reusable user prompt

Create a concise shift handover draft from the following structured record.

The summary must cover:
1. Production status
2. Downtime and maintenance
3. Quality concerns and containment
4. Safety carry-forward items
5. Staffing constraints
6. Open actions with owners and due dates
7. Missing or uncertain information

HANDOVER_JSON:
{{HANDOVER_AND_EVENT_JSON}}

Structured output schema

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "summary": {
      "type": "string"
    },
    "production_status": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "downtime_and_maintenance": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "quality_items": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "safety_items": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "staffing_items": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "open_actions": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "action_id": {
            "type": "string"
          },
          "owner": {
            "type": "string"
          },
          "due_at": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        },
        "required": [
          "action_id",
          "owner",
          "due_at",
          "description"
        ]
      }
    },
    "source_event_ids": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "missing_information": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "uncertain_statements": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  },
  "required": [
    "summary",
    "production_status",
    "downtime_and_maintenance",
    "quality_items",
    "safety_items",
    "staffing_items",
    "open_actions",
    "source_event_ids",
    "missing_information",
    "uncertain_statements"
  ]
}

Power Automate AI configuration

1. Add optional fields AISummaryDraft, AISummaryStatus, AIReviewedBy, AIReviewedAt, AIPromptVersion, AIModelDeployment, AIRequestAt, AIInputTokenCount, AIOutputTokenCount, and AIErrorMessage to Shift Handovers.
2. Create a flow triggered when a Shift Handover item is modified.
3. Use Get changes and continue only when AISummaryStatus changed to Draft Requested.
4. Retrieve related Operational Events and Open Actions.
5. Use Select actions to construct a minimal JSON object. Exclude attachment content and prohibited fields.
6. Use Compose to serialize the input.
7. Send an authenticated POST request to YOUR_AZURE_OPENAI_CHAT_COMPLETIONS_ENDPOINT.
8. Place the API credential in an approved connection or secret store. Never embed it in the request body or Configuration list.
9. Set the Content-Type header to application/json and use the authentication header required by the configured Azure resource.
10. Request structured JSON output using a model deployment that supports the schema.
11. Parse the returned message content as JSON.
12. Confirm every source_event_id exists in the retrieved event set.
13. Confirm every action_id exists in the retrieved action set.
14. If validation passes, write AISummaryDraft and set Human Review Required.
15. If validation fails, set AISummaryStatus to Failed Validation and preserve the human-authored HandoverSummary.

A representative request body is:

{
  "messages": [
    {
      "role": "system",
      "content": "You draft manufacturing shift handover summaries from structured operational records. Use only supplied facts. Return valid JSON matching the required schema."
    },
    {
      "role": "user",
      "content": "Create a concise shift handover draft from this structured record: @{outputs('Compose_AI_Input')}"
    }
  ],
  "temperature": 0.1,
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "shift_handover_summary",
      "strict": true,
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "summary": {
            "type": "string"
          },
          "source_event_ids": {
            "type": "array",
            "items": {
              "type": "string"
            }
          },
          "missing_information": {
            "type": "array",
            "items": {
              "type": "string"
            }
          },
          "uncertain_statements": {
            "type": "array",
            "items": {
              "type": "string"
            }
          }
        },
        "required": [
          "summary",
          "source_event_ids",
          "missing_information",
          "uncertain_statements"
        ]
      }
    }
  }
}

The full production request should use the complete schema shown earlier. The shortened request above illustrates the Power Automate body structure.

Extract the response content with the dynamic content returned by the HTTP action. If an expression is required, inspect the actual response first. A common chat-completions response path is:

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

Convert the returned JSON string with the Power Automate json() expression and pass it to Parse JSON. If the deployment returns a different documented response format, update the extraction path to match that API response.

Test with synthetic handovers containing normal events, missing fields, contradictory descriptions, unknown event IDs, and prohibited information. Do not enable the production trigger until malformed output and service failure paths have been verified.

Benefits of the AI Enhancement

The AI enhancement reduces the time spent reading several event descriptions and assembling them into a short narrative. It can also produce more consistent grouping of production, downtime, quality, safety, staffing, and action information.

AI-specific benefits include:

• Less manual summary drafting.
• Faster consolidation of multiple event descriptions.
• Consistent grouping of unstructured notes.
• Visible missing-information and uncertainty lists.
• Improved search when approved summaries use consistent terminology.

These benefits are separate from the core automation. AI does not create the record IDs, assign owners, enforce due dates, manage approvals, create folders, send deterministic reminders, or maintain status history.

What Remains Rule-Based or Human-Controlled

These controls remain human because incorrect decisions can affect employee safety, product quality, equipment condition, and customer obligations. AI may organize facts but cannot assume accountability for operational decisions.

Estimating the Additional Value of AI

The AI estimate uses representative assumptions and does not claim that AI eliminates review or errors.

Gross drafting time avoided per record:
3.00 minutes

AI review:
1.50 minutes

Expected correction time:
15% × 2 minutes = 0.30 minutes

Expected failure fallback:
3% × 3 minutes = 0.09 minutes

Net additional minutes recovered per record:
3.00 - 1.50 - 0.30 - 0.09 = 1.11 minutes

Monthly additional capacity:
91 × 1.11 ÷ 60 = 1.68 hours

Monthly labour value:
1.68 × $42 = $70.56

Net additional monthly value after AI usage:
$70.56 - $20 = $50.56

This is a modest incremental benefit compared with the core workflow automation. The stronger justification may be summary consistency and easier review rather than labour savings alone.

Testing Checklist

Use synthetic sample data and test accounts before processing real operational information.

Ongoing Maintenance

The operations systems coordinator is the primary system owner. The operations supervisor is the backup business owner. A Microsoft 365 or automation administrator supports connections, permissions, and flow failures.

Credential rotation must follow organizational policy. When a connection owner leaves, transfer flow ownership and repair connections before deactivating the account.

Monitor list growth and archive according to retention policy. Verify that indexed views remain performant. Review evidence storage separately from list item count.

AI output sampling should compare approved summaries with source records. Record recurring correction themes and revise the prompt or source data structure. Do not train or fine-tune a model on operational information without a separate governance review.

When to Move to Dedicated Software

The Microsoft 365 implementation can remain appropriate while the workflow volume, permissions, and integration requirements are manageable. Replacement is not automatic merely because the process becomes important.

Signs that a dedicated electronic logbook, manufacturing execution system, computerized maintenance management system, quality management system, or custom application should be evaluated include:

• Multiple plants require centralized configuration and cross-site reporting.
• Transaction volume makes list views, reconciliation, or flow runs difficult to manage.
• Equipment telemetry must create events directly from production systems.
• Formal electronic signature or regulated audit requirements exceed the available controls.
• Users require offline operation in areas without reliable connectivity.
• Complex field-level permissions are required.
• Mobile barcode scanning, photographs, or specialized device integration become central.
• Customer or supplier portals are required.
• Workflow exceptions require extensive custom maintenance.
• Integration is needed with enterprise resource planning, maintenance, laboratory, warehouse, or manufacturing execution systems.
• Advanced genealogy, lot traceability, statistical process control, or quality disposition is required.
• Vendor-supported service levels become an operational requirement.
• Security risk increases because too many lists, flows, and item-level permissions must be maintained.

Before replacing the implementation, determine whether the need can be met by refining the data model, archiving older records, adding approved integrations, or moving the user interface to a controlled application while retaining the same SharePoint data.

Implementation Checklist

• Confirm the business scope and emergency-process boundaries.
• Document shift volume, event categories, roles, and escalation timing.
• Confirm Microsoft Lists, Teams, Power Automate, SharePoint, and Approvals entitlements.
• Create development and production sites.
• Assign primary and backup owners.
• Configure SharePoint and Teams permissions.
• Create the Shift Schedule list.
• Create the Shift Handovers list.
• Create the Operational Events list.
• Create the Open Actions list.
• Create Status History, Flow Errors, Configuration, and Notification Log.
• Enable versioning, indexes, and unique constraints.
• Build the mobile-accessible Lists forms.
• Add the lists and reporting page to Teams.
• Create the evidence library and folder conventions.
• Document field mappings between every source and destination.
• Build schedule provisioning and duplicate prevention.
• Build event processing and action creation.
• Build evidence synchronization.
• Build handover validation and acknowledgment.
• Build reminders, escalation, delegation, and timeout handling.
• Build status-history and reconciliation flows.
• Configure Teams notifications and notification logging.
• Apply Try, Catch, Finally, retry, and manual-recovery patterns.
• Create operational and failure-reporting views.
• Apply privacy, retention, credential, and sharing controls.
• Test normal, invalid, duplicate, failure, timeout, and recovery cases.
• Complete user acceptance testing with sample data.
• Pilot the workflow before plant-wide activation.
• Document one-time and recurring cost assumptions.
• Replace the representative savings assumptions with actual internal figures.
• Add AI only after the core automation is reliable.
• Require human review for every AI-generated summary.
• Assign ongoing maintenance and support ownership.
• Define the volume, security, integration, and regulatory criteria that would trigger a dedicated-software review.