Cloud automation · Event-driven systems

Enterprise Healthcare Workflow Automation Engine

The connective tissue between Microsoft 365, custom apps, and clinical operations — turning manual handoffs into event-driven workflows.

Role
System design · Power Platform & Azure engineering
Inputs
Forms, list changes, schedules, webhooks
Output
Teams alerts, Lists writes, Planner tasks, audit log
Status
Prototype patterns

01 · Problem

Hospitals run on glue work.

Most hospital operations live in Microsoft 365 — Lists, SharePoint, Forms, Teams, Outlook — plus a fragmented set of custom apps. The handoffs between them are largely manual: copy-paste, email chains, “did you see my Teams message?”

Operations leaders lose hours each week to coordination work that should be automatic. The work is small, repetitive, and exactly the work event-driven systems were built to handle.

Manual coordination
Repetitive handoffs
Missed escalations

Lloyd has spent 9+ years inside hospital operations — the handoff patterns and ecosystem constraints are first-hand.

02 · System architecture

Three layers, composable across the Microsoft ecosystem.

Trigger surfaces fan into an orchestration layer that calls action surfaces — the same shape for every automation.

Trigger surface

Forms submittedList item changedSchedule (CRON)External webhook

Orchestration

Power Automate flowAzure FunctionBranching + retrySecrets via Key Vault

Action surface

Teams channel postLists writePlanner taskEmail + Calendar

Built prototypes inside a Microsoft 365 enterprise tenant. Not yet deployed at platform scale.

03 · One flow, end-to-end

Watch one handoff become a workflow.

A trigger fires, the orchestrator decides, actions fan out, and everything is logged. Step through it or let it run.

Step 1 of 5: List item change arrives. Flow run starts with a fresh correlation id.
Microsoft Lists · trigger: item changed
{
  "list": "Assets",
  "itemId": "A-0427",
  "assetType": "wheelchair",
  "site": "Site A",
  "previousStatus": "in-service",
  "currentStatus": "needs_service",
  "changedBy": "biomed.tech@site"
}
Orchestration

List item change arrives. Flow run starts with a fresh correlation id.

Actions fanned out
  • POST/teams/{teamId}/channels/{channelId}/messagesTeams
  • POST/planner/tasksPlanner
  • PATCH/sites/{siteId}/lists/{listId}/items/{itemId}Lists

Awaiting orchestration…

Audit log
flow-7c93a1 · outcome=ok · 1840ms

Representative built prototype. Concrete example shown to illustrate the shape — the same scaffold is reused across the patterns shown next.

04 · Patterns

Four shapes that cover most of the work.

Most operational automations collapse into a small set of reusable patterns. Each has been built and demonstrated.

Alert routing

Event from a system-of-record is classified and routed to the right human channel with full audit.

Equipment marked needs_service → severity classified → biomed on-call Teams channel + Planner task

List changedAzure FunctionTeams + Planner

Form → system-of-record

A submitted form drives an approval / write-back loop into a List or SharePoint document, with the submitter notified at each state.

Service request form → approval routing → Lists write + submitter notification

Form submittedPower AutomateLists + Email

Scheduled sync

Azure Function runs on a CRON, pulls from one Microsoft system, transforms, and writes to another — with idempotency keys and dead-letter routing.

Nightly: pull asset roster from List A → reconcile → write changes to List B

CRONAzure FunctionLists (read + write)

Webhook fan-out

External system event arrives by webhook and is fanned out to multiple downstream Microsoft Graph actions with per-action retry.

External incident.created webhook → Teams post + calendar event + Lists row

WebhookAzure FunctionGraph (3 calls)

Patterns shown have been built as prototypes inside a Microsoft 365 enterprise tenant.

05 · Reliability & governance

Past the happy path.

The difference between a clever flow and a production-worthy capability is everything that happens when something fails.

Idempotency

Every flow accepts a correlation ID. Duplicate triggers resolve to the same outcome without double-posting.

Retry & dead-letter

Transient failures retry with exponential backoff. Permanent failures route to a dead-letter list with full payload + error.

Secrets in Key Vault

No credentials in flow definitions. All keys, tokens, connection strings resolve through Azure Key Vault references.

Audit by design

Every run writes a row to a flow_audit list with correlation ID, outcome, duration, and triggering identity.

Prototype-grade implementations of each pattern, not yet hardened to production SLAs.

06 · What this enables

Coordination work that doesn’t get forgotten.

The honest framing — what these patterns make possible, without claiming production scale.

Removes manual handoffs

Every pattern eliminates a category of “did you see my message?” coordination work between Microsoft 365 surfaces.

Closes the audit gap

Operational events that used to live only in chat now have a structured, correlation-ID’d audit trail.

Composable, not bespoke

Each pattern is a scaffold — new automations slot into the same three-layer shape rather than being one-off scripts.

Designed to layer on top of existing systems like the wheelchair tracking platform, not replace them.

“Most operations don’t need a new platform. They need the existing one to talk to itself.”

  • ALM pipeline · solution packaging · environment promotion
  • Centralized monitoring · Application Insights · alerting
  • Naming standards · DLP policies · CoE oversight