The Problem

Implementing an identity platform across a K-12 district involves three distinct phases. First, the district's data across Active Directory, Infinite Campus, and Munis needs auditing for errors that block provisioning. Second, those errors need tracking through remediation across weeks of back-and-forth with district IT — often across multiple districts simultaneously. Third, the configuration must be validated before go-live. Without dedicated tools, all three phases rely on manual spreadsheet work and email threads.

The Solution

Three connected tools, each handling a distinct phase and feeding the next.

What It Demonstrates

• End-to-end systems thinking — three tools designed as a connected workflow
• Full-stack breadth: Python data processing, vanilla JS browser app with localStorage persistence, Claude API-powered validation tool
• Deep K-12 identity domain expertise: provisioning workflows, source system reconciliation, OU configuration, dynamic group management
• Designing for real users under real constraints — used live on client calls, built to handle messy real-world data

Screenshots

Tool 1 — Audit Generator · Excel output with color-coded remediation dashboards

Tool 2 — District Tracker · multi-district remediation tracking with DVR delta history

Tool 3 — Mapping Validator · Claude API-powered scored configuration review

Overview

A Python-based desktop utility that transforms structured data files based on configurable rule sets. Users define conditional transformation rules and apply them to operational datasets through a graphical interface — no command line required.

Use Case

Transforming structured operational files where specific column values must be updated based on defined conditions before ingestion into another system. Built to eliminate repetitive manual file modification and reduce pre-ingestion data preparation errors that accumulated across the operational cycle at GMRS.

What It Demonstrates

• Translating a repetitive manual workflow into a reusable, configurable tool
• Python GUI development with Tkinter for non-technical end users
• Data transformation logic using Pandas applied to real operational file structures

Screenshot

File Transformer GUI — configurable rule blocks, source/destination column mapping

Overview

Built to merge datasets from multiple sources into a unified structure suitable for reporting and analysis — eliminating manual consolidation work that was error-prone and time-consuming across GMRS's multi-project environment.

The Problem It Solved

Operational data at GMRS originated from multiple separate systems and file formats. Combining them for reporting required manual work that introduced inconsistencies and consumed significant staff time every cycle. This tool codified the merge logic and made it repeatable and auditable.

What It Demonstrates

• Multi-source data pipeline design — normalizing and merging sources correctly, not just reading files
• Turning a manual, error-prone process into a reliable, repeatable tool
• Python/Pandas data engineering applied to real operational workflows

Screenshot

Spreadsheet Combiner — multi-file selection, header mapping, 1,847 rows combined across 5 sources

Overview

Merges and standardizes disposition-level data from multiple sources into a unified reporting dataset. Replaced manual consolidation processes, reducing errors and significantly improving data consistency for operational reporting and analysis across GMRS research campaign lifecycles.

What It Demonstrates

• Applied automation to a high-frequency, error-prone operational task
• Data standardization logic across inconsistent source formats
• Python/openpyxl for structured Excel output generation

Screenshot

DispoMerge — GUI with log output showing 4,812 records processed, 421 duplicates removed, 3,200 merged and saved

Overview

A Streamlit web application enabling non-technical administrators to configure, audit, and export identity platform dynamic group mapping rules across Active Directory and Google Workspace — without touching raw configuration files or requiring technical knowledge of the underlying systems.

What It Replaced

Manual reconciliation of group mapping rules that required technical staff to directly inspect and compare configurations across systems. The engine made this accessible to implementation managers and reduced reconciliation from hours to minutes.

What It Demonstrates

• Streamlit application design for non-technical end users in a production environment
• Deep knowledge of identity platform group rule architecture
• Building tools that increase operational capacity without adding technical headcount

Screenshot

District Logic Engine v5.1 — Seattle_Unified, 847 groups loaded · 612 synced, 143 AD Only, 67 Google Only, 25 Missing

The Problem

Remote job listings are scattered across dozens of platforms with inconsistent formatting, duplicate postings, and no unified view. Manually tracking and comparing listings across sources is time-consuming and error-prone — exactly the kind of problem that should be automated.

What It Does

• Pulls live data from RemoteOK API, We Work Remotely RSS, and Remotive API simultaneously
• Merges all records into a unified stream and deduplicates across sources
• Normalizes data structure and field values across sources with inconsistent schemas
• Routes records into Master Table and Daily Feed views in Airtable via upsert
• Generates audit, normalization, dedupe, and combo reports for pipeline visibility

What It Demonstrates

• Practical workflow automation using n8n node-based architecture
• Multi-source data ingestion, transformation, and normalization across inconsistent APIs
• Real-world application — built to solve an actual operational problem, not as a demonstration

