Building a Controlled SOP Library with SharePoint and Lists

The Business Situation

Harborline Precision Products is a fictional 85-person manufacturer with approximately 145 standard operating procedures, work instructions, quality procedures, and IT operating guides. Operations employs most of the workforce, while a six-person Quality team manages document control and a three-person IT team administers Microsoft 365.

The principal people involved in the process are a Quality Systems Coordinator, the Quality Manager, department process owners, the Operations Manager, the Microsoft 365 Administrator, and employees who need approved procedures while completing their work.

The company already uses Microsoft Teams and Microsoft 365, but its procedures are distributed across departmental shared folders, Teams file areas, individual work folders, and email attachments. An Excel register attempts to track each procedure’s owner, version, and review date. The register is not consistently updated when a file changes.

The Quality team handles approximately 48 controlled-document events each month. These include scheduled reviews, revision requests, new procedures, feedback submissions, approval cycles, and retirements. Employees also access procedures throughout the working day, so publishing the wrong version can affect training, production consistency, and audit preparation.

The immediate requirement was not simply to move files into a new folder. Harborline needed a controlled knowledge-management process that could identify the current document, assign ownership, initiate reviews, record approval evidence, restrict sensitive procedures, notify responsible people, and retire obsolete content without deleting its history.

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

The Existing Process

The original process followed a familiar but unreliable sequence:

1. An employee searched one or more shared folders for a procedure, often using file names rather than metadata.
2. If multiple copies existed, the employee compared file dates or asked a supervisor which copy was current.
3. A process owner edited a Word document and saved a new file with a name such as SOP Assembly Final v3 UPDATED.docx.
4. The owner emailed the file to the Quality Systems Coordinator.
5. The coordinator recorded the proposed version in an Excel register and emailed approvers.
6. Approvers returned comments in email, sometimes against different file copies.
7. The coordinator reconciled the comments, renamed the selected file, and moved it to a shared folder.
8. The coordinator manually updated the version, effective date, review date, and approval status in the spreadsheet.
9. Employees were notified through email or a Teams message, but there was no reliable record of who had been notified.
10. When a review became due, the coordinator filtered the spreadsheet and sent reminders manually.
11. Obsolete procedures were moved into archive folders, where they could still appear in search results or be restored without context.

The spreadsheet itself was not the principal problem. The larger issue was that files, ownership, approval evidence, notifications, and review work existed in disconnected systems. Updating one component did not reliably update the others.

What the New System Needed to Do

The implementation team defined the requirements before selecting the final architecture.

Implementation Approaches Considered

Improving the existing folders

Standardized names and a better spreadsheet could reduce confusion temporarily. It would not provide reliable event-driven tasks, automatic reminders, controlled publishing, or a durable relationship between an approval and a document version.

Google Sites and Drive

Google Sites could provide a portal while Drive provides file storage, permissions, and version history. Google Sheets and Apps Script could manage review dates and notifications. This was technically viable, but Harborline already used Microsoft identities, Teams, and Microsoft 365 administration. Adding another suite would increase account management, support, and migration work.

Notion

Notion could support searchable pages, owners, categories, dates, and linked databases. It was less suitable for Harborline’s controlled Word-document model, separate approval evidence, and requirement to retain established Microsoft access groups.

Dedicated document-management software

A dedicated document-management or quality-management platform would become attractive if the company needed regulated electronic signatures, formal training attestations, validated workflows, advanced audit controls, or multi-site quality processes. Those requirements were not assumed for this representative implementation.

Microsoft 365 approach

SharePoint and Microsoft Lists could provide the files, metadata, version history, search, and structured records. Power Automate could coordinate workflow events, approvals, reminders, evidence, and status changes. Teams could deliver operational notifications without becoming the authoritative record. This approach retained the company’s existing identity and collaboration environment.

The Selected Solution

The selected implementation used a SharePoint SOP site as the controlled knowledge area, Microsoft Lists as the workflow system of record, Power Automate as the automation layer, and Microsoft Teams as the notification channel.

The implementation retained Microsoft Teams and Microsoft 365 identities. It replaced the uncontrolled folder structure and spreadsheet register. Email was no longer used as the primary approval record.

Manual file renaming, reminder tracking, evidence-folder creation, task creation, and routine status updates were removed. Process owners and Quality staff still controlled document content, approval, rejection, access classification, effective dates, and retirement decisions.

System Architecture and Data Flow

The architecture separates content, workflow, and communication. SharePoint stores documents and evidence. Microsoft Lists stores structured operational records. Power Automate moves information between them. Teams tells people where action is required but does not replace the system of record.

1. An operational event is submitted. A user creates an item in the SOP Events list or submits feedback through the SOP Feedback list. The source record contains the event type, affected SOP, rationale, impact, requester, and requested date. Missing required information sends the item to Needs Information.
2. The event is checked for duplication. Power Automate uses a supplied source event ID when available. Otherwise, it composes a fingerprint from requester, SOP, event type, date, and normalized title. The key is written to a list column configured for unique values. A collision marks the later item as a probable duplicate instead of creating more work.
3. A permanent event number is assigned. The native SharePoint item ID is converted into an identifier such as EVT-2026-000284. The flow records the identifier, automation timestamp, and initial status.
4. Ownership and due dates are resolved. The flow reads the SOP Register and SOP Categories lists. It determines the process owner, quality approver, backup approver, review interval, risk class, and notification channel. Missing ownership routes the event to Quality triage.
5. An evidence folder is created. SharePoint receives a folder path based only on safe identifiers, such as SOP-OPS-0037/EVT-2026-000284. List attachments are copied into this folder. The folder URL is written back to the event.
6. A task is created. Microsoft Lists receives a task with a unique task key, assigned owner, due date, task type, and source event number. The returned SharePoint task item ID is stored on the event.
7. A Teams notification is posted. Power Automate posts a concise message containing the event number, SOP number, due date, owner, and a link to the task. If the post fails, the task remains valid and the notification failure is logged.
8. Approval is initiated when the document is ready. The selected route depends on event type, risk, and change class. Power Automate creates an approval and stores the returned approval ID. Responses update the task and event, while a JSON evidence file preserves the outcome, comments, responders, and timestamps.
9. The approved document is published. The file’s content approval state, business version, effective date, and next review date are updated. Employees with permission see the approved version through SharePoint search and the SOP portal.
10. Status history is maintained. A separate flow compares the current status with the stored previous status. Each transition creates an immutable history item with the record number, previous status, new status, actor, comment, timestamp, and flow run ID.
11. Scheduled monitoring creates future work. A daily flow locates reviews approaching their due dates. It creates one event for each review using a unique review key. Another flow checks overdue tasks, reminders, escalations, missing folders, and failed automations.

