Using more states in a queue item

Feedback Orchestrator
, ,
1

Hi everyone,

Have any of you run into the need of adding more states in a queue item than New, InProgress and so on? I know we can use progress and then do a custom field on the queue item. However what if multiple custom states could be set, perhaps as a sub-state of InProgress.

It is a bit similar to what you do in long-running processes, however you handle it with multiple queues, but in terms of reducing queue clutter, it could make sense to use custom states.

Have you had the need for this, and would you do it with a custom field, or use the long-running tasks options, for tasks that are not really long running, but just to separate states.

For complex processes I could see this being useful, in order to secure a proper design of the process, and force some milestones, where a process could be restarted from, instead of starting completely from the beginning. This is also not always possible for more complex processes. However it requires careful design of the process.

Please share your experiences and thougts on this, for a small brainstorm.

Sonny

3

Hi @sonnymeyer

I think this is kind of already there, see here:

4

Thanks, I do know this, and that’s also what I’m mentioning with custom states and fields.

However it is also to expand on the discussion a bit, in terms of whether it would be useful to have it better integrated.

I.e. utilizing the built-in state machine, to handle various states, instead of doing it with decisions.

Again it can be build but the user experience would be better in my opinion if some more built-in mechanisms could be utilized, also in terms of how to view and filter custom states in the Orchestrator.

I’m also open for disagreement here, but these are just my thoughts, and hoping to start a valid discussion in terms of whether it really is needed.

Sonny

1 Like
5

I see now. Could you maybe offer an example of a use case that could directly benefit from such improvement?

6

Sure as stated in the original post I don’t have a specific case in mind right now however i see the following possibilities:

  1. Long running tasks, which is handled by multiple queues
    Disadvantage here is that it can create queue clutter
  2. Using SetTransactionProgress
    The disadvantage here is that one will have to utilize if’s and decisions in terms of handling various states, if using multiple extra states it will become a more complex flow

What if one would like to reduce the complexity of either the queue setup or using SetTransactionProgress, i.e. by being able to filter by custom states when viewing the queue in the Orchestrator. This cannot be done when working with multiple queues, and if I remember correctly it cannot be done with SetTransactionProgress either.

Let’s just consider for the sake of example that I have a complex process with, let’s say 7 different phases, that could be handled independently in time, and it will always happen sequentially.

If I’m to present this to the business users using multiple queues, my phases in the process (or states if you will) will be linked to the queue name (more or less), however if I would just have one queue, but with several custom states (i.e. Phase 1, Phase 2, and so on) it would, again in my opinion, reduce complexity, at least if I somehow would be able to utilize the state machine for navigating between states and jump to Phase x if a retry was needed.

I do realize that “jumping to phase x, or state x” is built-in when using the long-running tasks and multiple queues, because each queue item in a specific queue can have it’s retries directly linking to that. I also do realize that I absolute can build all of this I’m mentioning, again it’s just a matter of ease of use.

Any thoughts? Am I completely derailed here?

Sonny

9

Hi @sonnymeyer,

I agree with your input and have voted for such a feature. Meanwhile, I do think you will find what you described in my post in this feedback thread :

The workaround will work on a single queue, with each status handled by any of the robot sequentially. We have used this approach on a process where we have had over 400000 transactions. It works well, but I cant agree more with you that if a feature exists out-of-the-box for each transaction item, we would use it ASAP.

As you noted, we do have some checks in the Process.xaml with a state-machine to check if the in_TransactionItem.Progress="CustomProcessPhase/Stage"

1 Like