Re-Authorise using a node

[wfmike]

Hi all, 

Hopefully someone else has tried doing this. 

I'm trying to re-authorise a request after a rejection outcome. 

This is to allow the Agent to select a user with a collaborative license and resend the authorisation email on behalf on the requester. 

I'm trying to achieve this through a Human Task (select the user) then the authorisation node emails that user. See attached 

 

[Dan Munns]

@wfmike you should be able to do this. 

I am assuming that you have an authorisation first, then if rejected a chance to rework, then another chance at authorisation? 

Depending on what you want to do you could just give the second chance and then a decision node of rejected>close / accepted>resolved.

We have a similar (slightly more complex) process in place here: 

You will see that it can be rejected at any authorisation point in the red, blue or green sections and it sends it back to the beginning again for re-authorisation by all approving parties. If you want to have the authoriser selected with a human task then you should change the "Auto Assign Authorisation" node and just use a normal one but change the authorisers section to variable and then use the human task capture as the variable. It will look like this:

&[functions.getTaskAnswers("task-5aed9cec-eca5-479a-d6b4-3c0ae5cd1b21").Second_Authoriser]

 I have set the human task to have capture fields to select the authorisers. It takes its info from a simple list for each set of authorisers.

 

Or you could use the node you have and remove the human task.

Replace the human task node with a "Suspend>Wait for list of request authorisers" node. This will present a key icon in the action bar of the request which will allow the analyst to select multiple authorisers from the co-workers list. More info on that can be found here: Authorisation Action Item Wiki page.

Authorisers will need to be subscribed to the service and have a collaboration licence to be able to approve no matter what method you choose.

Edit: If you mark the request rejected with a "Set stage checkpoint" node you can unset it with another node the same which marks the checkpoint 'false' : 

 

Hope that helps  

@Victor can you move this page to the correct forum area please  

[wfmike]

@Dan Munns thanks for the details explanation - exactly what I was after and not as complicated as I thought it would be. 

@Foley Coker  FYI 

Time to do some testing. 

[Foley Coker]

@Dan Munns thank you this has been helpful to read. 

@wfmike please let me know when ready 

19 hours ago, wfmike said:

Time to do some testing. 

 

[Foley Coker]

@Dan Munns Hello Dan,

 

i am revisiting this post as i have come to bit of a standstill regarding the re-authorisation. In the below screen shot, we are attempting to place an expiry on the authorization node, and when reached it goes back to the request owner to select a new authorize. However when we initially tagged it to the first suspend await authorize, it would not provide the authorization key again but just set the authorization to the previously selected authorizer. We then built it as below with a different suspend node to then feed back into the auto assign authorization but yet it is still picking up the originally selected authorizer. Please can you advice how we can achieve this as the wiki did not provide much clarification.  

 

 

Thanks 

[Dan Munns]

@Foley Coker I believe that this is because the authoriser is already set. You would probably need to do something like this:

Auth node with expiry set > decision node >approved/rejected > carry on as normal

                                                                  |__ > expired > select NEW authorisers node > auth node with expiry set > etc etc....

Hope that is a) clear and b) works for you  

[Foley Coker]

@Dan Munns hey Dan, thank you for the response. It was clear to me haha, 

 

Unfortunately we had tried that as one of the solutions as well, and that for some reason was still picking up the previously selected authoriser, rather than giving the user the authorisation key to select a new one. I felt it may have had something to do with a get request info, possibly referencing previously stored data on who the authoriser was but im not entirely sure. 

[Dan Munns]

@Foley Coker yeah I would do a get new approver>get request info>authorisation node. Any time the request data changes I do a get info node. 

If you cant get it to work then give me a shout and I will see if I can knock something up to test.

[Joy]

Hi @Dan Munns, we have tried your suggestion as below and the process keeps reassigning to the initial approver. Please can you advise on next steps?

@Foley Coker

[Dan Munns]

@Joy @Foley Coker on the second suspend>list of authorisers you need to set this variable:

[Joy]

Thanks @Dan Munns it is working now 

[Dan Munns]

Good stuff