• Intake: Microsoft Lists forms for SOP events and reader feedback
• System of record: Microsoft Lists hosted on the controlled SharePoint site
• Automation layer: Power Automate cloud flows
• Document storage: SharePoint controlled-document libraries and an evidence library
• Notifications: Microsoft Teams channel messages and approval notifications
• Reporting: Microsoft Lists views and SharePoint operational pages
• AI layer: Optional Azure OpenAI classification and summarization with human confirmation

Data Structure

The design uses related SharePoint lists rather than placing every field on the document library. One SOP can have many events. One event can have many tasks, approval records, attachments, and status-history entries.

The document libraries also contain SOPNumber, CategoryCode, ProcessOwner, LifecycleStatus, ApprovalStatus, MajorVersion, MinorVersion, EffectiveDate, NextReviewDate, AccessClass, and Keywords. These columns improve search and allow the library metadata to be reconciled with the SOP Register.

Workflow Statuses and Ownership

A status can move backward when an approver requests changes, Quality discovers a missing document, or a publication check fails. Rejection requires an approver comment. Manual review is required for duplicate requests, missing owners, restricted access changes, critical-priority submissions, and automation errors that remain after configured retries.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Confirm tenant capabilities. Verify that the organization has access to SharePoint, Microsoft Lists, Microsoft Teams, Power Automate, the required standard connectors, and Power Automate approvals. Licensing and connector rights vary by tenant, so they should be confirmed before design work begins.
2. Create a non-production site. Build the lists, libraries, and flows in a separate SharePoint test site. Use test Teams channels and fictional documents until user acceptance testing is complete.
3. Create security groups. Establish groups for SOP Site Owners, Quality Editors, Process Owners, Company Readers, Department Readers, Restricted SOP Readers, and Automation Support. Use Microsoft Entra ID or Microsoft 365 groups according to the tenant’s identity policy.
4. Define permission boundaries. Site Owners administer configuration. Quality Editors maintain the register and publish content. Process Owners edit assigned drafts and complete tasks. Readers can view only approved documents in libraries permitted to their group.
5. Create automation ownership. Use an organizational automation identity or managed ownership model that will not disappear when an employee leaves. Assign at least two flow co-owners. The account requires only the SharePoint sites, lists, Teams channels, and approvals used by the process.
6. Prepare Teams. Create or select a team with an SOP Governance channel and appropriate department channels. The flow stores the target team and channel identifiers in configuration values rather than embedding them throughout each flow.
7. Prepare test users. Include one reader, one process owner, one Quality approver, one backup approver, one restricted reader, and one unauthorized user.
8. Configure data-loss prevention. Confirm that SharePoint, Teams, and the selected connectors are permitted to exchange this class of business data under the tenant’s Power Platform policies.
9. Document recovery ownership. The Quality Systems Coordinator owns business exceptions. The Microsoft 365 Administrator owns failed connections, permissions, flow suspensions, and service-level issues.

No credentials should be placed in list columns, flow descriptions, Teams messages, or document metadata. Connections are stored through Power Automate connection references. Optional API secrets should be kept in an approved secret-management service.

Step 2: Build the Intake

Create an SOP Events list and enable the standard list form. Create a separate SOP Feedback list with a shorter form for employees who only need to report a problem.

The feedback form requests the SOP number, feedback type, description, optional page or section reference, and optional attachment. Feedback types are Unclear, Outdated, Incorrect, Missing Step, and Improvement Suggestion.

The confirmation text should explain that submission does not change the approved SOP. Employees must continue using the current published version unless an authorized operational instruction states otherwise.

List forms can hide fields that are populated by automation. Business rules that cannot be reliably enforced in the form are checked in the validation flow. Incomplete submissions remain visible to the requester but do not create approvals.

Duplicate user submissions are handled in two ways. A supplied Source Event ID is treated as the strongest key. If none exists, the automation creates a normalized fingerprint. Attachments are not used in the fingerprint because file names and upload order are not reliable identifiers.

Step 3: Create the System of Record

