Edit Specific Data for a Queue Item

@Enterprise Would you need this or for traceability is better to create a new item with the same Reference?

If changes are reflected in ‘History’, I see nothing wrong as having them editable.

image

This would logically be scope to Edit privilege on queue I guess?

Cheers

7 Likes

This will help us to add Review as well, Sometimes few queue item will Fail and that will be the scenario i think, this will help us track them.

1 Like

This would also help with queues with UniqueReference set, where adding a substitute item isn’t straightforward (i.e. Reference is used somewhere, although is not the Best way does happen from time to time, or its used to identify items cross queue or even cross systems).

Could we get adding a queue item manually from Orchestrator bundled up with this as well (or separately)? If there’s an edit, create is just a minor addition away.

2 Likes

Andrzej,
Can you please describe in what concrete scenario(s) this would be useful/used? It will help us understand and refine the suggestion.

Thanks,
Nic

Sure.

For adding:

  • testing end to end queue processing specific scenarios by business users (‘robot is ready, please add sample scenarios and run the test job whenever you have the time’). While these could be added as f.e. input files, its not always feasible, especially if originally the data is fetched from some hard to reach places
  • On demand (re)runs by business users (‘can you rerun reconciliation just for company Z?’ and ‘let me run reports for these 4 companies’). StartJob with parameters could potentially serve similar function but queue is more natural for this
  • Queueing work for robots night runs or front office runs by successively adding work during the day and then just running it once (especially useful with floating licenses)
  • Urgent transactions for 24/7 or multiprocess robots (‘i need this new contract processed ASAP and there is a long queue/queue was already built for this run, let me add it with high priority’)

Editing:

  • Changing priorities and due dates / postpones of items
  • Editing input for business rule rejected items and rerunning them

Ideally to make both of those easier and safer it would be possible to define input structure for individual queues.

3 Likes

So…to sum it up

  • editing priorities, due date, defer date and input makes sense and
  • it is more important to achieve this from the Orchestrator UI than from the robot (via activity)
3 Likes

Editing would be very helpful, mainly from the Orchestrator but I think we should give some liberty over this from studio activities as well.

Thanks,
Prankur

6 Likes

I agree with @PrankurJoshi, it would be valuable to Edit them via activity (or see changes we make with an assign activity persistent) as it could be widely for automating testing purpose and would open many new design options while building workflows.

Cheers

3 Likes

Hi,

Being able to edit specific content would be really helpful in some cases. Just for keeping track of details on an item.

If a process needs to perform 5 main steps, you could use this functionality to update the latest successful operation. If the task encounters a business exception, this makes it so much easier for operation to see how the process came before stopping.
I know the same thing can be achieved by variables, but keeping a track record of this could be necessary for statistics. As well as gathering key properties that is encountered during run time.

I dont see any reason why as a developer i should not be able to assign variables to the queueitem.

4 Likes

If this is the use case, I still think you may have 3 types of data and the tracking may be done in Progress.

  • SpecificData, Reference - input, json, immutable, set it only in the beginning
  • ProgressData - json but you may change it during the transaction, set it anytime
  • OutputData - output, set it only in the end

Now, this is the debate. Should we split it or not? In theory we may remove the Output field too, if you allow editing the SpecificData. In this case you will end up with only one field that can be editable at any time.

Why should I choose one approach vs the other?

I wouldn’t remove Output field, as it serves IMHO a different purpose.
Suppose you have some transaction with SpecificData (payment to be done - bank account details, amount etc.).
The Output after processing might be something like “WasScheduled: True, ScheduledFor: [someDateTime], RequiresFurtherApproval: False, RejectionReason: null”.
This information doesn’t belong to SpecificData, because it would change the meaning of its content - instead of SpecificData representing a PaymentProposal it would now represent a ProcessedPayment|RejectedPayment union thus weakening or confusing the meaning.

If we go the route of using Progress for current Output, then it changes the meaning of Progress - instead of representing steps/intermediary data, it now also may represent result.
I might be alone in this, but I think that removing Progress on transaction completion is a good thing - what’s done is done and the result is what matters and that’s what Output is for.

Now for setting SpecificData only at the beginning, we have cases like this:
Input comes in semi-structured email. It needs to be parsed and then processed.

One of the hot questions becomes - what should the transaction represent?
With current possibilities, you could design it (simplified):

  1. 2 separate queues - one for parsing emails (where email is the transactionItem), one for processing (where parsed email content is the transactionItem).
    It works, but is fiddly.

  2. 1 queues - since parsing the email content is part of processing, transaction has to start when you find the email. Thus the parsed content (which is the “real” SpecificData) can only be stored in Progress field. This makes it fiddly (again) to work with and there’s a risk of: overwriting data, data not being immutable throughout the transaction, losing data at the end of processing (unless stored in Output, which it doesn’t really belong to).

If all 3 fields stay, these cases could be:

  1. Find email → AddTransactionItem. Reference (immutable and set on construct only) → some email identifier. SpecificData → null/placeholder for serialized DTO or other properties.
  2. Parse data from email → enrich SpecificData with content from parsing, set Progress → transaction details parsed.
  3. (Maybe possible?) Lock SpecificData editing, making it ReadOnly from now on.
  4. Process normally.
  5. Set result to Output (Progress erased, not useful anymore).

That gives maximum flxibility for however you need to design it and the locking would prevent data mutability in the middle of transaction.

2 Likes

Would you like to have this from activity too?

As of current spec

  • editing a new item will do edit
  • editing a failed/abandoned item may do “just edit” or “edit, save and retry”. the current item will change its status to retry and a new one with edited data will be created - equivalent of editing and then clicking retry
  • clone an item will create a new one (reference is editable this time)
1 Like

Hello ! I’m just curious about when this functionnality will be out. I’m doing a multi transactionnal process (each applicative transaction such as saving a file, creating ressources, etc… is reflected through a Queue for the specific task and then push its state to a new Queue) and everytime an exception (business or app) is thrown, nothing can be set to edit the state of the process. So the options I have right now would be : Create an Attended Robot to edit all fields of the transactions, code an HTTP and UI to edit the transaction, Upload a new transaction through a CSV and delete the old one.

BRE can happend because of missing data or mistakes in a Excel and Bulk Upload for example, and thus it will be hard to reupload a single transaction for a specific chain of process.

I think the spec you did is sufficient enough to make a reviewer able to recover a failed transaction, and would be a must have because I don’t see another convenient to do so, and making more flexible way to interact with queue and reviewers. (Right now, it feels like reviewer can only say “Something is wrong”).

Thanks for your work :slight_smile: !

You can now do that in specific scenarios:

Check our documentation to learn more :slight_smile:

7 Likes

@loginerror Hello there, I just wanted to know if there were a way to do that programmaticaly too through Studio or is it possible through the API ?
Thanks in advance :slight_smile:

Hi @Smixi

I believe this API endpoint would be able to achieve that:

2 Likes

Perfect, I would use that for now ! Hope there will be an activity for that :slight_smile: (or possibly one for just saving the state of a QueueItem object :slight_smile: ).
Thanks @loginerror !

@loginerror From where to access these endpoint information? is there any portal to get details of all the API endpoints.
I am looking to Update a QueueItem using API, I don’t see any documentation around

PUT QueueItems({id})

Hi @ArpanSur

This should be helpful:
image

This is the swagger definition of the API. It is accessible by appending this to the URL of your Orchestrator instance:
/swagger/ui/index#!/

See here for more info:
https://docs.uipath.com/orchestrator/reference#api-references

2 Likes