Master Data Architect Agent
A chat-driven workflow and activity designer that turns lifecycle rules into running processes — manual approvals, conditional branches, parallel reviews, automated integration calls, and the user-defined code that fills the gaps. The Design Agent shapes the data; the Architect Agent shapes how the data moves.
Why workflow design has been the second bottleneck
Once the canonical model is settled, the next thing every MDM program gets stuck on is the lifecycle: who approves what, in what order, with what SLA, and what fires off to which downstream system on completion.
The work is fiddly because workflows have a lot of moving parts:
What makes workflow design heavy
- Seven or eight activity types with very different semantics
- Branching logic that depends on attribute values, prior activity results, or role assignments
- Parallel branches, joins, rework loops, and timeouts
- Lifecycle hooks at six points around every activity for pre-checks, computed defaults, and side effects
- Dozens of external-system integration calls (SAP, Coupa, Salesforce, Databricks, Kafka, REST…) each with their own auth, schema, and error modes
- Gaps that no canned function fits — the moments where you need a few lines of custom code, not another configuration screen
The traditional answer was a workflow specialist hand-editing XML in front of a business analyst describing the process. The Architect Agent collapses that into one conversation: business owner describes the process, agent generates the activities and wiring, both sides watch a visual canvas update as decisions land.
From rules to running processes, in conversation
The Architect Agent picks up where the Design Agent finishes. It reads the canonical model the business already approved — classes, attributes, valuesets, validation rules — and asks what the lifecycle needs to look like. As you describe rules, it lays down activities on a canvas, wires the transitions, and configures the details.
Start(ProcessStart) — requester fills the Vendor formProcurement Review(Other,Actors=ProcurementLead,PossibleResults=Approve,Reject)EHS Review(Other, conditional onHazmatClassset,Actors=EHSOfficer, parallel to step 2)Rework(DataPreparation, conditional on any Reject,GoToback to Procurement Review on completion)Push to SAP(ExternalFunction,RunInBG, callsSAPBAPIFunction · BAPI_VENDOR_CREATE1)Notify Requester(ExternalFunction,RunInBG, callsEmailFunction)
CompleteCond=AllPerformers. SAP push is wrapped with StopOnAutoErr so a failed call pauses for human review. Canvas is rendering on the right — what should I adjust?
EHS Review now has TimeoutInterval=172800 with escalation chain EHSOfficer → EHSDirector. For the ID mapping I've inserted a PreFunction2 hook on Push to SAP that runs a UserDefinedCode snippet — drafted from your 6-char-prefix rule. Want to review the snippet in the activity detail panel, or should I run it against your sample data first?
The visual workflow canvas
Every change in the conversation lands as a node or wire on a canvas. You see the flow before you read the configuration.
Rework loop returns to Procurement Review on completion. EHS Review activity self-skips when HazmatClass is not set.
- ActorsEHSOfficer
- Conditional
HazmatClass in (1,2,3,4) - PossibleResultsApprove, Reject, RequestInfo
- CompleteCondAnyPerformer
- UpdateAttrsHazmatPermitNumber, EHSNotes
- ReqdAttrsHazmatPermitNumber
- TimeoutInterval
172800(48h) - EscalationEHSOfficer → EHSDirector
- SkipIfOwner
true - TransitionsPushToSAP (Approve), Rework (Reject), Start (RequestInfo)
Click any node and the activity detail panel opens. The panel is the same surface the agent uses to write configuration — what the agent sets, you can review and adjust without touching XML.
The seven activity types the agent understands
Workflows are built from a small fixed set of activity types. The Architect Agent knows when each fits, and what the right details are for the role each plays.
ProcessStart
Exactly one per workflow. Owns the initial form. The requester fills process attributes and kicks off the flow.
Other (manual)
Standard human task — review, approve, classify. Result buttons (Approve / Reject / Send back) feed downstream branching.
DataPreparation
Data-entry task. Auto-renders a form from UpdateAttrs / ReqdAttrs. Used for filling, enriching, or correcting attributes.
ExternalFunction
Automated step. Runs in the background, calls a Special Function (SAP BAPI, Coupa sync, REST call, S3 upload, Databricks query, custom code…). Seventy-plus built-in functions available.
SubProcess
Calls another workflow as a single step. Used for reusable building blocks: approval-chains, document-collection, dependency-checks.
Wait
Pauses the flow for a fixed interval or until a condition is met. Often paired with a TimeoutResult so the flow advances on expiry.
GoTo / Conditional
Branching and rework loops. Conditional activities self-skip when their condition is false. GoTo jumps back to a named earlier activity.
Roles & Actors
Not an activity type, but every activity has actors. The agent generates role rows, assigns actors, picks CompleteCond (AnyPerformer / AllPerformers / Majority), and adds SkipIfOwner guardrails.
Special Functions — how the workflow reaches outside the platform
An ExternalFunction activity is the workflow's mouth. It calls a Special Function: a packaged, reusable connector to something outside ZFlow. The platform ships seventy-plus Special Functions; the Architect Agent picks the right one for what you described, configures its inputs, and wires the failure mode.
Call any SAP BAPI; auto-discovered via BAPI Designer
JSON / XML / form / CSV; six auth schemes
Supplier and PO sync to Coupa
Object CRUD + bulk via Salesforce REST
Run a SQL query, parse rows into attributes
Same shape for Snowflake
Oracle / SQL Server / MySQL: select / insert / update / delete
Emit an event to a configured topic
Push a file to S3 with signed-URL response
Read / write SharePoint / Graph API
Templated email with attachment support
Post to a channel with rich blocks
Run a sandboxed Python script with attribute I/O
Call an LLM step with prompt + structured output
Classify an uploaded document via RAG + LLM
Partial list. The full catalog is browsable in the agent's tools panel; the Architect Agent only proposes a Special Function once it has confirmed the configured target system exists and the credentials are present.
For each Special Function call, the agent configures four things
- The target. Which configured external system (a specific SAP destination, a named REST endpoint, a Snowflake warehouse).
- The payload. Which process attributes map to which input fields. The agent reads the canonical model and the target's schema, proposes the mapping, and asks you to confirm edges it isn't sure about.
- The response handling. Which return fields write back to which attributes (e.g. SAP
LIFNR→ ZMDMSAPVendorID). - The failure mode.
StopOnAutoErrto pause for a human, retry policy, fallback Special Function, or compensating activity.
UserDefinedCode — when no Special Function fits
Most steps are covered by the catalog. The ones that aren't — a peculiar ID-mapping rule, a one-off calculation, a payload reshape the canned adapter doesn't quite do — are handled by UserDefinedCode. The Architect Agent treats UserDefinedCode as a first-class option.
When the conversation calls for logic that no Special Function captures cleanly, the agent drafts the snippet, shows it in the activity detail panel, and asks you to review.
UserDefinedCode runs in a controlled environment with declared attribute inputs and outputs. No filesystem, no arbitrary network calls — if you need those, you wire a Special Function instead.
The agent writes the snippet from the rule you described, in the conversation, with comments tying each line back to your words. You see exactly what it intends to do before you approve.
The activity detail panel shows the snippet inline. Edit it in the panel, and the change is captured as part of the workflow template — no external repo, no separate deployment.
The agent will run the snippet against sample input you supply and show the output before you commit. Test, redirect, repeat — in the same chat.
The escape hatch matters because the real world doesn't fit catalog shapes. ZMDM's promise is that you can stay in the chat when the canned path doesn't quite fit — the agent drafts code, you review, the workflow keeps moving.
Lifecycle hooks — the six moments around every activity
Every activity has six hook points the agent can wire. Most workflows use only a couple. The agent picks the right hook for the rule you described.
PreFunction
Before the activity is offered to actors. Compute defaults, set conditional visibility.
Start
When an actor opens the activity. Stamp a started-by user, fetch live data.
Action
On each save while the actor is working. Run mid-form validations.
PreFunction2
Right before complete is allowed. Map IDs, transform payloads.
Complete
Activity is finished. Record outcome, snapshot data.
PostFunction
After complete, before the next activity is staged. Side effects, notifications.
Hooks can call a Special Function or run UserDefinedCode. The agent prefers Special Functions when one fits and only drafts code when none does.
The patterns the agent generates by default
Most lifecycle requirements collapse into a handful of recurring shapes. The agent recognises them and reaches for the established pattern instead of building from scratch.
PossibleResults=Approve,Reject. Reject branches to a DataPreparation step that loops back. Used in almost every onboarding flow.CompleteCond=AllPerformers. Used when independent reviewers must each sign off.ExternalFunction activities with RunInBG, gated by StopOnAutoErr. Users watch them tick through; a failure pauses for human inspection.TimeoutInterval + escalation chain. After expiry the actor list expands or the activity completes with a timeout result.What happens when you approve
When you accept the proposed workflow, the agent commits it as a workflow template (the same XML shape ZesatiExport > Template the platform uses everywhere). The template is immediately live in the design environment: start a test instance, walk it as an actor, confirm the experience matches what the canvas showed you.
The Quality Agent and the Steward Agent — agents 3 and 4 of the ZMDM team — both attach to workflows the Architect Agent generated. The Quality Agent registers checks against the right attributes at the right activity. The Steward Agent registers itself as an eligible performer on activities where you've allowed agent-completion. No separate plumbing.
30 minutes, end to end
Bring a workflow you've already implemented elsewhere. Watch the Architect Agent rebuild it — start to finish, with a working test instance at the end.
CompleteCond to AllPerformers, approve the rest.
SAPBAPIFunction and pre-mapped fifteen of seventeen fields from the model. Two it asks about — one is a legacy quirk only you know, the other needs the 6-char-prefix mapping rule. You explain the rule; the agent drafts a UserDefinedCode snippet in a PreFunction2 hook and runs it against three sample records. Two pass, one fails on an edge case. You refine the rule; the agent updates the snippet; all three pass.
PostFunction hook calling SlackFunction with a templated message.
What the Architect Agent doesn't do (yet)
Honest scope. Some of the items below are short roadmap items; others are deliberate decisions about what the agent should leave to humans.
- Cross-workflow dependency analysis The agent doesn't yet warn that changing Supplier's "Push to SAP" activity will affect three other workflows that call it as a SubProcess. Cross-template impact analysis is on the roadmap.
- Live workflow refactor The agent generates and edits templates. Migrating in-flight process instances to a new template version is a steward decision; the agent proposes a migration strategy but does not execute it autonomously.
- Generic visual canvas editing You can review and approve activities from the canvas, but freeform drag-rewire of an existing complex workflow still happens in the existing mxGraph designer. The agent meets you in chat; the canvas is its drawing surface, not yet a full editor.
- Performance modeling The agent reasons about correctness, not throughput. It will not yet tell you that a synchronous SAP call in a high-volume bulk-load flow will be your bottleneck.
If any of these are deal-breakers for your first workflow, tell us before we start — several are short roadmap items.
How it fits with the rest of ZMDM
The Architect Agent is the second of five. It consumes what the Design Agent produced and feeds the three runtime agents that follow.
Design
Canonical model + lifecycle workflows
Architect
Workflow templates + integration wiring
Quality
Match rules + completeness + enrichment
Steward
Activity execution alongside human stewards
Expert
Grounded answers from live entities + lineage
- It consumes the canonical model from the Design Agent — classes, attributes, valuesets, validation. Workflow templates reference the model directly; the agent never reinvents schema knowledge.
- Its output feeds the Quality Agent — checks are registered against attributes at the right activity (duplicate detection at the data-preparation step, completeness check before approval).
- Its output feeds the Steward Agent — activities marked as agent-eligible get the Steward Agent registered as a performer alongside humans, governed by the same approval and escalation rules.
- Its output feeds the Expert Agent — lifecycle history, audit, and lineage are emitted by the workflow engine. The Expert Agent answers questions against that history.
Start Your Success Story
Join the growing list of manufacturers who have transformed their master data management with ZMDM.