Screenshots

n8n workflow canvas — three parallel API ingestion paths merging into dedupe, normalization, and Airtable upsert

Airtable output — normalized job listings from RemoteOK, We Work Remotely, and Remotive

Overview

An Excel-based forecasting model projecting staffing requirements and workload demand across multiple shifts based on historical trends. Built for a 300+ employee, multi-project call center operation where accurate staffing projection directly affected production capacity and client deliverable timelines.

Part of a Broader Financial Framework

One component of a three-part financial operations suite — alongside the CPI Calculator and Multi-Study Profitability Tracker — that together served as the central financial intelligence layer for GMRS executive decision-making.

What It Demonstrates

• Applied Excel modeling for operational forecasting in a complex, dynamic environment
• Understanding of how staffing projections connect to production outcomes and financial results
• Building systems that translate raw operational data into decision-ready outputs

Screenshot

Forecasting Model — Notes tab, manual entry with 5-shift projection results, and auto-calculation engine

Overview

A scalable reporting and analytics framework consolidating multi-source operational, staffing, and performance data into a single source of truth. Designed to track 50+ metrics per shift across campaign lifecycles with auto-calculated KPIs and a structured data entry architecture — replacing informal, inconsistent reporting practices across all active research campaigns at GMRS.

What It Replaced

Informal, ad-hoc shift reporting that varied by supervisor and couldn't be reliably aggregated or audited. The framework standardized what was captured, how it was captured, and how it connected to downstream financial and billing systems.

What It Demonstrates

• Systems thinking at the operational level — connecting shift-level data to executive-level visibility
• Excel architecture for structured data entry that maintains integrity at scale
• Reporting design that serves multiple stakeholders: floor supervisors, operations management, and executive leadership

Screenshot

Raw supervisor shift input (left) → auto-calculated KPI summary report (right) · Study X0014, Banking Customer Communications

Overview

A financial operations dashboard built using simulated transaction data to replicate real-world reporting scenarios. Developed KPI frameworks for authorization rates, failure rates, and processing performance, with visualizations for trend analysis and operational monitoring.

Design Intent

Built to demonstrate clean data structure, reporting accuracy, and actionable insights at a production level — not a toy example, but a genuine template for the kind of financial reporting used to monitor transaction processing operations. Emphasized structural clarity and reproducibility.

What It Demonstrates

• Financial KPI framework design: authorization rates, failure rates, processing performance
• Dashboard layout and visualization design for operational decision-making
• Clean data architecture that supports reliable, reproducible reporting

Screenshots

Source data — raw transaction CSV with TransactionID, Status, Amount, PaymentMethod, CardType, AuthTimeMs

Structured table — 60% auth rate, 20% failure rate, 213ms avg processing time

Pivot analysis — processing time by status, volume by date, channel, and outcome

Dashboard — transaction by status, avg processing time, payment method breakdown, daily volume with narrative commentary

Overview

A two-component financial toolkit for research study management: a pre-field cost estimator projecting the cost-per-interview before a study begins, and a post-field profitability tracker comparing true operational cost against client billing across all concurrent studies.

Why It Mattered

In a multi-client call center running dozens of concurrent research studies, billing accuracy and profitability visibility were critical. Without systematic tracking, individual study margins were invisible until invoicing — by which point it was too late to course-correct. This toolkit brought real-time financial visibility to every active study.

What It Demonstrates

• Financial modeling applied to operational research environments
• Pre-field / post-field analytical framework design
• Multi-study ledger architecture that scales across concurrent client engagements
• Understanding of how operational decisions connect directly to financial outcomes

Screenshots

CPI Calculator — Study X0001, CNO Financial · $45 bid vs $15.17 actual CPI, incidence rate +20% above estimate

Profit Evaluator — 12 studies, $27,895 cost, $158,420 billed, +$130,133 net · 11 profitable, 1 at loss

Overview

Salesforce reporting solutions designed and maintained to monitor support operations, track key performance metrics, and analyze customer trends at Identity Automation — built for cross-functional stakeholders with focus on data integrity, report accuracy, and usability.

Key Applications

• Built reporting to track adoption trends across the K-12 customer portfolio
• Monitored support activity and operational risk indicators by customer and district
• Designed dashboards supporting cross-functional visibility for CSE, TAM, and leadership teams
• Maintained data integrity across CRM records tied to active implementations

Overview

A 54-slide collaborative Salesforce Admin Sprint project completed through Clicked, covering the full Salesforce Admin curriculum across seven task sets: Configuration & Setup, Object Manager & Lightning App Builder, Sales & Service Cloud, Data Analytics Management & Productivity, and Workflow & Process Automation.

