Automation, Software & Data

AI-augmented IT operations platform

IT Director · National food brokerage

I built an internal platform that brought tickets, device records, identity, and network context together for a three-person IT team supporting 850 users across 51 offices. Technicians could investigate a problem inside a ticket, check live systems, consult the team's documentation, and approve supported changes without switching consoles. A Claude agent drew on synchronized records, an MCP connector, and generated documentation to suggest responses; technicians kept control of changes.

From prototype to shared platform

I started with a scheduled Python job loading Freshservice exports into SQLite for a read-only Cowork skill, then moved to Supabase Postgres for concurrent use and more frequent updates. Python jobs in GitHub Actions synchronized Freshservice, Microsoft Graph, ScreenConnect, Meraki, Bitdefender, and Action1, handling throttling, resuming after partial failures, and updating without duplicates. The database used audit columns and row-level security; the ticket agent ran on Azure Functions.

Live tools through an MCP connector

For current data, such as whether a machine was online, I built and deployed a FastMCP server on Azure Container Apps that queries Freshservice, ScreenConnect, Meraki, Dell TechDirect, and Microsoft Graph. Entra assignment controlled who could connect, Graph calls used delegated on-behalf-of permissions, Freshservice callers used individual API keys, and secrets stayed server-side.

Documentation generated from live systems

I built a cross-referenced Markdown library from Graph, Azure, Meraki, Freshservice, Snowflake, and PowerShell queries through ScreenConnect, covering infrastructure, identity, applications, procedures, and recovery, with history in Git. Articles were mirrored into Freshservice for technicians without repository access; new team members onboarded from it and began contributing their own. The agent could propose corrections as pull requests for human review.

Ticket investigation and approvals

For each new ticket, the agent weighed the email thread, requester history, screenshots, device and network records, and similar resolved cases, then posted a private suggestion with a confidence band. Technicians could tag it to gather read-only diagnostics or ask clarifying questions. Supported changes (device fixes, service restarts, account administration, scheduled offboarding) required a preview and a separate confirmation, enforced in the action layer independently of the model.

• Ticket content was treated as untrusted; targets were resolved against asset and session records.
• Automatic triage excluded destructive commands; secrets were redacted before posting.
• An atomic claim prevented duplicate scheduled steps; a verification loop checked whether a fix held.

Cost, feedback, and deployment

Triage started on a lower-cost model and escalated when confidence was low, with a deterministic fallback for outages. Staff could correct the agent inside the ticket, and merges to main deployed the Azure Function automatically.

Business-system integrations and data pipelines

IT Director · National food brokerage

I built integrations that kept employee records, client access, and reporting data in sync, with checks to catch missing data and unexpected changes.

Entra ID records inside Snowflake

A Python stored procedure, scheduled as a Snowflake Task, imported employee records from Microsoft Graph with no external server. A SQL MERGE kept the user dimension current, and a deletion timestamp preserved departed users for historical reporting. Snowflake Secrets held the credentials, and an external access integration limited outbound calls to the Microsoft endpoints.

CRM-driven email groups and reporting access

CRM account assignments drove Exchange distribution lists and the Entra groups behind Fabric access. I moved the job from an on-premises scheduled task to an Azure Automation runbook with a managed identity, removing a file handoff and a stored credential. Because the same data decided who received client information, empty sources were skipped and reported, and unusually large membership changes stopped for review.

Approved employee SMS broadcasts

Staff submitted a Microsoft Form, Power Automate routed it for approval, Graph resolved the audience from dynamic Entra groups, and Twilio delivered it. The service included toll-free A2P verification, STOP and HELP opt-out handling, and a public terms page.

Manufacturer data into SharePoint

A PowerShell pipeline replaced a manual monthly process, pulling vendor volume data from the HPSCAT API into SharePoint through Graph across a changing manufacturer roster. The vendor bound API access to fixed source addresses, which Power Automate's dynamic egress could not meet, so the job ran from a known host. A later audit of scheduled automation moved its credential into a DPAPI-encrypted file and the job from a personal account on a shared server to a dedicated service account and host, with git-based deployment and a test to verify upload access.

