Jump to content

Re-Authorise using a node


wfmike

Recommended Posts

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 

 

re-auth.PNG

Link to comment
Share on other sites

@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: 

image.thumb.png.f98e1d7dd9816c763b4c987d6be3c3c3.png

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:

image.png.3cf6447d8a899912c3b00a1cc7827ea5.png

&[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.

image.thumb.png.ad3fc7a96bd605cfbd8ee822fe9e34ed.png

 

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'

image.png.5177842f11d7a401ab6b213fa91f79fe.png

 

Hope that helps :) 

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

Link to comment
Share on other sites

  • 1 year later...

@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.  

 

image.png.0dab96efade8486a4a898d63272f9b39.png

 

Thanks 

Link to comment
Share on other sites

@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 :) 

Link to comment
Share on other sites

@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. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...