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

Question

Question

How to have multiple people approve something before moving on?

asked on October 14, 2019

I am working on a Business Invoice process in Forms, I will be using a table for each line item on the Invoice.

Each Invoice can have multiple Departments all of which need their own department heads to approve.

How would I be able to set this up so that the Forms process so that once the process starts it can look at each line item and proceed to send them to each department head for signatures?

1 0

Answer

SELECTED ANSWER
replied on October 14, 2019

You can do this by using 'Inclusive Gateways' in Forms. You can have one Form split into several different outflows based on a certain criteria. After the Form is submitted, you can have it hit an 'Inclusive Gateway' before splitting off into a separate approval route for each Department. You'll have to determine how it will evaluate those values in the table and determine which Departments it needs to be routed to for approval.

 

You can then use another 'Inclusive Gateway' after the Department Approvals to merge all those flows back together into one outflow for all Forms (i.e. Saving to LF, final email, etc.). The 'Inclusive Gateway' to merge them back together will wait for all active inflows to complete before moving on (in other words, all active Department Approvals; inactive routes, or Departments that didn't need to approve a particular Form, shouldn't affect the flow).

 

Reference using 'Inclusive Gateways' below in the Laserfiche Administration Guide:

https://www.laserfiche.com/support/webhelp/Laserfiche/10/en-us/administration/#../Subsystems/Forms/Content/Gateways.htm%3FTocPath%3DForms%7CCreating%2520a%2520Process%7C_____4

 

2 0
replied on October 14, 2019

So Forms will be able to read the dropdown for the department in each Row in the Table accordingly and send them off the to right User Task?

0 0
replied on October 15, 2019 Show version history

Yes. You can configure the 'Outflows' of the first 'Inclusive Gateway' (for splitting into Department Approvals) to choose which paths to follow based on a variable in the Form (such as the Department value in the table-row selection drop-down).

I tested this in my environment and confirmed. Below are some highlights.

I created a Form that includes a simple table, with columns for Invoice Number and a drop-down column for Department:

 

Then, built my Process Diagram to use an 'Inclusive Gateway' to split into the necessary paths:

I then configured the 'Department Splitting' gateway outflows to be based on the Department selection in that table:

NOTE: the variable will differ in your process based on how you specifically configured your variables

 

I tested by submitting the Form with 2 departments in the table:

...and the Form was routed to the appropriate 2 approval parties (the 2 unused remained inactive). The second 'Inclusive Gateway' (Approval Merging) waited for both approvals to be completed prior to moving on with the process (no special configuration needed there).

1 0
replied on October 15, 2019

This is fantastic! Thanks!

0 0
replied on October 15, 2019

I've got to say, I love you. Everything has kinda of clicked and I am breezing through this now and my tests all seem to be working great!

1 0

Replies

replied on July 13, 2020

Does there need to be outflow paths for a rejection? What if one of these departments don't approve the invoice? 

0 0
replied on July 13, 2020

Here is what I ended up with.

So each User Task has two Outputs, Approved and Rejected, Approvals move on to the "End of Spaghetti" activity and waits patiently for all other User Tasks to get there.

However, should a user opt to Reject the form several things happen;

The Reject Outflow triggers and hits the Rejected Signal Throw, which prompts all Rejected Signal Catches to kill their respective User Tasks. Each of the Singal Catches then runs to the "End of Spaghetti" Activity because Inclusive Gateways can see exactly how many responses it SHOULD get back and if we terminate the User Tasks without anything extra the whole process stalls as the Inclusive Gateway will wait on responses it will not get. The Catches here will solve this problem for us. 

Some JavaScript runs and fills in a "hasBeenRejected field.

$(document).ready(function(){
  
    $('.hasBeenRejected input').val('');
  
  $('.Reject').click(function(){
    
    $('.hasBeenRejected input').val('Rejected');
    
  });
  
})

This will allow my "End of Spaghetti" Activity to run the "Rejected" Outflow and send the rejection back to the Submitter for either restart the process with any fixes listed in the Comment Section from the rejected User Activity or to cancel the process and let it end. 

If you have any questions or anything just let me know.

I will say while this was the final form that form took I ultimately had to go a different route so it never it production but every single test I had, hundreds of tests, all went through beautifully.

0 0
replied on July 13, 2020

That's beautiful spaghetti. Thanks! My process requires some approvals to be done a specific order so I use exclusive gateways mostly, but this will be super helpful in some of the other processes i'm diving into! 

0 0
replied on July 13, 2020

Yeah, I have two other smaller approval groups, Submitter and their people, then CEO and CFO, but the majority of this is Directors so I can hit them all at the same time, plus the Catches will cancel the user task and it removes the task from their inbox so it doubles up one clean up duty.

0 0
replied on March 8, 2021

Hello, I am trying to build a similar process but I run into an issues when one of the users tasks gets rejected and another one is approved it doesn't route different ways. Instead it sends out a rejected email to all. Would you happen to have an idea of what I am doing wrong?

Thank you

0 0
replied on March 11, 2021

@Tetiana-

IF you're using an Inclusive Gateway, it will wait for all approvals to complete before moving on; it's a way of merging the paths back together. In general, for that you would have it setup to function like

> If all user tasks are approved, move on with the process

>If ANY user task is rejected, reject the whole process

In other words, it's a way to merge the multiple paths back together and act on the process as a whole.

 

If you want different functionality for each user task (each one is looked at individually, with its own follow-on actions) it may be better to keep the paths separated.

 

There's also an option of using Exclusive Gateways, which simplifies the building of the process by having 1 reject route and 1 approved route, but keeping the paths still separated once they're split. Because, an Exclusive Gateway will act on each path's decision, individually, when it's reached and determine which way to send it (it doesn't wait for all of the approvals to complete, after each approval it sends that ONE along).

 

It all depends on your use case scenario and desired results. See the below documentation for clarity on how to use these gateways:

https://doc.laserfiche.com/laserfiche.documentation/english/docs/Subsystems/ProcessAutomation/Content/Forms-Current/Gateways.htm

0 0
replied on March 11, 2021

Yeah, I ended up scrapping the whole thing after the approvers refused to do this in Forms rather than the repository. 

Ultimately I had the set up above with Signals that would throw when the attached approver rejected it, this would like trigger other Signals to cancel the current tasks and send "responses" to the inclusive gateway because it was expecting x responses not 1. Then it led to a gateway that would use the last user response and either move on or send a rejection letter to the submitter and have them make the appropriate changes and then it would try again.

Let me see if I can find an old copy of that process.

0 0
replied on March 11, 2021

I deleted the old one so I remade it real quick, this is the most basic functioning one I can make at this time. 

When a user rejects the Form it sends a response to the "Someone rejected this" Signal Throw which triggers the "Rejection" Signal that all 3 of the attached Signal Catches are waiting for, they cancel the current task and then send *something* to the "Collect the results" Gateway so it can move on. "Send to the correct place" Gateway uses the standard outflow "Last User Action = Reject" and a Default path. Of course, the Default path can move on to other stuff but I have it end there. Since the last user action will always be "Reject" in the event of rejection it will send it off to the initiator with an email that houses the "Comment" from the rejector explaining why and then the initiator can fix and resubmit.

"Gateway used to restart the process" exists solely because the "Rejected, please resubmit" User Task can't route to the "Gateway to send to each user for approval" since they can't typically have multiple inputs and outputs so a secondary gateway is used to fix this. I just tested it as well and it seems to work according to plans. 

Of course, you can add a bunch of other stuff but this is as simple as I can get it.

Hope it helps!

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

Sign in to reply to this post.