@productEnt 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.
This would logically be scope to Edit privilege on queue I guess?
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.
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.
Can you please describe in what concrete scenario(s) this would be useful/used? It will help us understand and refine the suggestion.
- 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’)
- 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.
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)
Editing would be very helpful, mainly from the Orchestrator but I think we should give some liberty over this from studio activities as well.