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

Question

Question

User Task per each row

Forms
Updated August 27, 2018
asked on August 24, 2018

Hi, 

We have an Add/Drop form and let's say that the student is Adding 3 classes (done through a table with bunch of lookup rules) so we know who the instructor is.

How do we set up our Process Diagram so that each said row and the 3 different classes (they can be the same potentially for different classes) get approved?

Is it even possible in Forms? 

0 0

Answer

SELECTED ANSWER
replied on August 27, 2018 • Show version history

Okay, so I don't think you can use row indexes in conditions (yet), so I would do the following:

  1. Create a section at the bottom of the form and set it to Hide Always and Save values.
  2. Add variables to store the values from each row
    • Course 1, Instructor 1, Action 1
    • Course 2, Instructor 2, Action 2
    • etc.
  3. For each of those variables add a Function that grabs the value from the associated row of the table
    • =INDEX(Table.Course,1),=INDEX(Table.Instructor,1)
    • =INDEX(Table.Course,2),=INDEX(Table.Instructor,2)
    • etc.
  4. In your process diagram, add an Inclusive Gateway with 6 user tasks (one for each possible row) and for the Conditions set them to something like
    • Course1 != ""
    • Course2 != ""
    • etc.
  5. Set the assigned user based on the Instructor (you may or may not need a separate variable depending on your setup).
    • Approval1: Assign to -> Instructor1
    • Approval2: Assign to -> Instructor2
  6. Add an inclusive gateway after those tasks that merges the paths back together (inclusive should wait for all Active branches before proceeding to the next step).

Now, you will probably need to do a separate form for each user task because I can't think of a "cleaner" way to keep the tasks separated, but the hidden fields are what you would actually want to show along with some kind of "Response1" field (separate variable for each approval) and a standard Submit button on these additional forms instead of the table so you can track each approval/denial without affecting the other branches.

On your "Final" form, you could either show all the results in separate sections and set Field Rules to show if they have content, or you could use JavaScript to take all those fields and plug them back into the table with a "response" column added.

I wouldn't say this is necessarily an "elegant" solution, but it keeps all the tasks in the same business process, it allows you to separate the table rows, and it avoids problems with data being overwritten when users submit a form that requires changes to a shared table/fields.

The Indexes will only put values in for rows that have content, so if a user adds 3 rows, Rows 1-3 will populate and Conditions 1-3 will come back true, but Rows 4-6 will be empty and therefore the form should not hit those branches.

2 0

Replies

replied on August 25, 2018

I would have the form start a workflow where a for each row workflow activity started an approval form that would distribute the appropriate instructor. 

0 0
replied on August 27, 2018

Glenn, but how do you setup wait conditions and how do we return to the main form once the approvals are done?

0 0
replied on August 26, 2018

If an instructor has 2 or more courses in the original submission, is it necessary to have them all on the same approval form, or would it be okay to have them as separate approval tasks since they are different courses?

Also, is it exactly 3, 3 or less, etc.?

I can think of a few ways to approach this but the most viable option is going to depend heavily on what kind of requirements you need to meet.

0 0
replied on August 27, 2018

They don't have to all be on the same approval form. There would be 6 classes at most that could be added at any one time. That is pretty much the only requirement, I just can't think of a way to separate that out ellegantly - I know I can use a concept of Inclusive Gateway with a timer that waits for all approvals to come in then proceed and have some sort of counter to make sure all approvals are in, but how do I set the conditions, it would have to be per row or something like that?

0 0
SELECTED ANSWER
replied on August 27, 2018 • Show version history

Okay, so I don't think you can use row indexes in conditions (yet), so I would do the following:

  1. Create a section at the bottom of the form and set it to Hide Always and Save values.
  2. Add variables to store the values from each row
    • Course 1, Instructor 1, Action 1
    • Course 2, Instructor 2, Action 2
    • etc.
  3. For each of those variables add a Function that grabs the value from the associated row of the table
    • =INDEX(Table.Course,1),=INDEX(Table.Instructor,1)
    • =INDEX(Table.Course,2),=INDEX(Table.Instructor,2)
    • etc.
  4. In your process diagram, add an Inclusive Gateway with 6 user tasks (one for each possible row) and for the Conditions set them to something like
    • Course1 != ""
    • Course2 != ""
    • etc.
  5. Set the assigned user based on the Instructor (you may or may not need a separate variable depending on your setup).
    • Approval1: Assign to -> Instructor1
    • Approval2: Assign to -> Instructor2
  6. Add an inclusive gateway after those tasks that merges the paths back together (inclusive should wait for all Active branches before proceeding to the next step).

Now, you will probably need to do a separate form for each user task because I can't think of a "cleaner" way to keep the tasks separated, but the hidden fields are what you would actually want to show along with some kind of "Response1" field (separate variable for each approval) and a standard Submit button on these additional forms instead of the table so you can track each approval/denial without affecting the other branches.

On your "Final" form, you could either show all the results in separate sections and set Field Rules to show if they have content, or you could use JavaScript to take all those fields and plug them back into the table with a "response" column added.

I wouldn't say this is necessarily an "elegant" solution, but it keeps all the tasks in the same business process, it allows you to separate the table rows, and it avoids problems with data being overwritten when users submit a form that requires changes to a shared table/fields.

The Indexes will only put values in for rows that have content, so if a user adds 3 rows, Rows 1-3 will populate and Conditions 1-3 will come back true, but Rows 4-6 will be empty and therefore the form should not hit those branches.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...