Cancelling an assigned task if - -

We have the following requirement

  • User sends a request
  • Supporter answers request by asking for clarification or by fulfilling the request
  • Here is the thing: While the user is supposed to clarify, the supporter should be able to enter his form again, e.g. to fulfill the request for some reason (let’s say he was able to clarify by phone)

The first thing that comes to mind is to split the token after the supporter asks for clarification with a parallel gateway, so that both user and supporter are assigned to their mutual tasks. Trouble is, if the user clarifies the request, the supporter suddenly has two tasks for his form, the one that allowed him access at all times plus the one from the clarification.

Conceptually, we think we need to cancel the Answer request task (to which the supporter is assigned to give him access to the process at all times) if the user sends a clarification to his request.
Likewise, we need to cancel the Send request task (to which the user is assigned for clarification) if the supporter fulfills the request or sends a different request for clarification.

We have come up with the following solution:

I.e. we send a signal that consumes the token for the pending task und immediately assign the task again with the new token - both for user and supporter.

Is there a more elegant solution? Should we look at it differently?

Hi @dschulten

Very nice to hear from you again! :slight_smile:
This a great question and i think there are lots of other ways to be able to show model this, i feel using non-interrupting events would probably work best, i don’t think there’s a need to close off the Send Answer Request message. I feel it can stay open while a you wait the missing data to come back.
Something like this came to mind

2 Likes

Hi @Niall,

I liked the model but do you think using signal is valid in this case as I believe the information needed is related to the specific submitted request.

Hi @hassang

In this case i’m using an escalation event, the idea being that it can be triggered directly by the user in the Send Answer task and can easily remain within the same scope.

I think you’re right that signal wouldnt work because it might trigger other instances and messages would be a bad choice because they indicate something is triggering the process from outside of the current scope. In the end i thought that escalation or maybe conditional would work.

1 Like

My bad @Niall… I thought signal event is used :sweat_smile:

1 Like