DeconstructWorkQueueItem

deconstructworkqueueitem is a blueprint generated subflow that runs once per queue item, immediately after it is dequeued it was introduced to bridge structural differences between blue prism and power automate desktop in how work queue data is handled — allowing migrated business logic to continue working as originally written without rewriting every downstream reference why it exists blue prism and pad represent work queue items differently blue prism — dequeuing returns a flat collection (table of data) alongside an item id pad — dequeuing returns a single object with a json payload packed into a text field the migrated business logic was written expecting blue prism's collection style references deconstructworkqueueitem converts pad's queue output into that format so nothing downstream needs to change what it does a local queue storage pad has no native concept of a "currently loaded" queue item the way blue prism does this subflow stores the active item in a local dictionary using its id as the key, so the flow can 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 parsed manually from text c parses processing metadata blue prism stores status, tags, and exception reason as separate native fields during migration, these are consolidated into the processingnotes field as json this subflow unpacks them back into discrete, accessible properties d converts data into a table the parsed payload is converted into a single row datatable with field names as column headers this matches the collection style format the migrated logic expects, preserving the original data access patterns common questions why maintain a local queue directory? pad has no native concept of a "currently loaded" item the dictionary maps the active item id to its pad object so the flow can reference it later for status updates why is the data in json format? blue prism collections are flat and native blueprint serializes them to json to fit into pad's single field queue payload during migration 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 preserve all metadata in one place