DeconstructWorkQueueItem
DeconstructWorkQueueItem — Technical Reference. Overview DeconstructWorkQueueItem is a subflow that runs once per queue item, immediately after it is dequeued. It was introduced during a Blue Prism t…
DeconstructWorkQueueItem — Technical Reference
Overview
DeconstructWorkQueueItem is a subflow that runs once per queue item, immediately after it is dequeued. It was introduced during a Blue Prism to Power Automate Desktop migration to bridge structural differences between the two platforms — specifically in how they handle work queue data.
Rather than rewriting all of the migrated business logic to work with PAD's native queue format, this subflow acts as a translator so the rest of the flow can continue working as originally written.
Why It Exists
Blue Prism and PAD handle work queue items differently. In Blue Prism, dequeuing an item returns a flat table of data (called a Collection) alongside an Item ID. In PAD, dequeuing returns a single object with a JSON payload packed into a text field.
The business logic in this flow was written expecting Blue Prism's "Collection-style" references. This subflow converts PAD's queue output into that format so nothing downstream needs to change.
What It Does
A. Local Queue Storage
PAD doesn't natively track which queue item is currently being worked on the way Blue Prism does. To replicate this, the subflow stores the active item in a local dictionary using its ID as a key. This allows the flow to look it up later when marking it complete or updating its status.
B. Parses the item payload
The queue item's data arrives as a JSON string. The subflow converts this into a structured object so individual fields can be accessed by name rather than manually parsing text.
C. Parses processing metadata
Blue Prism stores Status, Tags, and Exception Reason as separate native fields. These were consolidated into the ProcessingNotes field as JSON during migration. The subflow unpacks these back into discrete, accessible properties.
D. Converts data into a table
Finally, the parsed payload is converted into a single-row data table with the field names as column headers. This matches the Collection-style format the migrated logic expects, allowing it to reference data the same way it did in Blue Prism.
Summary
Question | Answer |
Why maintain a local queue dictionary? | PAD has no native concept of a "currently loaded" item. The dictionary maps the active Item ID to its PAD object so the bot can reference it later for status updates. |
Why is the data in JSON format? | Blue Prism Collections are flat and native. The migration tool serializes them to JSON to fit into PAD's single-field queue payload. |
Why does ProcessingNotes contain a Status field? | Blueprint combines Status, Tags, and Notes into a single JSON blob in the PAD "Processing Notes" field to maintain all metadata |
How did we do?
Exporting Reusable Flows