What It Shows

• End-to-end Salesforce admin competency across the full curriculum
• Ability to structure and present technical work clearly for a professional audience
• Collaborative project execution across a team of 8 contributors
• Canva-produced presentation demonstrating visual communication alongside technical content

Dashboard Preview

Animated walkthrough showing slicer filtering, cross-filter interaction, and page 2 shift-level analysis. Built in Power BI Desktop on mock data modeled from real operational structure.

The Context

Nearly 30 years of call center operations data no longer exists in accessible form — but the metrics, structures, and operational logic do. This project reconstructs a representative dataset from that institutional knowledge: 180 concurrent research studies across four branch locations, 664 individual shifts tracked across AM/PM breakdowns, and a full date dimension — all modeled as a proper star schema with defined relationships.

The goal was twofold: build real Power BI hands-on experience with data that actually means something, and produce a portfolio artifact that demonstrates operational analytics thinking — not just chart-clicking on a sample dataset.

The Data Model

Three tables connected via defined relationships in Power BI's model view:

• studies — 180 rows, one per research project. Study name, client, call center, PM, LOI, incidence rate, LL/CP completes and hours, production rate, CPI vs. bid CPI, and full charge breakdown through total revenue.
• shifts — 664 rows, one per shift worked across 60 studies. AM/PM breakdowns, supervisor, dial metrics, production rate, comprate, TQs by termination reason, refusals, breakoffs, and answering machines.
• dim_date — Full date dimension covering 2023–2024 with year, quarter, month, week, and weekday flag for time intelligence.

Page 1 — Study Overview

Four visuals with a call center slicer providing interactive cross-filtering across all charts simultaneously:

• Total Revenue by Call Center (horizontal bar)
• Completed Interviews by Project Manager (horizontal bar)
• Average Production Rate by Month (line chart — monthly trend)
• Average Incidence Rate by Call Center (horizontal bar)

Page 2 — Shift-Level Operations

Drill-down into shift performance with cross-filtering active across all three visuals:

• Production Rate by Supervisor (average, horizontal bar)
• Production Rate by Supervisor and Shift — AM vs. PM breakdown (clustered bar with legend)
• Breakoffs and Refusals by Month (dual-axis line chart — separate Y-axes for each metric)

What It Demonstrates

• Star schema data modeling with defined table relationships
• Correct aggregation choices (Average vs. Sum) for rate-based metrics
• Cross-filtering behavior across related tables
• Slicer design with user experience considerations (Select All, filter reset)
• Dual-axis charting for metrics at different scales
• Multi-page dashboard architecture with consistent visual language

The Problem This Models

Before any donor data can be loaded into a CRM — Salesforce, Microsoft Dynamics, Blackbaud, or otherwise — it has to be cleaned. Every nonprofit technology implementation runs this gauntlet: data arrives from three or four sources, each with different field names, different formatting conventions, and duplicate records for the same person. Someone has to normalize it, resolve the duplicates, document every decision, and produce a validated output file the import tool will actually accept.

This simulator models that workflow end to end across three realistic source systems: a Salesforce Contacts export (with real NPSP field names like npo02__TotalOppAmount__c), an email platform subscriber export, and an event sign-in spreadsheet.

What the Pipeline Actually Does

The tool isn't decorative — the JavaScript is executing each step against real authored source data:

• Stage 1 — Ingest: Reads 33 total records across three sources with inconsistent schemas and field naming conventions
• Stage 2 — Field mapping: Resolves 12 source field variants (FirstName / fname / First Name) to a single canonical donor schema
• Stage 3 — Quality validation: Catches and corrects phone number formats, state name abbreviations, invalid values, and missing critical fields — with counts and specific examples for each issue type
• Stage 4 — Deduplication: Detects cross-source duplicate groups via email matching, applies best-value field selection logic on merge (CRM giving history preferred over email platform engagement data), and resolves name variants like "Pat Harris" vs. "Patricia Harris"
• Stage 5 — Output: Produces a real downloadable CSV (39 unique records, Salesforce NPSP Contact schema compatible) and a timestamped audit log of every transformation

Design Decisions Worth Explaining

What It Demonstrates

• Systems thinking across the full data operations loop — ingest → map → validate → deduplicate → output → document, not just individual tasks
• Nonprofit CRM domain fluency — real NPSP field names, Salesforce Data Loader output schema, the specific quality problems that appear in nonprofit donor data
• Audit-first methodology — every transformation is a documented decision, not a silent correction
• Best-value merge logic — source record preference is deliberate and explained, not arbitrary
• Building tools to demonstrate thinking, not just describe it

Why This Exists

