Drilling Fluids Lab Application

Overview

The Drilling Fluids Lab Application is a laboratory information management system built to modernize and centralize the workflows of a drilling fluids laboratory. I designed and developed it to replace legacy Microsoft Access databases and manual, fragmented processes with a web-based application that could support formulation work, laboratory request handling, test tracking, reporting, analytics, administration, and operational lookup workflows in a single environment.

This was not a narrow dashboarding project or a simple database front end. It was a broad internal business application designed to support the day-to-day operational reality of a laboratory that needed more reliable systems, better accessibility, stronger workflow tracking, and tighter integration with enterprise infrastructure.

At its core, the application was a modernization effort. It moved a set of lab-critical processes out of brittle desktop-database and manual environments and into a centralized cloud-based platform that could scale more effectively, support role-based access, and provide a stronger foundation for future development.

Context

The laboratory relied on a combination of legacy systems, manual workflows, and disconnected data sources to manage requests, formulations, testing data, reference information, reporting, and project-level visibility. That type of setup can work for a while, but over time it creates growing operational friction: desktop dependencies become limiting, workflows become harder to track, reporting becomes more manual, and the system becomes more difficult to maintain.

The organization needed a way to digitize and centralize core laboratory processes without losing the domain-specific functionality that users depended on. That meant the application had to do more than store data. It had to reflect how the lab actually operated across multiple workflow areas, including request intake, project review, formulation search, chemical reference management, analytics, reporting, and administrative controls.

The Drilling Fluids Lab Application was built to solve that problem by creating a single internal system that could support the full lab workflow lifecycle while integrating with broader enterprise data and identity systems.

Problem

Before the application was in place, several structural problems limited the effectiveness of laboratory operations:

• Important workflows depended on legacy desktop-database systems
• Request handling and status transitions were harder to track in a structured way
• Formulation and testing information was not centralized in a modern application experience
• Reporting and document generation required more manual work than necessary
• Operational, chemical, and laboratory data lived across multiple systems
• Access control and user management needed to align more cleanly with enterprise identity infrastructure
• Stakeholders needed better self-service visibility into laboratory activity and project status

These issues created both technical and operational risk. Legacy systems are harder to maintain, harder to scale, and more fragile in environments where multiple users, structured approvals, and evolving business needs are involved.

Objective

The objective of the Drilling Fluids Lab Application was to build a production-ready internal platform capable of supporting:

• Laboratory request intake and lifecycle tracking
• Drilling fluid formulation management
• Chemical database and inventory workflows
• Project-level search, filtering, and administration
• Analytics and dashboards for internal and external stakeholders
• Equipment and calibration tracking
• Report and document generation
• Role-based administration and permissions
• Integration with enterprise authentication, email, data storage, and analytical systems

The application needed to be practical, accessible, maintainable, and broad enough to cover the core operational needs of the lab without forcing users to jump between disconnected tools.

What I Built

I built a cloud-based laboratory information management system with a Flask-based architecture, Azure-hosted infrastructure, multi-database integration, and a wide range of workflow-specific features supporting both lab users and administrators.

At a high level, the system included request workflows, formulation management, chemical and inventory capabilities, analytics, project-level views, equipment tracking, reporting, and administration.

Laboratory Request Workflow

I built a full request lifecycle system for lab work, allowing requests to move through structured submission, review, approval or denial, technician assignment, and status tracking processes. This included support for:

• Structured request submission
• Workflow state changes
• Assignment and ownership tracking
• Approval-chain style process handling
• Excel import support for bulk request intake
• Supporting organization of request-related files and folders

This part of the system was important because it replaced more fragmented and informal request handling with a trackable digital workflow.

Drilling Fluid Formulation Management

A major functional area of the application was formulation management across multiple fluid system types. I built support for:

• Oil-based mud and invert system formulations
• Water-based mud formulations
• Field formulations tied to active operations
• Multi-criteria search and comparison workflows
• Exportable outputs for formulation-related data

This allowed lab users to move beyond static or hard-to-query records and interact with formulation information in a more flexible and operationally useful way.

Chemical Database and Inventory Workflows

The application included a searchable internal catalog of chemicals and related materials, including support for different additive categories and inventory-oriented workflows. I built features supporting:

• Searchable chemical reference information
• Dry and liquid additive tracking concepts
• Base oil and weighting material organization
• Bin management for physical storage workflows
• Barcode generation for labeling support

