From an optimisation standpoint, using the tags field for storing exceptions is generally a bad idea as it allows for too much variance. Any potential fail point could result in a new tag being created (and tags are permanently stored in the database, even if the work queue item it was generated from is removed). The more tags you have, the longer it may take for a lookup query. It's best to keep them as generic as you are able to within your process, in such a way that yields high reusability of the same string. (Likewise, from a data security standpoint, this is slightly more secure as both the status and tag fields are typically unencrypted. (Fewer rows, easier to clean.))
While you can leverage all available fields tied to work queue items to generate dynamic reports, it's not recommended based on personal experience. You can get away with doing summary tables during off hours, but querying the BP schema directly with queries complex enough to generate useful report data can throttle your environment. If you're trying to generate reports (which I'm only assuming is the case at this point, I may be wrong), you're better off writing to an external database somewhere.
As for retries and tags, per the attached image, it appears custom tags are typically maintained. The exception tag seen below was generated by me right-clicking the work queue item and marking it as an exception. It was then removed when I forced a retry.
------------------------------
Ami Barrett
Automation Developer, Team Lead
Blue Prism
Plano, TX
------------------------------
While there's not an action in the Work Queue object to remove all tags, since tags can be modified without locking an item, you can create your own action to handle it. Here's an example of one such action. Split Text points to the action in Utility - Strings and splits on a semi-colon. Get Item Data and Untag Item are both Work Queue actions.
One thing I would point out is if you needed to tag the work queue items with something aside from the "StepX" stuff, then this would potentially cause a problem with that. I'd personally recommend adding some kind of filter that lets you clear specific tags, for example maybe only clear the tag if it starts with "Step".
As far as the sequence issue goes, I don't think there's a good way to store that kind of information in the work queue. You could have an additional collection in the item data that contains the steps completed, but depending on how you are reporting on it, that could be problematic to pull it later. If you want to stick with the work queue tags, I'd add some sort of logic in your reporting piece so it can understand how to order the tags properly.
What I personally do as far as reporting goes, I tag items with a "Type" tag (like Type: Imported, or Type: Failed to Get Data). On each process, whenever a work queue item is completed or exceptioned, it tags it with a type based on which branch of the process it went down (it has to remove the old Type tag first). That way on more complicated processes where a simple success/failure doesn't exactly indicate what the result was, it can tag the item with a type. Using that type, I can know what branch the process went down. Rather than reporting on the specific actions taking place in the process, it reports on the endpoint, which gives me enough information to know what logic the process branched into to get to that point. The advantage of this is I can reconstruct the steps that were executed during the process by merit of which endpoint it reached, and it's much simpler to implement since I only need to think about it whenever I have a Mark Completed / Mark Exception stage (I created a wrapper around the Work Queues object to further reduce the number of actions that processes have to call).
------------------------------
Nicholas Zejdlik
RPA Developer
------------------------------
