GDP-Compliant Automated Complaint Handling with Humans in the Loop

Inspiration

In pharmaceutical wholesale distribution, a customer complaint about a medicine shipment is never just a support ticket. Under EU Good Distribution Practice (GDP, 2013/C 343/01, Chapter 6), every complaint is a regulated event: it has to be investigated, root-caused, and resolved with a documented, auditable disposition. Get it wrong, and you are looking at a compliance breach and, potentially, a patient-safety risk.

Today that work is mostly manual. Staff read emails, look up orders and batches across disconnected systems, judge severity, and route each case by hand. It is slow, inconsistent, and hard to audit.

We wanted to find out whether agentic automation could take on the heavy lifting without ever taking a regulated decision out of human hands. The guiding principle was simple: agents and robots do the work, humans make the decisions, and the audit trail is built in by design, not bolted on afterward.

What it does

The system drives a complaint from inbound email to closed case, end to end:

Intake. An email arrives. A robot fetches it, processes any attachments (storing photos and extracting delivery-note data), and an AI agent extracts the structured details and classifies the complaint into one of four GDP categories: quantity discrepancy, cold-chain (temperature) deviation, quality deficit, or other.
Triage. A Customer Service reviewer validates the extracted data and decides: proceed, request more information (a robot emails the customer), or mark it as "not a claim" and close the case.
Investigation. In parallel, robots gather sales-order evidence from the ERP and temperature logs from a cold-chain portal. An investigation agent reasons over the evidence and suggests a disposition and a finance direction. It never decides.
CAPA (Corrective and Preventive Action). A Quality Assurance reviewer approves which steps may run. Robots then execute in the ERP: adjust inventory, post a credit or debit note, and close the record.

A key compliance guarantee is structural: the agent is built so it can never recommend destruction. Goods that cannot return to stock go to quarantine first, and any irreversible step waits on a named human.

The whole lifecycle is monitored through a custom GDP Complaint Tracker app, and the case state is a single Data Service record whose Gate field acts as the state machine.

How we built it

We built the solution as a BPMN flow on UiPath Maestro, combining several parts of the platform into one orchestration:

Maestro BPMN as the long-running orchestration spine, with parallel and exclusive gateways and event-driven waits for the human gates.
Data Fabric / Data Service as the single source of truth and the case state machine.
Agent Builder: two purpose-built low-code agents (extraction/classification and investigation), each grounded in GDP Chapter 6.
Integration Service (Outlook 365) for email intake, Robotic Process Automation for deterministic execution against the mock ERP desktop app and the cold-chain portal, and IXP for document extraction.
A Coded Web App (React + TypeScript) as the human-in-the-loop cockpit.

We developed the project agentically, using Claude Code as our primary build environment alongside Visual Studio Code and UiPath's tooling. Claude Code authored and validated large parts of the orchestration logic, the agent prompts, the RPA workflows, and the cockpit app, while we kept the regulated design decisions and the final platform wiring firmly in our own hands.

Challenges we ran into

Our biggest challenge was a pivot. We designed the full solution in Maestro Case first. This was not a beginner bouncing off a hard tool: we authored a complete, expert-level case definition with an eight-stage regulated lifecycle, four personas with distinct permissions including e-signature, a Responsible-Person disposition gate, an independent destruction backstop, cross-case correlation, and decision tables for the fail-closed GDP logic.

The design was sound, but we hit a series of platform walls: slow and fragile build/deploy round-trips, a publish footgun that silently re-registered our gate app and faulted every human gate, tooling that could not surface agent-type processes (forcing a manual split between the CLI and the UI), intermittent runtime stalls and duplicate instances on long-running cases, and opaque gate data binding.

So we moved the same design to Maestro BPMN, where the model was more transparent, the deploy cycle faster, and the human-gate pattern predictable. We shipped a working end-to-end solution in BPMN that we could not get stable in Case in the time we had.

A second recurring challenge was the amount of manual setup required to go from "built" to "running": establishing connections via OAuth, registering event triggers, binding agents, and regenerating schemas, all spread across the CLI and the UI with handoffs we had to reverse-engineer by hitting walls.

What we learned

Designing for compliance is a discipline of its own. A flow that validates and runs can still violate GDP. We learned to make data integrity (the ALCOA+ principles) a property of the architecture, not an afterthought, and to keep the "agents suggest, humans decide" boundary structural and explicit.
Deploy first, perfect later. The platform's behavior on the live tenant is the real source of truth. Getting something deployed and proven beat refining a model offline.
Separate reasoning from execution. Letting agents extract and recommend, while keeping decisions in decision logic and human gates, made the system easier to test and far easier for a regulated reviewer to trust.
Choose the right orchestration model early. Knowing when a process belongs in Case versus BPMN would have saved us our largest detour, and it became some of the most useful feedback we could give UiPath.

Built with

UiPath Maestro BPMN, Data Fabric, Agent Builder, Integration Service, Coded Web App, Robotic Process Automation, IXP, Claude Code, Claude Opus 4.8, Outlook 365, a mock ERP desktop application, and a cold-chain portal.