1. Create the SharePoint site. Use a dedicated site such as Controlled Operations Knowledge. Keep site ownership limited to Quality and IT administrators.
2. Create access-separated libraries. Create Company Controlled SOPs, Department Controlled SOPs, and Restricted Controlled SOPs. This avoids large numbers of uniquely secured files and folders.
3. Configure versioning. Enable document version history, content approval, and major/minor version behavior appropriate to the organization’s policy. Restrict draft visibility to editors and approvers. Do not require checkout if the business needs Word co-authoring.
4. Create the evidence library. Create SOP Evidence with access limited to Quality, assigned process owners, approvers, and automation support. Readers do not need access to approval comments or supporting records.
5. Create the lists. Build SOP Categories, SOP Register, SOP Events, SOP Tasks, SOP Feedback, SOP Status History, SOP Event Keys, and Automation Errors.
6. Use machine-safe internal names. Create columns initially with names such as SOPNumber, EventStatus, and NextReviewDate. Display labels can be changed later without changing the internal names referenced by flows.
7. Configure unique values. Enforce uniqueness on SOPNumber, TaskKey, EventKey, HistoryKey, and any Source Event ID field that the business guarantees to be unique.
8. Add indexes. Index SOPNumber, LifecycleStatus, NextReviewDate, EventStatus, AssignedOwner, DueDate, TaskStatus, SourceEventID, and AutomationStatus. This supports filtered queries as the lists grow.
9. Enable list version history. Turn on version history for the operational lists. Status History remains the readable audit log, while native list history provides additional evidence of direct edits.
10. Create filtered views. Include Current SOPs, Reviews Due in 30 Days, Reviews Due in 90 Days, My Open Tasks, Awaiting Approval, Overdue, Missing Owner, Automation Failures, Untriaged Feedback, Retired, and Quarantined.

Configure VersionLabel as a calculated text column:

=CONCATENATE([MajorVersion],".",[MinorVersion])

Use separate number fields instead of asking users to type a version string. A major process revision increments MajorVersion and resets MinorVersion to zero. An editorial or approved minor change increments MinorVersion. A review with no content change does not change either number.

Do not use a calculated column containing TODAY() as the only overdue control. Such values may not refresh until an item changes. The scheduled monitoring flow should compare stored dates with the current UTC date and write an explicit review band or status.

Before migration, inventory all 145 legacy documents. Each file must be assigned an owner, category, version, access class, and disposition. Unknown or conflicting files enter Quarantined status and are not published. Migration is a document-control decision, not merely a bulk upload.

Step 4: Connect the Tools

All flows should be created inside a Power Platform solution where the organization’s governance model permits it. Use connection references and environment variables for the SharePoint site URL, list names, library names, team ID, channel IDs, and coordinator address.

Step 5: Build the Core Automation

Automation A: Validate and provision an operational event

• Trigger: A new item is created in SOP Events.
• Conditions: EventNumber is blank and AutomationStatus is not Complete.
• Actions: Mark Running, validate fields, create the duplicate key, assign the event number, resolve ownership, create the evidence folder, copy attachments, create the task, update the event, and post to Teams.
• Fields updated: EventNumber, DuplicateFingerprint, AssignedOwner, DueDate, EvidenceFolderUrl, EventStatus, AutomationStatus, LastAutomationRun, and CurrentTaskID.
• Notification: Post the task link to the configured channel and mention the owner only if the tenant’s Teams action supports the required identity mapping.
• Exception: Route missing configuration to Manual Review. Route technical failures to Automation Error.

The exact action order is important:

1. Update the source item to AutomationStatus = Running.
2. Check event type, title length, rationale, SOP requirement, category, risk, and requested date.
3. If validation fails, set EventStatus = Needs Information, add a reason, and stop successfully so the flow does not appear as a technical failure.
4. Compose the Source Event ID key or fallback fingerprint.
5. Create the key in SOP Event Keys. If the unique value already exists, retrieve the existing event, mark the new item Duplicate, record DuplicateOf, and stop.
6. Generate the event number from the native item ID.
7. Read the category and affected SOP records.
8. Calculate owner, due date, risk route, access class, and target Teams channel.
9. Create the evidence folder. If it already exists, verify that it belongs to the same event and continue.
10. Copy each list attachment into the evidence folder. Preserve the original attachment name but prepend the event number if a collision exists.
11. Create the task using a unique TaskKey.
12. Write the task ID and evidence URL to the event.
13. Set the event to Triaged and AutomationStatus to Complete.
14. Post the Teams message.

Automation B: Create scheduled review events

• Trigger: Daily recurrence during a low-usage period.
• Conditions: LifecycleStatus is Published and NextReviewDate is within 30 days.
• Actions: Compose a review key, create it in SOP Event Keys, create an SOP Event, and let Automation A provision it.
• Fields updated: SOP LifecycleStatus becomes Review Due when the review event is accepted.
• Notification: The process owner receives a Teams task notification.
• Exception: Missing owners or dates enter the Quality exception view.

The review key is based on SOP number and due date, such as REVIEW|SOP-OPS-0037|2027-07-11. This prevents the daily recurrence from creating the same review repeatedly.

Automation C: Convert feedback into triage work

• Trigger: A new SOP Feedback item is created.
• Conditions: SOP number and feedback description are present.
• Actions: Assign a feedback number, create an SOP Event of type Feedback, link both records, create the task and folder, and copy attachments.
• Fields updated: FeedbackStatus, LinkedEventNumber, AssignedTo, and AutomationStatus.
• Notification: Quality receives a triage message.
• Exception: Feedback for a retired or unknown SOP is sent to manual review.

Automation D: Maintain status history

• Trigger: An SOP Event or SOP Register item is created or modified.
• Conditions: Current status does not equal PreviousStatus.
• Actions: Create a unique history record, then update PreviousStatus on the source record.
• Fields updated: PreviousStatus and LastAutomationRun.
• Notification: None for normal transitions.
• Exception: A history-write failure creates an Automation Errors item and is detected by nightly reconciliation.

Direct status editing should be limited to authorized Quality users. When a manual override is necessary, the user must provide LastTransitionComment before changing the status. Native list version history provides an additional record of who made the edit.

Step 6: Add Approvals, Reminders, and Escalations

Use a split approval design rather than leaving one flow waiting for many days:

