Work
Selected problem-solving work across analytics, data engineering, automation, and business systems.
VerdaStat™ work starts with the operating problem, then designs the data model, workflow, platform, or reporting architecture needed to solve it.
How The Work Is Framed
Filter Work
Azure SQL Backend
Structured service request foundation
Internal requests were scattered across email, chats, spreadsheets, and informal follow-ups, making ownership, status, priority, comments, and reporting difficult to manage.
Designed a normalized Azure SQL backend with request, category, status, comment, and assignment tables, plus keys, constraints, timestamp logic, seed data, and a reporting-ready view.
Created a centralized, scalable backend foundation for structured tracking, cleaner data entry, future Power Apps integration, and BI reporting.
- Modeled one-to-many relationships for requests, comments, assignments, categories, and statuses.
- Used lookup tables and constraints to reduce invalid category, status, and priority values.
- Created a readable SQL view for future operational reporting and analytics.
BI Infrastructure
Refresh architecture migration
Scheduled BI refreshes depended on a gateway installed on a local workstation, creating a single point of failure when the machine slept, rebooted, disconnected, or became unavailable.
Designed a migration to a cloud-hosted Windows VM running the Power BI gateway while keeping the existing source, ingestion, storage, preparation, and query layers unchanged.
Reduced workstation dependency and created a more reliable, supportable refresh foundation with clearer monitoring, credential handling, backup, and future high-availability options.
- Mapped the current source, ETL, storage, preparation, query, gateway, and service layers.
- Outlined VM setup, gateway installation, connector configuration, dataset mapping, and refresh testing.
- Included production recommendations for monitoring, recovery-key storage, service credentials, and gateway clustering.
CRM Automation
Website-to-CRM lead intake workflow
Business users were spending too much time manually handling website intake, CRM data capture, record creation, and follow-up, slowing response times and making lead activity harder to track.
Designed a website-to-CRM intake workflow using a Real-time Journeys form, Dataverse custom activity records, and interaction tracking for advisory follow-up and reporting visibility.
Reduced manual work by approximately 95%, improved client response time, created cleaner lead capture, reduced errors, and improved follow-up visibility.
- Embedded a Real-time Journeys form on the website as the intake starting point.
- Used custom activity and interactions tables to support structured lead-generation activity.
- Gave the advisory team a cleaner path for follow-up instead of repetitive manual entry.
Lead Capture Architecture
Secure website inquiry workflow
Website inquiries can get lost in inboxes, copied manually into spreadsheets, or tracked without a clean contact history, making follow-up slower and harder to measure.
Designed a lightweight flow from website form to secure backend processing, Azure SQL contact and inquiry records, hCaptcha validation, and Microsoft 365 email notification.
Created a lower-cost, cleaner workflow that captures every inquiry, updates existing contacts by email, preserves message history, and can later extend into CRM, Teams, automation, or BI.
- Used Vercel, Azure Functions, Azure SQL, hCaptcha, and Microsoft 365 SMTP instead of introducing a heavy CRM platform too early.
- Separated contact master records from inquiry messages so one person can submit multiple inquiries without duplicate lead records.
- Kept credentials and database access behind backend services while preserving a simple user experience on the website.
Dataverse Form Logic
Data-entry validation and auto-population
Standard business rules were not enough to control the form behavior users needed, leaving room for missing context, inconsistent records, and manual field updates.
Implemented JavaScript-based model-driven form logic using onLoad behavior to validate values and auto-populate fields where configuration alone was not sufficient.
Improved data completeness, reduced entry errors, created a cleaner user experience, and helped users complete records faster with less manual correction.
- Used JavaScript where form-side business rules could not fully support the needed behavior.
- Guided users through validation and automatic field population during form load.
- Strengthened data quality at the point of entry instead of relying on downstream cleanup.
Azure Data Pipeline
Dataverse-to-SQL pipeline architecture
The existing Skyvia ingestion approach hit platform limits, creating scaling pressure for larger data movement and reporting needs.
Moved the pipeline into the existing Azure environment, using available Microsoft sponsorship credits to transform Dataverse data and load it into Azure SQL.
Processed 100K+ records per cycle, improved reliability, reduced manual work, created a cleaner reporting layer, and controlled cost through the existing Azure environment.
- Re-architected ingestion after the previous tool reached practical limits.
- Focused transformation work on reshaping columns for a cleaner SQL reporting layer.
- Used the existing Azure footprint to improve scalability without unnecessary platform spend.
Supporting Samples
Architecture examples behind the work.
Sanitized samples that support the backend design and reporting infrastructure examples above.
Azure SQL Backend
Service request table design
A normalized backend design for service request management, structured for future Power Apps, BI reporting, and operational tracking.
- Separated request records from reusable category, status, comment, and assignment tables.
- Used foreign keys, unique lookup values, and priority checks to reduce invalid or inconsistent data.
- Added timestamp automation and a reporting-ready SQL view so business tools can consume readable values.
Power BI Gateway
Refresh architecture migration
A migration plan that keeps the analytics pipeline intact while replacing a local workstation dependency with a cloud-hosted gateway path.
- Mapped the current source, ETL, storage, preparation, query, gateway, and service layers.
- Outlined VM provisioning, gateway installation, connector setup, dataset mapping, and refresh testing.
- Included production controls for monitoring, credentials, recovery-key storage, backups, and future gateway clustering.
Lead Capture System
Secure inquiry workflow architecture
A lean intake system that captures website inquiries, validates submissions, stores clean contact and inquiry records, and sends inbox notifications without adding a heavy CRM platform too early.
- Replaced manual follow-up risk with a structured workflow from website form to backend processing, database storage, and email notification.
- Used Vercel, Azure Functions, Azure SQL, hCaptcha, and Microsoft 365 SMTP to keep the solution practical, secure, and lower-cost.
- Created a clean foundation that can later connect to CRM, Dataverse, Teams notifications, automated follow-up, or BI reporting.
Delivery Strengths
Execution that connects business needs, technical quality, and operational continuity.
VerdaStat™ delivery includes stakeholder workshops, workflow design, UAT coordination, releases, documentation, and handoff so solutions stay usable after launch.
Problem Type
Disconnected reporting
When leaders rely on inconsistent reports, manual exports, or fragmented dashboards across teams.
Problem Type
Weak data foundations
When automation, CRM data, or analytics depend on incomplete records, inconsistent fields, or poor controls.
Problem Type
Delivery bottlenecks
When teams need practical implementation help to move from roadmap or concept into working solutions.
Start Building Clarity
Bring reporting, automation, and data engineering work into one focused engagement.
Use this page to frame the initiative or operating problem you want to improve next.
Discuss Your Project
Share the outcome, blockers, and support you need.