This helped connect digital records more directly with the practical needs of inventory organization and physical lab operations.

Analytics and Dashboards

I built analytics and dashboarding capabilities to provide users with visibility into laboratory activity, efficiency metrics, project trends, request characteristics, and related reporting views.

These dashboards pulled from both structured operational databases and analytical warehouse data, giving users better access to summarized information without requiring direct database querying or separate reporting tools.

This analytics layer was important because it gave managers and stakeholders a more self-service way to understand what was happening in the lab.

Project Management and Search

The application included a broad project overview experience where users could search, filter, sort, and navigate projects using multiple criteria. This supported:

• Technician-based filtering
• Status and priority filtering
• Project and client lookups
• Project duplication workflows where appropriate
• Easier navigation across active and historical work

This helped the application function not just as a request tool, but as a broader project-level operating system for the lab.

Equipment and Calibration Tracking

I also built support for asset-related workflows involving laboratory equipment, calibration schedules, and related summaries.

This allowed the system to cover not only request and project data, but also a portion of the operational infrastructure needed to support laboratory quality and readiness.

Reporting and Document Generation

The application included reporting workflows capable of generating documents in multiple formats, including spreadsheet, Word, and PDF outputs. These features supported:

• Report generation for lab and operational workflows
• Template-driven document output
• File browsing and template access
• Export-ready structured outputs for internal use

This helped reduce manual reporting effort and gave users a clearer path from lab data to usable deliverables.

Administration and Role Management

I built an administration layer to manage core reference data and support role-based operational control within the application. This included:

• Admin interfaces for managing chemicals and related reference records
• Rig and well lookup support
• Azure AD user and group management workflows through Microsoft Graph integrations
• Application role handling for different user classes

This was important because enterprise internal systems need maintainability and controlled governance, not just user-facing features.

Email Notification Workflows

The application also supported automated email notifications through Microsoft Graph, enabling status communication and workflow-triggered updates within the Microsoft ecosystem already used by the organization.

System Architecture

Architecture and Design

From an architectural perspective, the Drilling Fluids Lab Application followed a server-rendered Flask design with modular organization around feature areas, shared utilities, externalized SQL queries, and integrated authentication and storage handling.

Although the application was broad in scope, the architectural approach favored simplicity in deployment and practical maintainability. Rather than splitting the system into a separate frontend application and multiple services, I built it as a monolithic web application with modular internal organization. This kept the deployment model simpler while still allowing the system to support a wide range of workflows.

One of the most important design choices was externalizing SQL queries into organized files rather than embedding them directly in application code. This created better separation between Python business logic and data access logic, and it made the system easier to maintain across its different feature domains.

The application also relied on reusable utilities for query building, Excel parsing, storage browsing, security logic, and shared data-handling concerns, which helped keep the system more coherent despite its breadth.

Data and System Integrations

A major part of the project's complexity and value came from its integration across multiple data and storage systems. The application connected to:

• Azure SQL databases for core lab, chemical, and operations data
• Databricks SQL for analytical and business-intelligence-oriented queries
• Azure Blob Storage for uploads, documents, and downloadable files
• Azure Data Lake Storage Gen2 for report templates and organized storage structures
• Microsoft Graph for email notifications and directory-related integrations
• Azure AD for authentication and role-based access control

This allowed the application to serve as a central interaction layer across multiple enterprise systems rather than functioning as an isolated lab-only database front end.

Authentication and Authorization

The system used Microsoft-based identity infrastructure through Azure AD and MSAL to support secure sign-in and role-aware access. Authorization was structured around group-based roles and custom access rules, allowing different user types to interact with the system in ways appropriate to their responsibilities.

This was especially important because the lab environment included multiple user classes with different operational needs. Some users needed manager-level controls, some needed day-to-day lab functionality, and some needed more limited or external-facing access patterns.

Session handling was designed to support practical application use in both development and production environments, while keeping the authentication model aligned with the broader enterprise ecosystem.

Frontend and User Experience

The application used a server-rendered frontend with modern JavaScript enhancements and utility-first styling. The user experience was designed around practical internal workflows rather than decorative interface patterns.

A major theme of the UI design was giving users ways to work with complex laboratory and project data efficiently. That included:

• Searchable and filterable tables
• Enhanced dropdown and selection workflows
• Spreadsheet-like data entry interactions
• Export and reporting paths
• Barcode support for operational use
• Responsive layouts for day-to-day usability

