Confusion About Queue Ownership and Transaction Handling in UiPath Maestro

Help Maestro
1

Hi everyone,

I’m currently building an agentic automation project using UiPath Maestro, REFramework, and UiPath Agents, and I’m a bit confused about the correct architecture when working with queues and transaction ownership.

My current process design looks roughly like this:

  • Dispatcher process:
    • Reads invoice emails
    • Downloads PDF invoices
    • Pushes invoice paths into an Orchestrator Queue

Then inside Maestro I have:

  1. Extraction workflow
  • Gets queue item
  • Extracts invoice data
  1. Validation workflow
  • Validates business rules
  • Calls an Agent if contextual reasoning is needed
  1. Performer workflow
  • Enters data into ERP

My confusion is about how queue ownership should work across these workflows.

At first, I was thinking:

  • The extraction workflow should get transaction items itself
  • Another workflow should set transaction status
  • Then I should create some kind of loop to keep fetching queue items until no more items are available

But now I’m not sure if this is the correct way when using Maestro.

So my questions are:

  1. In Maestro-based architectures, should every workflow directly interact with the queue and transaction items?
  2. Should I simulate REFramework behavior manually (Get Transaction Item / Process / Set Transaction Status)?
  3. Is it recommended to build loops inside the BPMN process to continuously fetch queue items?
  4. Or should Maestro itself orchestrate the transaction flow while workflows simply receive/process data?
  5. What is the recommended enterprise approach for queue ownership and transaction lifecycle management in Maestro?

I’m trying to understand the cleanest architecture and avoid overengineering or misusing queues between workflows.

Thanks in advance!

2

@ziyad_tarek Not sure exactly, but take a look below link and see if this helpful

Happy Automation

3

Hi @ziyad_tarek

I like your approach. I have done quite a bit of work in Maestro over the last few months, and this is my personal approach on the matter.

The real difference between REFramework and Maestro is that in Maestro architectures, orchestration responsibility moves away from individual workflows and into the BPMN process itself. So don’t forget this.

A clean approach is usually having queue’s for system of records for your transactions, Maestro as an orchestration layer, workflows for building/running your executions and then Agents for decision making when needed.

So in your case I would do have a Dispatcher that reads emails, downloads invoices and creates queue items. Then Maestro should orchestrate the lifecycle of each transaction.

The important point is that you generally don’t want every workflow independently owning queue operations. Rather let Maestro retrieve the transaction, passe the payload into activities/workflows, return results/status/data, make a decision on next steps, and then update the transaction status.

That means your extraction workflow should ideally receive invoice data/path as input, extract data and then finally return structured extraction result instead of getting a queue item itself and trying to manage the state and status etc.

Same for validation and performer workflows. You should not try to manually recreate the full REFramework transaction loop inside BPMN unless you have a very specific requirement.

In unattended automations, the REFramework owns transaction orchestration and remains that way always. But in Maestro, “Maestro” becomes the orchestration engine.

What I would do in Maestro is something like this:

  • Trigger Maestro process
  • Maestro consumes queue items
  • Each BPMN instance represents one business transaction
  • Maestro handles routing/escalation/retries
  • Make specific workflows stay stateless and reusable

This gives you way better visibility of the process. It also has easier retry handling and cleaner agent integration etc.

Treat agents as optional decision services, not transaction controllers. The agent should enrich or reason about data, but Maestro should still own process state and transaction progression.

Hope this helps :slight_smile:

4

You absolutely do NOT want to rebuild the Reframework in Maestro. Thats not how it works.

These processes are not transactional, they are linear.
They can still complete a transaction and be tied to a queue, thats honestly not a bad idea, but they are linear.

So your Maestro process, if triggered by a queue item, owns that queue item and is responsible for ending the state in it, the error handling in Maestro is still limited so thats harder.

I would however propose you remove your dispatcher. Maestro is designed to be event driven, so rather than the starting event being a queue item added, the starting even can be an email being recieved, Maestro can read the email and trigger a robot to extract the email data attachment and extract the invoice data, passing that back to Maestro, then the validation workflow etc etc.

The key change I think you need to make is to stop thinking in transactional loops. That benefit only exists when you are using an application you dont want to repeatedly log in and out of and need a recovery workflow.

For Maestro, if you have 100 emails. you have 100 separate jobs, each handling 1 email end to end.
Of course that means it costs $100

5

For now, I’d recommend using Maestro only as the dispatcher / orchestrator, not the performer. Queue transaction ownership belongs on the Performer side today.

A cleaner split for your design:

  • Maestro is the dispatcher and process-level orchestrator. It reads emails, downloads PDFs, pushes invoice paths to the queue, and handles higher-level decisions like branching on validation outcomes, escalating to humans, and calling Agents for contextual reasoning.
  • Performer (REFramework) owns the queue transaction loop: Get Item, Process, Set Status, retries, business exceptions. Extraction, validation, and ERP entry run here.