1. A flow detects a task with TaskStatus = Ready for Approval.
2. It validates that the document URL, proposed version, change class, and approvers are present.
3. It creates the first approval and stores the returned approval ID.
4. A separate approval-completion flow receives the outcome and finds the task by ExternalApprovalID.
5. If approved and another stage is required, it creates the next approval and replaces ExternalApprovalID with the new identifier while retaining the previous ID in evidence.
6. If all stages approve, it sets the event to Approved.
7. If the response is Changes Required, it returns ownership to the process owner and records the comments.
8. If rejected, it requires comments, sets the event to Rejected, closes open tasks, and records the evidence.

Configure approval responses such as Approve, Changes Required, and Reject where the tenant’s approval action supports custom responses. Interface labels can vary, so the implementation should map the actual returned outcome into those normalized values.

A daily reminder flow queries open tasks. It sends a first reminder after two calendar days, an escalation after four days, and places the item in the coordinator’s intervention queue after five days. LastReminderDate and EscalatedOn prevent repeated notifications on the same day.

Each category has a BackupApprover. The system does not silently substitute an approver because that could change the approval authority. If the main approver is unavailable, the Quality Systems Coordinator records the delegation, cancels or closes the original approval where supported, and launches a replacement approval. Both identifiers and the reason are retained.

Step 7: Add Documents and File Management

Controlled files and event evidence have different access and retention needs, so they are stored separately.

Controlled document conventions

• Use one current controlled file per SOP record.
• Name files with the SOP number, short title, and approved business version, such as SOP-OPS-0037_Final-Assembly-Torque_v3.1.docx.
• Store the permanent SharePoint FileUniqueID because a URL can change after a rename or move.
• Use SharePoint version history as the technical file history and VersionLabel as the approved business version.
• Do not include words such as final, newest, or updated unless they are part of a controlled naming convention.

Evidence structure

SOP Evidence/
  SOP-OPS-0037/
    EVT-2026-000284/
      EVT-2026-000284_original-request.docx
      EVT-2026-000284_owner-approval.json
      EVT-2026-000284_quality-approval.json
      EVT-2026-000284_publication-record.json

New SOP requests that do not yet have an SOP number use NEW/EventNumber. The folder remains stable after an SOP number is assigned, or it can be moved by an authorized migration flow that updates the recorded URL.

List attachments are copied to the evidence folder during provisioning. After the copy is verified, the event stores the destination file identifiers. The original list attachment can be retained according to policy or removed after an agreed retention period.

When an attachment has the same name as an existing evidence file, the automation compares file identifiers and does not overwrite silently. It either reuses the confirmed file or adds a sequence suffix. Failed uploads place the event in Automation Error without deleting successfully copied files.

Retired SOPs are not deleted. The register changes to Retired, the retirement date and reason are recorded, and the file is moved or reclassified into a restricted retired-document view. Normal portal pages filter out retired content. Retention periods and disposition should follow the company’s legal, quality, contractual, and regulatory obligations.

Step 8: Add Reporting and Operational Views

SharePoint pages and Microsoft Lists views provide the initial reporting layer. This avoids introducing another reporting platform before the team understands which metrics it actually uses.

The event flow records StartedAt and CompletedAt. On closure, Power Automate calculates DurationHours. Monthly reporting can show volume by event type, status, owner, category, result, and exception type. The first dashboard should use simple counts and averages. More advanced statistical reporting can be added later if management has a defined need.

Operational views update as list records change. SharePoint document search depends on indexing and is not guaranteed to update immediately after publication. The SOP portal should therefore include direct library views as well as search.

Step 9: Add Security and Governance Controls

• Least privilege: Give users only the site, library, list, and flow access required for their role.
• Access boundaries: Use separate libraries or sites for materially different audiences instead of creating hundreds of individual permission exceptions.
• Draft protection: Readers should see approved major versions, while drafts remain limited to editors and approvers.
• Register protection: The full SOP Register is restricted to governance users. Reader-facing pages expose approved library metadata instead of every administrative field.
• Evidence protection: Approval comments, investigation records, and source attachments remain in the restricted evidence library.
• Shared links: Disable anonymous or organization-wide links when they conflict with the SOP’s AccessClass.
• Credential storage: Use connection references and an approved secret store. Never place API keys in Compose actions visible to general flow editors.
• Activity evidence: Retain SharePoint version history, status history, approval evidence files, and Power Automate run identifiers.
• Former users: Disable accounts promptly, remove group membership, reassign owned SOPs, and transfer flow ownership.
• Retention: Define retention periods for current SOPs, retired SOPs, approval records, and failed submissions. Version history alone is not a backup strategy.
• Privacy: Intake forms should instruct users not to submit unnecessary personal, medical, disciplinary, credential, or customer information.
• AI restrictions: Optional AI processing must use an approved service and only the minimum required fields. AI never approves, publishes, or retires an SOP.

Organizations operating under formal regulatory or contractual frameworks should have Quality, legal, information-security, and records-management specialists validate the controls. This representative implementation does not assume that Microsoft 365 configuration alone satisfies a specific regulation.

Step 10: Deploy and Test

1. Build all components in the test site with test lists, libraries, channels, connection references, and fictional SOPs.
2. Create at least one sample record for every event type, access class, status, and approval route.
3. Complete technical testing for triggers, duplicates, retries, attachments, approvals, permissions, and status history.
4. Run user acceptance testing with the Quality Systems Coordinator, one process owner, one approver, one reader, and one restricted user.
5. Pilot the system with one department and approximately 15 to 20 SOPs.
6. Run the legacy register and the new review-date report in parallel during the pilot. Reconcile every due review.
7. Correct workflow assumptions, notification frequency, views, and access rules before broad migration.
8. Import approved legacy SOPs in controlled batches. Keep unknown or disputed files quarantined.
9. Activate production flows only after connection references, URLs, team IDs, and security groups have been verified.
10. Publish a short operating guide covering submission, review, approval, search, feedback, failure recovery, and escalation.
11. Assign launch support to Quality for process questions and IT for technical failures.
12. Retain an export of the legacy register and an inventory of source files for rollback and reconciliation.

