Skip to main content

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…

Sean Ellner
Updated by Sean Ellner

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

Contact