I have kind of a peculiar requirement from my client. They want to use queues as process output, rather then input, but not for another BOT to pick up, like a dispatcher / performer scenario, but to be picked up by a Snaplogic process via the Orchestrator API. The alternative is creating a CSV file in a shared location / orchestrator storage bucket. What are the pros / cons of each approach as you see it and what are your overall opinions on this matter? I have never heard of such a solution in my 5-6 years of working in UiPath, so if you can point me to other similar forum posts / solutions available in the UiPath community, that would also be beneficial.
Using Queues as an output is unusual, but it’s not necessarily a bad design if the output represents business transactions.
Pros of using Queue
Built-in audit trail and transaction history.
Easy for SnapLogic to consume via the Orchestrator API.
Supports filtering, references, status, and metadata.
Better traceability than flat files.
Cons:
Queues are primarily designed for transaction processing, not as a general data store.
Adds API and Orchestrator dependency.
May be overkill if the only requirement is to transfer data.
If SnapLogic only needs to consume exported data without requiring queue features like retries, statuses, or tracking, then Orchestrator Storage Buckets (or a database/object storage) would be a cleaner approach than using queues or shared CSV files.
Overall, I would choose the solution based on the business requirement. If auditability and transaction tracking are important, queues are a valid option. If it’s simply data exchange, Storage Buckets or another storage solution would be more appropriate.
there are also other alternates also recommended by UiPath (from talks with their product developers / product team) e.g. using Data Fabric ( Data Service).
Coming back to “using queue items”: Some main intents like reflecting the incoming transaction data, retry concept … are not fully used. From the technically side it can be used to reflect the transaction data processing. And in scenarios like e.g. onprem Orchestrator / no Data Service availability such an approach can be used to hold the data with the inbuild functionalities. Escpecially when the processed records will be postprocessed e.g. reporting …
However, when designing such an approach it also recommend the check the Orchestrator Rate Limits as it touch the API retrieval for fields like specific content / output …
I think you can try to use Queues as output only if snapLogic needs record-level data with auditability, retry capabilities, and status tracking via the orchestrator API. If the requirement is simply to hand over processed results in batches, a CSV file or Storage Bucket is usually simpler and more appropriate. Queue-as-output is technically valid, but file-based output is generally the cleaner design unless item-level orchestration is specifically required.