Rollback means disabling production flows, preventing further publication, restoring the last approved operating procedure for document control, and reconciling any records created during the affected period. It should not mean deleting events or evidence.

Code and Configuration

The core implementation does not require a custom program. SharePoint, Microsoft Lists, Teams, Power Automate, and the Approvals connector provide the required triggers and actions. The following expressions and configuration values complete the native flow design.

Environment and connection configuration

Event trigger condition

Apply a trigger condition so the intake flow processes only records that do not yet have an event number. Confirm the actual internal field name in the trigger output.

@empty(triggerBody()?['EventNumber'])

Event number

After the SharePoint item is created, use its native ID to construct the business identifier:

concat(
  'EVT-',
  formatDateTime(triggerBody()?['Created'], 'yyyy'),
  '-',
  padLeft(string(triggerBody()?['ID']), 6, '0')
)

For item ID 284 created in 2026, the output is EVT-2026-000284.

Fallback duplicate fingerprint

Use SourceEventID when supplied. Otherwise, compose a bounded fingerprint from fields that should be equal for probable duplicates:

toLower(
  concat(
    triggerBody()?['Author']?['Email'],
    '|',
    coalesce(triggerBody()?['SOPNumber'], 'NEW'),
    '|',
    triggerBody()?['EventType']?['Value'],
    '|',
    formatDateTime(triggerBody()?['Created'], 'yyyy-MM-dd'),
    '|',
    substring(
      replace(trim(triggerBody()?['Title']), ' ', ''),
      0,
      if(
        greater(length(replace(trim(triggerBody()?['Title']), ' ', '')), 80),
        80,
        length(replace(trim(triggerBody()?['Title']), ' ', ''))
      )
    )
  )
)

Choice and person fields can appear differently depending on connector output and column configuration. Inspect a test run and adjust the property path while preserving the same transformation.

Evidence folder path

Use identifiers rather than the user-entered title so unsupported filename characters cannot enter the folder path:

concat(
  if(
    empty(triggerBody()?['SOPNumber']),
    'NEW',
    triggerBody()?['SOPNumber']
  ),
  '/',
  outputs('Compose_Event_Number')
)

Task key

concat(
  outputs('Compose_Event_Number'),
  '|',
  'INITIAL-REVIEW',
  '|01'
)

Configure TaskKey to enforce unique values. If Create Item fails because the key exists, the Catch branch should query the existing task by TaskKey and update the event with that task’s native ID.

Scheduled review filter

The recurrence flow can query published SOPs due within 30 days. Construct the date dynamically and use the actual internal choice-field representation expected by the SharePoint connector.

LifecycleStatus eq 'Published' and NextReviewDate le '@{formatDateTime(addDays(utcNow(),30),'yyyy-MM-dd')}'

For each result, create this unique review key:

concat(
  'REVIEW|',
  items('Apply_to_each_SOP')?['SOPNumber'],
  '|',
  formatDateTime(items('Apply_to_each_SOP')?['NextReviewDate'], 'yyyy-MM-dd')
)

Next review date

After approved publication or review, calculate the next review date from the interval stored on the SOP record:

addToTime(
  outputs('Approved_Effective_Date'),
  int(outputs('Review_Interval_Months')),
  'Month'
)

Status-history trigger

For a Choice column returned as a string, use:

@not(
  equals(
    triggerBody()?['EventStatus'],
    triggerBody()?['PreviousStatus']
  )
)

The history key can combine the record number and current UTC ticks:

concat(
  triggerBody()?['EventNumber'],
  '|STATUS|',
  string(ticks(utcNow()))
)

Create the history record before updating PreviousStatus. If history creation fails, leave PreviousStatus unchanged so reconciliation can detect the mismatch.

Duration calculation

div(
  sub(
    ticks(outputs('Completed_UTC')),
    ticks(outputs('Started_UTC'))
  ),
  36000000000
)

The output is whole hours. Store minutes separately if the business needs finer reporting.

Teams notification format

SOP action required

Event: @{outputs('Compose_Event_Number')}
SOP: @{coalesce(triggerBody()?['SOPNumber'],'New SOP')}
Type: @{triggerBody()?['EventType']}
Owner: @{outputs('Owner_Display_Name')}
Due: @{formatDateTime(outputs('Due_Date'),'yyyy-MM-dd')}
Status: Triaged
Open task: @{outputs('Task_Link')}

Do not put restricted procedure content or approval comments in a broad Teams channel. Post only the minimum metadata and a permission-controlled SharePoint link.

Approval evidence object

After each approval response, create a JSON file in the event evidence folder. Map dynamic values from the approval-completion trigger into this structure:

{
  "eventNumber": "EVT-2026-000284",
  "taskKey": "EVT-2026-000284|QUALITY-APPROVAL|02",
  "approvalId": "RETURNED_APPROVAL_ID",
  "approvalStage": "Quality",
  "outcome": "Approve",
  "responders": [
    {
      "email": "APPROVER_EMAIL",
      "response": "Approve",
      "comments": "APPROVER_COMMENTS",
      "completedUtc": "2026-07-11T14:25:00Z"
    }
  ],
  "flowRunId": "POWER_AUTOMATE_RUN_ID",
  "recordedUtc": "2026-07-11T14:26:00Z"
}