The Donor Data Pipeline Simulator (its sibling project) covers what happens before data enters a nonprofit CRM. This tool covers what happens inside it — the NPSP-specific data model decisions that determine whether reporting, receipting, and donor relationships actually work. Built to demonstrate working knowledge of the data model itself, not just the vocabulary.

The Four Modules

• Household Account model: Ungrouped contacts resolve into Household Accounts with combined giving roll-ups — including the edge case household grouping rules have to get right (same last name, different address resolves to a separate household)
• Hard vs. soft credits: Gift entry with automatic household soft credits for spouses and an employer matching-gift path — with separated totals showing why finance reports on hard credits only while development reporting may include soft-credit recognition
• Constituent deduplication: A 12-record file scanned with nickname normalization (Bob ↔ Robert, Liz ↔ Elizabeth, Peggy ↔ Margaret), email/address/phone match scoring with stated reasons, and a merge preview where the surviving record keeps the most complete value per field
• Tax receipt batch run: A weekly batch that honors Do Not Mail / Do Not Email flags, routes by preferred channel, holds records that fail address validation, suppresses anonymous gifts — and logs every exclusion with its reason

Design Decisions Worth Explaining

What It Demonstrates

• NPSP data model fluency — Household Accounts vs. one-to-one and Person Account models, Opportunity-based gift entry, automatic household soft credits
• The revenue-integrity distinction — why conflating hard and soft credits is one of the most common nonprofit reporting errors, and how the model prevents it
• Dedup methodology — normalized comparison, weighted multi-signal scoring with stated reasons, best-value survivorship on merge
• Preference-aware communications — donor consent flags treated as hard constraints with an auditable exclusion trail

Why This Exists

Decades of hand-written SQL is one claim; being able to query Salesforce specifically is another. This workbench is the bridge: the same relational thinking — aggregation, grouping, filtering, anti-joins — expressed in the SOQL dialect against the NPSP object model, applied to the questions fundraising teams actually ask.

The Query Library

• Top households by lifetime giving — the foundational NPSP roll-up: closed-won Opportunities grouped by Household Account
• LYBUNT report — donors who gave Last Year But Unfortunately Not This: the most actionable retention list in fundraising, built on NPSP's Contact rollup fields
• SYBUNT report — gave Some Year But Unfortunately Not This, ordered by lapse age for reactivation segmentation
• Soft credit recognition — non-primary OpportunityContactRole totals per contact: household recognition without double-counting revenue
• Lapsed major donors — $1,000+ lifetime giving with no gift in 2+ years, using SOQL's LAST_N_YEARS relative date literal
• Year-over-year giving trend — the board-meeting query, using SOQL's CALENDAR_YEAR() date function

Design Decisions Worth Explaining

What It Demonstrates

• SQL-to-SOQL transfer — aggregation, grouping, and filtering logic carried from decades of production SQL into the Salesforce dialect
• NPSP object model fluency — Contact rollup fields, Opportunity-based gifts, OpportunityContactRole soft credits
• Fundraising domain vocabulary — LYBUNT, SYBUNT, lapse segmentation, major donor thresholds
• Analyst judgment — every query paired with the operational reason a team runs it

The Problem This Models

A research study needs 600 completed interviews — but not just any 600. The dataset must mirror the target population across every dimension at once: age bracket, region, and sample type. That turns one target into 32 concurrent micro-targets, each of which must close for the data to be representative. And cells fill unevenly: younger respondents are harder to reach, cell-phone sample converts differently than landline, regional contact rates vary by shift. Passive monitoring fails; the operation needs variance analysis that surfaces under-pacing cells while there's still field time to act.

What the Simulation Does

• Quota structure: stratifies a client-issued 600-complete specification across 4 age brackets × 4 regions × 2 sample types using population weights — the spec is the client’s; making it operational is the job
• Shift simulation: each "Run shift" applies differential response propensities plus production noise, so the matrix fills realistically unevenly across a 14-shift field period
• Attainment heatmap: every cell color-codes its fill rate against pace; filled quotas close and production against them stops — every interview against a closed cell is wasted cost
• Variance report: under-pacing cells ranked worst-first, each with the per-shift completion rate now required and the floor intervention: which sample to load, where to weight interviewer hours, when to escalate

Provenance

What It Demonstrates

• Spec-to-structure translation — taking a client-issued quota specification and making it operational: the business-analyst bridge between research design and production
• Statistical sampling methodology — stratification, population weighting, differential response modeling
• Real-time operational analytics — pace-vs-plan tracking with automatic cell closure at quota
• Variance-driven decision-making — analysis that ends in an instruction, not just a number
• Deep operational expertise — methodology grounded in three decades of production quota and sampling work