Fragmented intake
Form data has to be normalized, routed, and written into different operational structures without breaking downstream imports.
Production-style synthetic demo
2026
Operations & Workflow Automation Specialist
Magnolia Park Dental
Automation System
A seven-scenario Make.com case study showing how I implement, test, troubleshoot, and refine operational workflows across intake, scheduled worklists, missed-call recovery, monitoring, and maintenance.
Scope boundary: synthetic/sample data only. This is not a paid client deployment, not a real-patient system, and not evidence of production HIPAA deployment.
Make.comWebhooksRoutersFiltersAggregatorsHTTP/APIGoogle SheetsGoogle DriveGmailTwilioSlackData stores
The operating problem
Front-desk work has many failure points, not one.
The case study models a dental front desk as a connected operating system. Intake, recurring CSV work, missed calls, alerts, and cleanup each need different triggers and controls, but they still have to behave coherently.
The implementation focuses on reliable handoffs, human-readable worklists, safe routing, duplicate prevention, and visibility when scenarios fail.
Manual worklists
Recall and eligibility work depend on recurring exports that can create duplicate rows, stale lists, or repeated messages if bundle flow is handled poorly.
Missed-call follow-up
A missed call needs filtering, deduplication, time-based routing, and a staff signal without unnecessarily exposing identifiers.
Silent automation failure
A scenario that stops running can look healthy unless monitoring understands the difference between scheduled and event-driven workflows.
System map
Seven workflows, with build status shown precisely.
The broader blueprint defines seven scenarios. The portfolio highlights the strongest implementation evidence and does not imply that every scenario has identical completion status.
S1Core path implemented
Patient Intake
Webhook intake, phone and contact normalization, emergency routing, dual Google Sheets writes, and welcome communication logic.
WebhookNormalizeRouteSheets + comms
S2Partial build
Review Request
Scheduled row lookup for completed appointments with one-time review-message logic.
S3Built evidence
Friday Recall
Drive discovery, file download, CSV parsing, text aggregation, email output, scheduling, and error handling.
S4Built evidence
Daily Eligibility
Controlled sheet refresh, CSV fan-out, per-row writes, array aggregation, and a single summary email.
S5Synthetic demo built
Missed-call Recovery
Webhook gate, caller normalization, patient lookup, 60-minute deduplication, business-hours routing, demo SMS, Slack signal, and logging.
S6Verified demo build
Watchdog
HTTP requests to Make execution logs, scenario-specific recency logic, alert routing, and error handling on the monitor itself.
S7Built evidence
Error Log Cleanup
Monthly retention maintenance using data-store search and delete logic with separate failure routes.
Architecture
Inputs become actions through controlled orchestration.
The system combines event-driven triggers, scheduled exports, state, business rules, communication channels, and a separate reliability layer.
01 Inputs
Webhook eventsIntake + missed calls
Scheduled exportsRecall + eligibility CSVs
02 Orchestration
Make.com scenariosVariables, routers, filters
Bundle controlParse, fan-out, aggregate
03 Data + state
Google WorkspaceSheets + Drive + Gmail
Data storeError + missed-call state
04 Actions
Worklists + emailHuman operational handoff
Demo messagingTwilio + PHI-free Slack
Technical deep dives
Three implementation patterns I would discuss in an interview.
These examples show the most useful technical evidence in the project: stateful branching, bundle control, and monitoring logic that matches the actual trigger model.
01
Missed-call recovery
Search, aggregate, deduplicate, then route.
A synthetic call.completed payload enters through a custom webhook. The connection filter admits only incoming unanswered calls. The flow normalizes the caller number, searches the patient sheet, and uses an aggregator so a zero-result lookup can still continue.
The shared data store checks whether that caller was handled in the previous 60 minutes. New events move to a business-hours router, demo SMS logic, a PHI-free Slack notification, and an event log.
Guard patternSearch → aggregate → branch
State window60-minute dedup
RoutingBusiness hours / after hours
Data boundaryNo identifiers in Slack
1WebhookSynthetic call.completed
2Missed-call gateincoming + unanswered
3Lookup + guardpatient search + aggregator
4Dedup statesame caller, last 60 min
5RouterSMS demo + Slack + log
02
Daily eligibility
Let the rows fan out, then collapse only after the writes.
The workflow finds and downloads the latest appointment export, clears only the previous worklist rows, parses the CSV, and writes each appointment into the review sheet.
The important implementation detail is module placement. The clear step executes before CSV fan-out, and the Array Aggregator executes after the per-row writes. That preserves N rows in the sheet while ensuring the downstream summary email runs once.
InputScheduled CSV export
Fan-outN records → N sheet rows
ResetClear before parse
CollapseAggregator → one email
1Find filelatest export in Drive
2Clear worklistA2:J, header preserved
3Parse + writeN bundles → N rows
4AggregateN bundles → 1 bundle
5Emailone summary message
03
Watchdog monitoring
Health rules depend on the scenario's trigger model.
The Watchdog requests recent execution logs from the Make API and evaluates each monitored scenario against a suitable rule. Event-driven workflows can legitimately have no trigger. Scheduled workflows need evidence of a recent successful run.
The implementation uses 24-hour windows for daily jobs, an 8-day window for the weekly recall workflow, and event-driven logic for webhook scenarios. Each HTTP module also has its own failure route so the monitor can report problems in the monitor itself.
TransportHTTP + Make API
Daily scenarios24-hour success
Weekly scenario8-day success
Monitor safetyHTTP error routes
scenario health
S1 · Patient Intakeevent-drivenhealthy
S2 · Review Request24 hourshealthy
S3 · Friday Recall8 dayshealthy
S4 · Eligibility24 hourshealthy
S5 · Missed Callevent-drivenhealthy
Video walkthrough
See the automation in Make.com.
The supplied YouTube walkthrough is embedded as the visual companion to the case study. The written claims on this page are grounded in the documented project sources.
Open on YouTube ↗QA & reliability
Testing beyond a successful first run.
The project documentation records repeated internal QA passes, failure-mode checks, live output verification, and formula corrections. The emphasis was on exposing silent-failure risks and refining the implementation.
Important: internal QA scores in the project documentation are not presented here as external certification.
Verify from output
Confirmed live bundle shapes and API response fields before finalizing mappings.
Failure-mode tests
Exercised routing, dedup behavior, worklist fan-out, monitoring windows, and deliberately broken paths.
Structured error routes
Used alert emails plus data-store records with hardcoded error-source labels for diagnosis.
Iterative correction
Fixed mapping, formula, module-order, recipient, and error-source defects found during testing.
Responsible design
Clear demo and production boundaries.
This case study is deliberately precise about what the work proves and what it does not.
✓ What the demo proves
- Hands-on Make.com implementation and troubleshooting
- Webhooks, routing, state, aggregation, scheduling, and HTTP patterns
- Operational thinking around silent failures, duplicates, and worklist design
- Explicit separation between synthetic demo flows and real PHI requirements
- Responsible AI-assisted work with validation in the actual tools
! What I am not claiming
- No paid Magnolia Park Dental client engagement
- No live production deployment
- No real patient data or PHI processing
- No production HIPAA certification or legal compliance attestation
- No claim that I independently originated the entire architecture
My role
Implementation, testing, troubleshooting, refinement.
I personally implemented, configured, tested, troubleshot, and refined the Make.com workflows shown in this project.
I used AI extensively for research, architecture development, implementation guidance, and troubleshooting. I validated the resulting logic in the builder and corrected issues through iterative testing.
This is strong evidence of hands-on automation implementation and systems execution. It is more limited evidence of independent blank-page architecture authorship, and I present it that way deliberately.
Samuel Kennedy
Operations experience, now focused on workflow automation.
I bring 10+ years of experience across regulatory operations, remote support, research, reporting, data management, and stakeholder coordination. My current focus is practical workflow automation and operations systems.