Enterprise browser extension for a vendor portal

IT Director · National food brokerage

I built an Edge and Chrome extension to handle a monthly contract-email process in a vendor portal. It lists the active programs, previews recipients, and sends emails in batches the operator approves.

Why an extension

The extension runs in the user’s signed-in browser session, so it needs no backend or stored login credentials. It replaced earlier browser automation that struggled with the portal’s popups.

Reverse engineering

I used the portal’s grid API to read programs beyond the visible rows, then traced how its detail pages generated email links and submitted messages. The extension follows that process and checks each response.

Guardrails for irreversible actions

• Dry run first: shows where every email will go; nothing sends until confirmed.
• Explicit recipient selection: nothing is inferred silently.
• Supervised batches: each batch is a human click, which also sidesteps MV3 service-worker recycling.
• Run report: per-program sent/failed status, downloadable as CSV.

Self-hosted release pipeline

A GitHub Actions release signs the extension and publishes it to Cloudflare R2 for automatic updates. Intune installs it for the designated users in Edge and Chrome, with access restricted to the vendor’s domain.

Business applications and legacy-data integrations

IT Manager · Regional HVAC business

Custom quoting and office applications

Built a service-pricing calculator in VB.NET and ASP.NET Web Forms on IIS, encoding parts markups, labor, helper and travel charges, refrigerant fees, tax, and discounts, with emailed quotes. Rebuilt it in Python and Flask with Microsoft 365 sign-in, editable rate cards informed by service history, customer lookup, technician submission, office review, and PDF quotes sent from the reviewing employee's mailbox through Microsoft Graph delegated permissions.

Developed a separate office application on a nightly copy of the service system's data, covering maintenance-contract follow-up, season progress, service-call trends, billing backlogs, customer email (with suppression rules, contact history, and duplicate-send checks), and data-quality checks office staff could act on.

The applications used Entra ID sign-in with app roles mapped to existing Active Directory groups, tested route authorization, and kept secrets and writable state apart from code. They ran behind IIS with PowerShell blue/green deployments that tested, started the new version alongside the old, switched traffic, verified sign-in, and rolled back on failure.

Extended a generated PHP/MySQL commission tracker with business-specific logic and reports, and built a commission engine validated against historical payouts, with versioned rules, approval controls, and payroll exports.

Data integration and operational troubleshooting

Reconstructed Visual FoxPro table relationships from the business records and built Python tools for data validation and backup-first corrections, verifying interpretations with the people responsible for the work.

Traced an accounting-integration hang to control characters in customer records by correlating process dumps and application logs, then built scanners and repair tools for the affected data. Added a PowerShell watchdog with event-log alerts for a .NET backup service.

Reporting platforms: Fabric F64 and Snowflake

IT Director · National food brokerage

I led the move from per-user Power BI Pro licensing to Microsoft Fabric F64 capacity, with board approval. Alongside the licensing change, I designed group-based access and row-level security for internal and partner reporting.

Why capacity over per-seat

I compared capacity pricing with the cost of individual viewer licenses. F64 suited the business: staff and partners could view shared reports without a separate Pro license for each viewer, and the platform supported Copilot.

Access by attribute, not by hand

Entra dynamic groups used role, region, and department to assign workspace access. The identity standards kept those attributes consistent and reduced individual permission changes.

Row-level security and migration

Row-level security limited partners to their own sales and regional staff to their region, while corporate users had broader access. Reports, dashboards, and datasets moved during evening and weekend cutovers, with validation afterward. IT owned capacity, identity, and security; BI owned report content.

Snowflake platform review

I reviewed Snowflake usage through read-only queries and shared findings with the BI team: idle compute costs, warehouse queueing and memory pressure, and service-account and consultant permissions that needed narrower roles.