So to your questions:

  1. workflows shouldn’t each grab queue items
  2. don’t rebuild the REFramework loop inside BPMN
  3. don’t poll a queue from Maestro
  4. one Maestro instance per business case, not per queue item

If you want to skip queues entirely, Maestro is event-driven, so an email trigger can start one instance per invoice with workflows as stateless steps.

6

Whilst I agree in principle, there is perhaps an important role in queue items when it comes to reporting.

Jobs, including Maestro jobs, effectively have a binary end state of either success or failed, which robs nuance when it comes to reporting.
Queue items have better outcomes as they can be at least further categorized into a Business Rule exception or application exception.

I’ve been saying for a few years, jobs need to have more end states we can define in order to enhance reporting.

Maestro is a natural fit for this, but I think the underlying job DTO is what needs to change so both Maestro jobs, agent jobs and traditional RPA can all have in addition to the success fail end state a further defined end Status that can then be visible in tools like Insights.

Lets say I have a Loan Approval process, a favourite to demo in Maestro.
I dont want to consider a loan rejected as a fail, but I would love to be able to set the end state of the job based on that, with fails being reserved for errors.

Queues can help fill this gap to a degree in the meantime, in Orchestration processes I will typically have a queue item associated with the job running in order to facilitate this better reporting and at least show a separation of BRE and exception.

If we can cover this gap, then I 100% agree with what you are saying, and I think using queues in them is confusing as people only really associate them with transactional, Ui based processing, which should not/ can not be done in Maestro and must be delegated to a performer robot by Maestro using queue items to delegate the task, was making this point a year ago to the Maestro team when the product was in its infancy and queue items were not supported yet.

7

i have similar problem. I have created Agent using connector mail trigger to read the email and extract Subject, from and body and the same agent is pushing this info in QUeue. I build second agent who classifies diese emails and gives respone as “Anmelden”, Abmelden" Unbekannt. I am also trying to give queue item input directly to the second agent. i knew that i can avoid queue as i’m using Mail trigger. But to keep a track of the Email that BOT processed, using Queue. How to give Transactionitem.specificcontent(“From”) to second Agent as input.

8

My first question is, whats pushing you towards using Maestro for this? It doesnt sound like a particuarly complex process, nor one that would benefit from the dashboarding Maestro provides? Its gonna cost you $1 per email just for the Maestro flow, then $0.40 at least for the two agents, not even sure the first agent makes sense for extracting the subject etc, why do you need an agent for that?

I feel like the architecture in general should be considered first.

9

@Jon_Smith , You are absolutely right. The process itself is not complex.
Initially, I created an email processing workflow in Desktop Studio to read the incoming emails, extract information such as the subject, content, and sender, and store this information in a Queue Item.
For the email classification step, I built an Agent because the incoming emails have different formats and use different wording. The Agent provides more flexibility compared to a rule-based approach and can better handle variations in the email content.
However, I was not able to pass the Transaction Item input directly to the Agent as intended. After receiving the Agent response, the process triggers two additional workflows for the next processing steps.
I would also like to demonstrate the capabilities of UiPath Agents and Maestro in my company. The demo will show the overall process design, the interaction between workflows and Agents, and how Agents can be used to handle flexible email classification scenarios.
The challenge I am currently facing is passing the Queue Item data as input parameters to the Agent.

10

Ok, if you are just demo’ing Maestro then ok.
I suggest you also look at Long Running Process templates in Studio though and do the equivalent there to compare.

As for your specific issue. Indeed, you cannot directly give a queue item to an agent and expect it to parse it.
You need to either extract each field from the queue item specific content in Maestro, or build a simple linear workflow with a queue item added trigger at the start, you can then comfortably read the queue item details and pass that to an agent which you call in the Studio workflow.

In Maestro you can then make the queue item and wait for it. If you set up some triggers it should get automatically handled by the second, queue item triggered, process.

I am not a fan of this architecture, but if you are just trying to mess around and demo Maestro this is possible.

11

Thanks for your quick reply.

I understand that this is not an ideal architecture. I was trying to find the best way to read incoming emails and provide the email data to the Agent while keeping the processing within Maestro. Since I was not able to find a direct way to pass the email data to the Agent, I considered using the Queue as an intermediate step.

I am aware that the same process can also be implemented using Studio with workflow logic. Thank you for the suggestion regarding the Long Running Process templates in Studio. I will definitely look into those templates and compare the different approaches.

12

Ok, well you can pass the email directly to an agent, in Maestro, if you skip the queue step entirely.

Just use the email trigger to start the flow, then pass the data from that directly to the agent you call.
What part of that were you struggling to do that made you think you need a queueitem?

13

The main reason I was using a Queue was to keep track of the emails the bot has processed and to have an easy way to cross-check them later.

Based on your suggestion, I’ll instead use the email trigger to start the Maestro flow and pass the email directly to the agent. I’ll then log the processed email information to an Excel file for tracking and auditing.