The emphasis was on making the system effective for the actual work being done in the lab, not merely presenting a polished shell around database records.

Deployment and Operations

I containerized the application and deployed it using Azure Container Apps, creating a more reliable and scalable hosting model than the desktop-database environment it replaced.

The system was packaged with Docker-based builds and deployed as a cloud-hosted web application with enterprise authentication integration. This enabled a more modern operational model with:

• Centralized hosting
• Improved accessibility from different environments
• Easier deployment consistency
• Better alignment with cloud-native infrastructure practices
• Reduced dependence on local desktop installations and file-based system fragility

This shift from desktop-bound legacy tooling to centralized cloud deployment was a major part of the project's value.

Modernization Strategy

One of the defining aspects of this project was that it was an explicit modernization effort.

The application did not emerge in a vacuum. It was built in the context of existing legacy workflows and prior desktop-database logic that had to be understood, preserved where necessary, and re-expressed in a more modern system. That required translating older patterns into a new architecture without losing the operational functionality users depended on.

This kind of migration work is often harder than greenfield development because the challenge is not just to build something new. It is to preserve institutional process knowledge, improve reliability, reduce friction, and create a system that users can actually adopt in place of legacy habits.

My Role

I was responsible for the design and development of the application across its major technical and workflow layers. My role included:

• Application architecture and workflow design
• Backend development in Flask
• Integration with Azure SQL, Databricks, storage systems, and Microsoft services
• Formulation, request, reporting, analytics, and administration feature development
• Authentication and role-based access implementation
• Document generation and export workflows
• Operational modernization of legacy lab processes
• Deployment and production-hosting design

This was a broad ownership role that combined software engineering, data integration, workflow design, and modernization strategy.

Technical Scope

The project involved a wide technical surface area, including:

• Python and Flask for backend development
• Azure SQL and Databricks integration
• Azure Blob Storage and Data Lake integration
• Azure AD and MSAL for authentication
• Microsoft Graph for notifications and user/group workflows
• Server-rendered templates with JavaScript-enhanced frontend interactions
• Reporting workflows across Excel, Word, and PDF
• Spreadsheet-like data entry components
• Docker-based deployment to Azure Container Apps
• Operational support for laboratory, chemical, project, and administrative domains

The breadth of the system is part of what makes it significant. It was not a narrow feature build. It was a full internal platform for a specialized business function.

Key Engineering Themes

Legacy Modernization

The application replaced fragile, aging desktop-database workflows with a centralized web-based system built for broader access and longer-term maintainability.

Workflow Digitization

Many workflows that had previously been manual, email-driven, or difficult to track were converted into structured digital processes with clearer status handling and operational transparency.

Centralization Across Domains

The system unified laboratory, chemical, operational, analytics, reporting, and administrative functions into one application.

Maintainable Data Access Design

Externalized SQL queries and organized feature domains helped keep the system more maintainable as it expanded.

Enterprise Alignment

Authentication, permissions, storage, email notifications, and deployment were all aligned with enterprise Microsoft infrastructure rather than bolted on as afterthoughts.

Outcome

The Drilling Fluids Lab Application modernized laboratory operations by replacing legacy desktop workflows with a cloud-based internal system that supported request intake, formulation management, project search, analytics, reporting, administration, and operational tracking.

The application delivered value through:

• Stronger structure and visibility for lab request workflows
• Centralized access to formulation, testing, and chemical information
• Improved self-service analytics and project-level visibility
• Reduced manual effort in reporting and document generation
• Tighter integration with enterprise identity, email, and storage systems
• A more scalable and maintainable foundation for future laboratory workflow development

Why This Project Matters

This project matters because it reflects the kind of engineering work that has real operational impact: taking a specialized business function with legacy tools and fragmented workflows and turning it into a centralized, maintainable, production-grade system.

It also highlights an important strength in my work: building software that sits at the intersection of operations, data, workflow design, and enterprise systems integration. This was not just an exercise in rewriting a legacy tool. It was an effort to improve how the laboratory functioned day to day, how users interacted with information, and how the system could grow over time.

That same pattern is highly relevant in healthcare and other process-heavy industries. Many high-value systems are internal workflow platforms that need to manage requests, approvals, records, reporting, permissions, and operational visibility in a structured and dependable way.