Try, Catch, and Finally scopes

1. Place business actions inside a scope named Try.
2. Create a Catch scope configured to run after Try has failed or timed out.
3. In Catch, update the source record to Automation Error, increment RetryCount, write a sanitized error summary, and create an Automation Errors item.
4. Create a Finally scope that runs after successful or failed completion and writes LastAutomationRun where possible.
5. Configure exponential retry for SharePoint and Teams actions that can fail temporarily. Use a conservative retry count and interval that match tenant policies and expected service limits.
6. Do not retry business validation failures. Those records should finish in Needs Information or Manual Review.

Test every expression with sample records and inspect the Power Automate run history. The most common setup errors are incorrect internal column names, Choice fields returning an unexpected shape, person fields without an email address, missing library permissions, and malformed OData filters.

Failure Handling and Operational Reliability

Idempotency means that repeating the same technical operation produces the same business result instead of duplicate records. This implementation uses unique event keys, task keys, history keys, approval IDs, and deterministic folder paths to support idempotent recovery.

A nightly reconciliation flow checks for:

• Events in Running status longer than one hour
• Triaged events without a task
• Events without evidence folders
• Approvals without matching tasks
• Published SOPs without file IDs or review dates
• Current and previous statuses that do not match
• Open review events for retired SOPs
• Errors marked resolved while their source records still show Failed

Every unresolved discrepancy creates or updates an Automation Errors item. Staff recover records through a controlled retry flow that first reads existing identifiers. They do not simply resubmit the original request.

A Complete Example

On July 8, 2026, an Assembly Supervisor submits a revision request for SOP-OPS-0037, Final Assembly Torque Verification.

• Event Type: Revision
• Change Class: Major Process
• Risk Level: Quality
• Rationale: Add torque-wrench verification before the final assembly inspection.
• Source Event ID: NCR-2026-0118
• Attachment: Proposed process-change summary

1. Microsoft Lists creates native item 284 in SOP Events.
2. Power Automate validates that the SOP exists, the rationale is present, the source event is supplied, and the requested category is active.
3. The flow creates the unique key SOURCE|NCR-2026-0118. No existing key is found.
4. The flow assigns EVT-2026-000284.
5. The SOP Register identifies the Assembly Process Owner, Quality Manager, 12-month review interval, Department access class, and Operations Teams channel.
6. SharePoint creates SOP-OPS-0037/EVT-2026-000284 in SOP Evidence. The submitted attachment is copied into the folder.
7. Microsoft Lists creates task TSK-000491 with TaskKey EVT-2026-000284|INITIAL-REVIEW|01. The task is assigned to the Assembly Process Owner.
8. Teams receives a message containing the event number, due date, and task link.
9. The process owner updates the controlled draft, sets the proposed version to 4.0, and marks the task Ready for Approval.
10. Power Automate creates the process-owner approval and stores its returned approval ID.
11. The owner approves. A JSON evidence file is written to the event folder.
12. Because this is a major process change, the flow creates a final approval requiring both the Quality Manager and Operations Manager.
13. The Quality Manager requests a clarification about calibration frequency. The event moves to Changes Required, and the task returns to the process owner.
14. The process owner updates the draft and resubmits. The approval sequence restarts with new approval IDs, while the original responses remain in evidence.
15. Both final approvers approve on July 11, 2026.
16. The flow sets the controlled file to approved, updates MajorVersion to 4 and MinorVersion to 0, records the effective date, and sets NextReviewDate to July 11, 2027.
17. The SOP Register changes to Published, the task changes to Completed, and the event changes to Closed.
18. SharePoint search and the department SOP page expose the approved document to permitted readers after indexing. Drafts and approval evidence remain restricted.

If the document publication action had failed after approval, the event would have remained Approved or entered Automation Error. It would not have been marked Published until the file state, metadata, and register had been reconciled.

Implementation Cost

The following amounts are representative planning assumptions, not vendor quotations or verified client costs. Microsoft licensing, storage, connector rights, implementation rates, and internal labour costs vary by tenant and organization.

The estimate assumes the company already operates Microsoft 365. It does not assert that every required feature is included in a particular subscription. The organization must confirm Power Automate, approvals, storage, premium connector, and optional AI licensing requirements in its own tenant.

Estimated Time and Cost Savings

The representative calculation uses these assumptions:

• 48 SOP workflow events per month
• 42 minutes of current administrative handling per event
• 11 minutes of handling after core automation
• 15 percent exception rate
• 18 minutes of additional work for each exception
• 2 hours of system maintenance per month
• $44 loaded hourly labour cost
• $90 recurring monthly software and storage allocation
• $10,848 one-time implementation economic cost

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

48 × 42 ÷ 60 = 33.60 hours

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

Base handling: 48 × 11 ÷ 60 = 8.80 hours
Exceptions: 48 × 15% × 18 ÷ 60 = 2.16 hours
Maintenance: 2.00 hours
Total: 8.80 + 2.16 + 2.00 = 12.96 hours

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

33.60 - 12.96 = 20.64 hours

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

20.64 × $44 = $908.16

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

$908.16 - $90 = $818.16

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

$10,848 ÷ $818.16 = approximately 13.3 months

Recovered time does not automatically reduce payroll. It can represent additional capacity, quicker review turnaround, reduced overtime, fewer administrative follow-ups, and lower dependence on one coordinator. It can also help the same team manage a larger SOP library without increasing manual reconciliation at the same rate.

Non-financial benefits include:

• Clear ownership for every active SOP
• Fewer incomplete review requests
• More consistent approval evidence
• Earlier visibility of overdue reviews
• Reduced exposure to obsolete files in normal search and portal views
• Better reporting by category, owner, status, and exception
• More consistent employee access to approved procedures
• A traceable retirement process

