Maestro: Enterprise Workflow Automation

How can you use Maestro to improve your workflow or system?

Maestro covers the full arc of a business process, from whatever kicks it off to the final record.

A process can start in many ways. Maestro apps are triggered by whatever event actually initiates the work:

• A form submission, when a person needs to apply, request, or submit something.
• A chat message, for conversational assistants and intake bots.
• An API call or webhook, when another system needs to kick off a process.
• A schedule for recurring jobs that run on their own (nightly, weekly, end-of-term).
• A queued message or system event, so a process can react automatically to activity elsewhere.
• A manual start, for workflows an operator launches on demand.

When the front door is a form, it’s a capable one. For the many processes that begin with a submission, Maestro includes a full drag-and-drop form builder:

• Data collection with rich, validated fields, conditional logic that shows or hides questions based on prior answers, and required-field enforcement, so what comes in is clean and complete.
• Document uploads for the files a process needs: transcripts, supporting documentation, signed PDFs, spreadsheets, and more, carried straight into the workflow.
• Digital signatures, both captured directly on the form and, through the DocuSign connector, routed for formal e-signature as part of the process.

However it starts, the trigger initiates the workflow automatically. From there, the process routes, validates, notifies, approves, records, and, where it helps, calls on AI.

It automates the work in between. On a drag-and-drop canvas, a subject-matter expert lays out the routing, the approvals, the integrations with other systems, and the record-keeping. What used to be an email chain and a shared spreadsheet becomes a governed workflow that runs itself and surfaces only the exceptions.

It brings in AI where it adds value. Any point in the process can invoke an AI model, with full awareness of the data flowing through it, to read a submission, extract data from a document, triage or score an item, or draft a recommendation for a human to approve.

It stays operable. Operators monitor every running process, step in on human-in-the-loop decisions, and export the data it collects, all from a single console. And every version of every app is a permanent, reviewable record, so what runs in production is always auditable and reversible.

Why did we build it instead of buying it?

• A runtime we’d own. Their engine runs on infrastructure we have to provision, scale, patch, and monitor. When their runtime is down, our processes are down.
• A black box. Our business logic lives in the vendor’s proprietary database, running on a runtime we can’t see into or audit.
• Lock-in. Getting a process out means an export, if one exists at all.
• A generic fit. The tool was built for everyone, not for how the University actually works.

• No runtime for us to maintain. A deployed Maestro app is a native AWS Step Functions state machine running on managed AWS services, Lambda, API Gateway, EventBridge, and Bedrock for AI. It keeps running even if Maestro’s own design tools are offline, because Maestro was never in its path to begin with. We patch nothing and babysit nothing for a live app to keep working.
• Fully transparent and auditable. Every published version of every app is committed as reviewable plain-text files to version control (Git). A change to a process is a pull request you can read. A rollback is a revert and redeploy. Publishing “fails closed”: if a version can’t be committed, nothing ships and nothing is left in an ambiguous state.
• Ours, on our terms. Maestro runs in our AWS account on our infrastructure. The data, the definitions, and the running apps are ours, with no third-party runtime in the middle.
• Built for the University. It’s shaped by how UMBC’s offices actually operate, and it’s a reusable product across many of them, not one team’s bespoke tool.

What is the technology behind it?

• AWS is the runtime. Every app a user designs compiles to a native AWS Step Functions state machine and runs entirely on managed AWS services. There is no separate workflow engine to host or maintain. The app inherits enterprise-grade durability and elasticity directly from AWS, and DoIT operates none of it.
• Version control is the source of truth. Every published version is committed as reviewable plain-text files to Git. Governance is built into the architecture, not bolted on: what runs in production is exactly what’s in version control, and both are auditable and reversible.
• A single schema authority prevents drift. The form builder, the visual workflow canvas, the compiler, and the cloud executors all derive from one shared, strongly-typed schema registry. The fields a user builds, the logic that runs, and the infrastructure that gets created can never fall out of sync, a class of bug that plagues low-code platforms is designed out entirely.
• A strict, pure compiler. A dedicated compiler translates each visual design into cloud infrastructure. It validates data flow and reachability, verifies that every form field and AI-generated value is actually in scope where it’s used, and refuses to silently skip anything it doesn’t understand. Its output is covered by golden-file tests, so any change to what gets deployed is intentional and reviewed.
• Trigger-aware compilation. The compiler picks the right AWS execution model for the trigger: a fast, synchronous path for live API and chat responses and a durable, long-running path for everything else, and wires up the API route, schedule, or queue the trigger needs, all from the same design.
• AI behind a clean abstraction. Model providers sit behind a pluggable interface, and AI steps run as first-class nodes with confidence gating, structured outputs, and an agentic retrieval-augmented pipeline that lets a model search a curated knowledge base and answer with citations. The platform is model- and provider-agnostic by design.
• Multi-tenant and domain-neutral. Every record is organization-scoped at the database layer by helpers that refuse to build an unscoped query, and no domain-specific concept is hardwired into the core. That’s what makes Maestro a reusable product across many offices rather than one team’s one-off tool.
• Shared, pre-deployed executors. Deploying an app creates only its orchestration, never new application code. A library of shared, parameterized cloud functions handles email, HTTP calls, document generation, data-table operations, AI evaluation, and connectors to external systems (Salesforce, Google Sheets, Box, DocuSign, SFTP, and more), each configured per step rather than rebuilt.

Who is the creator and maintainer of this design?

Jason Paluck, Associate Vice President, Division of Information Technology, designed and built Maestro and continues to lead its development and maintenance.