You are viewing limited content. For full access, please sign in.

Question

Question

Forms - Limitations of assigning task to entire group of people

asked on July 12, 2017 Show version history

I just want to confirm that I understand this correctly. Because I keep telling people that it is not possible.

In forms you can assign to a group of people IFF you only want 1 individual user to perform the task.

You can't assign to multiple users if you want everyone to perform the task. For this you must use individual user task objects for each user and know exactly which users need to be assigned ahead of time.

0 0

Answer

SELECTED ANSWER
replied on July 13, 2017 Show version history

You will need to do something like this:

  1. In the Form,
    • Create a hidden field for "current user"
    • Store all of your users in a hidden multi-line field (like AllUsers) with some kind of delimiter like ; or / or |
  2. In the Forms business process...
    • Call the Workflow first (see below), then go to a parallel gateway, this will trigger the first user task, and see if it needs to loop back (basically a do-while loop) but make sure you have it wait for the workflow to complete.
    • The Gateway will check whether or not your AllUsers field is empty (there's other ways to do this, but this is the easiest)
  3. The Workflow does the following:
    • Retrieves the AllUsers field
    • Splits into to a "Users" multi-value token
    • assigns the First Index to CurrentUser on the Form
    • Removes CurrentUser from the "Users" token
    • Rebuilds the delimited user list (minus the current user) and updates AllUsers string

 

I got the following results

 

However, be super careful if you try this because if you don't have something that guarantees the loop will break it could quickly become a runaway process.

0 0

Replies

replied on July 12, 2017 Show version history

Based on your description, yes that sounds mostly correct.

However, you could do something with a looped business process that calls a workflow, the workflow iterates to the next user in a collection, then goes back to the forms process that assigns the task, and repeats until until every user has been assigned his/her own task.

It might help to hear the use case. I've found that Forms can work around some of these "limitations" more often than expected if you use the right combination of activities.

 

1 0
replied on July 13, 2017

I think a workflow must start a new blank form though, it can't interact with an existing instance. In this case they are submitting a form, and they want to select from a list of users to assign to.

You can dynamically set the user assignments from a variable, however when you assign more than one person, the first person to perform the task ends the task. They want to assign this to multiple people, where everyone assigned can interact with the form.

0 0
replied on July 13, 2017 Show version history

Which version are you using? Starting with one of the 10.X versions of Workflow you can update business process variables for an existing Forms process.

0 0
replied on July 13, 2017

Interesting, so I can call a workflow, that sets some variables. How would I repeat this though, there is no for each in forms.

0 0
SELECTED ANSWER
replied on July 13, 2017 Show version history

You will need to do something like this:

  1. In the Form,
    • Create a hidden field for "current user"
    • Store all of your users in a hidden multi-line field (like AllUsers) with some kind of delimiter like ; or / or |
  2. In the Forms business process...
    • Call the Workflow first (see below), then go to a parallel gateway, this will trigger the first user task, and see if it needs to loop back (basically a do-while loop) but make sure you have it wait for the workflow to complete.
    • The Gateway will check whether or not your AllUsers field is empty (there's other ways to do this, but this is the easiest)
  3. The Workflow does the following:
    • Retrieves the AllUsers field
    • Splits into to a "Users" multi-value token
    • assigns the First Index to CurrentUser on the Form
    • Removes CurrentUser from the "Users" token
    • Rebuilds the delimited user list (minus the current user) and updates AllUsers string

 

I got the following results

 

However, be super careful if you try this because if you don't have something that guarantees the loop will break it could quickly become a runaway process.

0 0
replied on July 13, 2017

Wow! I am going to try this. I didn't know you could repeat and just terminate all the tasks. I suppose I could have a condition after the user task to determine if the process is complete and to move on, then all paths except 1 would terminate and we are back into a standard linear process.

0 0
replied on July 13, 2017

When I tested it, each approval/rejection leads down it's own path so the overall instance did not Complete until every user task was finished.

However, it will not treat them the same as normal parallel processes and will follow the outflow of each user task independent of the others.

If you absolutely need it to wait for every user to complete his/her task, you might need a second field, workflow, condition, etc. to track how many are complete.

0 0
replied on July 13, 2017

Yea there are projects where I will need to wait for every user and ones where I won't. I was thinking it would just be a matter of inserting a condition after every user task that is only met when all tasks are complete (maybe a variable set by javascript). Then all tasks would terminate accept the final one which would continue on.

0 0
replied on July 13, 2017

That could work. Set a "Complete" field somewhere, and populate/update it with javascript each time someone finishes their form.

Something to consider however is that changing values in one task is going to affect the values for the process, but this is something you'd need to address in normal parallel tasks anyway.

Like I said though, it really depends on your use case.

0 0
replied on July 14, 2017

It works really good. Since all users assigned will be unique I just setup a table where they can select users (this becomes a multi-value field in the workflow).

Then there is a hidden text field called Assign defaulted to Start. When Assign is "Start", workflow sets Assign to the first value, when Assign is a user it just loops through until Assign and the current value become equal, then takes the next value. When it runs out of values to set, it sets Assign to "End" and triggers a conditional to stop assigning users. Thanks for this!

I did run into what might be a show stopper for a specific project though. I can't seem to end the user tasks if desired. I can only terminate the entire instance. I am now looking for a way to end these user tasks remotely from another part of the process diagram. This only applies to a specific scenario of course, where not every user needs to finish their task before it moves on.

0 0
replied on July 14, 2017 Show version history

Here's a thought on how to get you what you need:

  1. Set an additional field for each user (Required: Yes/No)
  2. Create two separate user tasks (one for required, one for optional)
  3. Add a condition before the task to decide which to assign
  4. Attach a Signal Catch (with interrupt) for the Optional tasks
  5. Modify the condition to also check if all Required tasks are complete
  6. Hit a Signal Throw event after the conditions

This way you can split the tasks into two groups, and when you hit the signal throw it will cancel any incomplete Optional tasks.

The signal events shouldn't affect any task that is already complete, just the incomplete ones, so in theory it should work the way you want.

Even if you don't know in advance who is required/optional, you could still use a combination of conditions and signals to end the tasks.

For example, if you only need 3/5, then you could check for 3 completes to pass the condition, put the signal throw after the condition, and that should cancel whichever 2 are still pending.

0 0
replied on July 14, 2017

Ah, I had dug through the signal documentation but didn't realize you could attach a signal catch event. It always looked like a signal throw event when I tried to attach it, when you look at the properties it is a catch event though. That was the part I was missing. Hey! Thanks again!

0 0
replied on July 17, 2017

Got everything working. There is some unexpected things that caused it to terminate though. You can't have more than one outflow from a signal throw event even though it let's you create them. You can outflow into a conditional decision, and from there create multiple paths. The signal catch events must have an outflow to an end event, when they interrupt the task, instead of moving on, it tried to flow out the signal instead and killed the entire process.

0 0
replied on December 13, 2017

Would any of you mind posting a picture of the 'Workflow' from designer so that we could see how it's being done? (We have yet to integrate workflow with Forms, so would like to see how this is being done)

0 0
replied on December 13, 2017

I just did another one of these the other day. Keep in mind though, by looping back into a parallel gateway you actually create an array of single element parallel paths. Which means you can't simply combine your paths with another parallel gateway. You must build your own solution for performing a task once all user tasks are complete. This usually involves terminating after every user task, until a trigger is set informing the process that all user tasks are complete, so that only the last user task does not terminate, leaving you with a single path. It gets somewhat complicated.

Here is the assignment workflow. It simply gets the collection of users to assign, finds the next user to assign, and assigns it to a variable in forms called "assign", then ends. When it reaches the end, it sets the variable "assign" to the value End so that forms stops calling it.

The way I know who to assign next is with a skip token. If it is True then I skip the value I am on in the for each loop, if it is false, then I assign that value and end the workflow. 

Skip is set to True at the start, if I see that this is the first time the workflow is being called by the "assign" variable being it's default value, then I set skip to False. Otherwise, if while cycling through the users, I see that the currently assigned user is the user we are on, that means the next user will need to be assigned, and I set skip to False.

If it skips every value, then I know we are done.

2 0
You are not allowed to follow up in this post.

Sign in to reply to this post.