Readers should replace the monthly volume, handling time, exception rate, maintenance time, labour rate, licensing allocation, implementation effort, and professional rate with their own figures. They should also separate time spent searching for SOPs from time spent administering workflow if both benefits are to be estimated.

Adding AI to the Automation

AI should be added only after required fields, deterministic validation, approvals, permissions, review scheduling, and failure handling work reliably.

Useful AI applications for an SOP library include:

• Summarizing long feedback descriptions
• Suggesting a category for an unstructured request
• Identifying likely missing information
• Extracting referenced equipment, systems, or procedure numbers
• Suggesting search keywords
• Comparing two document versions for reviewer attention
• Supporting semantic search across permitted content

AI is not needed to calculate a review date, increment a version, enforce a required field, match an exact SOP number, choose an access group from a lookup table, or apply a threshold rule. Those tasks are more reliable and less expensive as ordinary automation.

The core automation creates records, tasks, folders, approvals, reminders, notifications, and status history. AI adds value specifically when staff must interpret unstructured text or compare lengthy content.

The Recommended AI Enhancement

The recommended first enhancement is AI-assisted feedback and change-request triage. It summarizes the submission, suggests a category and priority, and identifies missing information. A Quality user confirms or corrects every suggestion before the values affect routing.

• Trigger: A valid feedback or change-request event reaches Quality Triage.
• AI input: Event title, rationale, feedback type, selected SOP metadata, and non-sensitive attachment text if separately approved.
• System instruction: Classify and summarize without making approval, safety, legal, or publication decisions.
• Expected output: One JSON object matching the defined schema.
• Validation: Parse JSON, check allowed categories and priorities, confirm confidence is between zero and one, and reject unexpected properties where practical.
• Record update: Write suggestions into separate AI fields, not the authoritative category or priority fields.
• Human review: Quality accepts or corrects the suggestions.
• Low confidence: Scores below 0.75 remain unclassified and enter manual review.
• Prohibited data: Credentials, medical information, disciplinary information, controlled technical data, customer secrets, and unnecessary personal data.
• Logging: Store model deployment, prompt version, timestamp, output, human correction, and flow run ID.
• Failure behavior: Continue with normal manual triage. AI failure must not block the SOP workflow.

Reusable system instruction

You assist a manufacturing Quality team with preliminary SOP request triage.

Return only one valid JSON object matching the requested schema.

You may summarize the request, suggest a category, suggest a priority, and identify missing information. You must not approve or reject an SOP, determine legal or regulatory compliance, make a safety decision, publish a document, assign access, or invent facts.

Use only the information supplied. If the request is ambiguous, add the ambiguity to missingInformation and lower confidence. Do not include personal data that is not necessary to describe the operational request.

Reusable user prompt

Review this SOP event.

Event number: {{EVENT_NUMBER}}
Event type: {{EVENT_TYPE}}
Current SOP number: {{SOP_NUMBER_OR_NEW}}
Current SOP title: {{SOP_TITLE_OR_UNKNOWN}}
Submitted title: {{EVENT_TITLE}}
Feedback type: {{FEEDBACK_TYPE_OR_NONE}}
Rationale or feedback:
{{RATIONALE}}

Allowed categories:
Operations
Quality
Maintenance
Safety
IT
Other

Allowed priorities:
Low
Normal
High

Return:
1. A factual summary of no more than 80 words.
2. One suggested category.
3. One suggested priority.
4. A list of missing information.
5. Whether a human should give the event immediate attention.
6. Reasons for immediate attention.
7. A confidence value from 0.00 to 1.00.

Do not make a final approval, safety, legal, regulatory, access, or publication decision.

Expected JSON schema and example

{
  "summary": "The request proposes adding torque-wrench verification before final assembly inspection and references a quality event.",
  "suggestedCategory": "Operations",
  "suggestedPriority": "High",
  "missingInformation": [
    "Confirm whether the change affects operator training."
  ],
  "requiresHumanAttention": true,
  "attentionReasons": [
    "The request references a quality nonconformance."
  ],
  "confidence": 0.86
}

Optional Azure OpenAI request

If Azure OpenAI is approved, Power Automate can call the deployed model using an HTTP or custom connector permitted by the tenant. The exact supported API version and model parameters should be taken from the deployed Azure resource rather than copied from an old configuration.

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

Headers:
Content-Type: application/json
api-key: Retrieve from approved secret storage

{
  "messages": [
    {
      "role": "system",
      "content": "You assist a manufacturing Quality team with preliminary SOP request triage. Return only one valid JSON object matching the requested schema. Do not approve, reject, publish, retire, or make safety, legal, regulatory, or access decisions."
    },
    {
      "role": "user",
      "content": "Event number: {{EVENT_NUMBER}}\nEvent type: {{EVENT_TYPE}}\nSOP: {{SOP_NUMBER_OR_NEW}}\nTitle: {{EVENT_TITLE}}\nFeedback type: {{FEEDBACK_TYPE_OR_NONE}}\nRationale: {{RATIONALE}}\nAllowed categories: Operations, Quality, Maintenance, Safety, IT, Other.\nAllowed priorities: Low, Normal, High.\nReturn summary, suggestedCategory, suggestedPriority, missingInformation, requiresHumanAttention, attentionReasons, and confidence."
    }
  ]
}

Authentication uses the Azure resource API key or an approved identity-based method supported by the organization’s connector design. Never place a real key in the request body or article configuration. No pagination is required for one completion request.

Configure retry only for temporary timeouts, HTTP 429 responses, and server errors. Respect the resource’s rate limits. Do not retry malformed prompts or validation failures automatically. Parse the assistant message content, validate it against the expected JSON structure, and route malformed output to manual triage.

Benefits of the AI Enhancement

• Less reading time for long feedback descriptions
• More consistent preliminary categorization
• Faster recognition of incomplete requests
• Structured summaries that can be used in operational reports
• Quicker identification of requests that mention safety, quality, or compliance concerns
• Better search keywords after human confirmation

These benefits are separate from the core automation. AI does not create the evidence folder, assign the permanent event number, calculate the review date, enforce access, route an approved workflow, or preserve version history. Those results come from the rule-based SharePoint and Power Automate implementation.

What Remains Rule-Based or Human-Controlled

Estimating the Additional Value of AI

The following assumptions should be tested during a pilot rather than treated as expected production performance:

• 24 unstructured feedback or change requests per month
• Core automation triage time of five minutes per applicable record
• AI-assisted triage and human review time of two minutes per applicable record
• 15 percent correction rate, with three minutes per correction
• 3 percent AI failure rate, with five minutes of fallback work
• $15 monthly AI usage allowance
• $44 loaded hourly labour cost

Gross time saved:
24 × 3 minutes ÷ 60 = 1.20 hours

Correction effort:
24 × 15% × 3 minutes ÷ 60 = 0.18 hours

Failure fallback:
24 × 3% × 5 minutes ÷ 60 = 0.06 hours

Net additional capacity:
1.20 - 0.18 - 0.06 = 0.96 hours per month

Estimated labour value:
0.96 × $44 = $42.24 per month

Estimated net value after AI usage:
$42.24 - $15 = $27.24 per month

The initial financial value is modest at this volume. The stronger justification may be consistent triage and faster identification of incomplete requests. The organization should retain AI only if pilot measurements show useful quality, acceptable corrections, and appropriate data handling.

Testing Checklist

Use fictional or sanitized sample data before processing real procedures, approval comments, or restricted information.

Ongoing Maintenance

The Quality Systems Coordinator is the primary business owner. The Quality Manager is the backup business owner. The Microsoft 365 Administrator owns technical connections, permissions, and platform monitoring.

Credential rotation should follow the organization’s identity and secret-management policy. Flow connections should be checked whenever an owner changes role, leaves the organization, or has authentication controls modified.

If AI is enabled, Quality should sample outputs, track corrections, monitor low-confidence rates, review prohibited-data incidents, and compare usage cost with measured time saved. Prompt versions and schema changes should be tested before deployment.

Documentation must include the data model, list internal names, environment variables, flow owners, approval rules, retry procedure, rollback procedure, access groups, retention decisions, and known limitations.

When to Move to Dedicated Software

The Microsoft 365 implementation does not need to be replaced merely because the SOP count grows gradually. It should be reviewed when the operating or control requirements materially change.

• Transaction volume makes list views, flows, or exception handling difficult to administer.
• The company needs regulated electronic signatures or validated computer-system controls.
• Formal training assignment and employee attestation must be tied to every SOP version.
• Multiple sites require localized versions, translations, or separate approval authorities.
• Permissions become too complex for library-level groups.
• Document relationships, effective-date scheduling, or supersession rules become substantially more complex.
• Audit requirements demand packaged evidence, immutable records, or vendor-supported validation.
• Integration is required with ERP, manufacturing execution, learning-management, maintenance, laboratory, or quality-management systems.
• Exception rates and manual recovery consume increasing administrative time.
• Mobile, offline, kiosk, or shop-floor acknowledgement requirements become important.
• A customer-facing or supplier-facing controlled-document portal is required.
• The business requires contractual support commitments for document-control workflow.
• Security risk increases because too many uniquely secured files, custom flows, or service identities must be maintained.

Relevant categories include document-management systems, electronic quality-management systems, learning-management systems, and manufacturing knowledge platforms. A replacement decision should compare the cost and risk of maintaining the existing implementation with the migration, licensing, validation, and change-management cost of dedicated software.

Implementation Checklist

• Confirm business requirements, SOP types, workflow volume, and regulatory constraints.
• Select the SharePoint, Microsoft Lists, Power Automate, and Teams architecture.
• Confirm accounts, tenant capabilities, connector rights, and licensing.
• Create test and production environments.
• Define owners, backup owners, approvers, readers, and support roles.
• Create security groups and permission boundaries.
• Inventory legacy procedures and quarantine unknown versions.
• Create controlled-document and evidence libraries.
• Configure versioning, content approval, draft visibility, and retention.
• Create SOP Categories, Register, Events, Tasks, Feedback, History, Keys, and Errors lists.
• Configure unique fields, indexes, defaults, and views.
• Build event and feedback intake forms.
• Document the field mapping between every connected tool.
• Build duplicate prevention and identifier generation.
• Build task, folder, attachment, and Teams notification automation.
• Configure approval routes, sequential stages, and all-approver stages.
• Configure reminders, escalations, delegation, rejection, and return-for-change handling.
• Build status-history and reconciliation flows.
• Create reporting views for reviews, overdue work, failures, ownership, and volume.
• Configure Try, Catch, Finally, retry, and manual-recovery behavior.
• Protect credentials, restricted data, drafts, evidence, and shared links.
• Test all expressions, connector outputs, internal field names, and permissions.
• Complete user acceptance testing with sample data.
• Pilot with one department before broader migration.
• Document rollback, support, and launch communication.
• Replace representative cost assumptions with actual tenant and labour costs.
• Replace savings assumptions with measured handling time and exception rates.
• Add AI only after the rule-based workflow is reliable.
• Keep AI suggestions separate from authoritative fields and human decisions.
• Assign primary and backup maintenance owners.
• Define the volume, security, regulatory, integration, and support criteria that would justify dedicated software.