External authorisations node

[Adrian Simpkins]

Hi All

We are working on a new process within which the External Authorisation node is being used to get authorisations. However, from reading the Wiki it seems to indicate that this function is just purely for external users with the guidance 'as long as they are not accessing any applications it would work for external users'

We want to get any customers manager to authorise these requests and was looking to use the External Auth node to generate said email out. The customer and manager are both as a mimimum a basic user.

If anyone can confirm please I would be most grateful

Many thanks as always

Adrian

[Jim]

I use this for internal unlicensed users, where I want there decision to progress the workflows so it does work. The only irritation is if they don't respond or try to just email back etc there is no way for an analyst to set the outcomes or override them so they are just suspended until they either expire, or are done correctly. 

Admins if willing can override them by finding the email that was sent and then using the link, which means the links aren't specific to the user they are sent to either and could be forwarded.

[EWA]

Yes. it is an email authorisation, we used it for basic users

 

[Adrian Simpkins]

Thank you both - I must have missed this function before as I was only aware of the authorisation process using the collab licence

Much appreciated  

[Steve Giller]

6 minutes ago, Adrian Simpkins said:

from reading the Wiki

Are you looking at an old copy of the wiki (which has been removed) or are you looking at the current documentation? I can't find the text you mentioned in the existing docs.

[Adrian Simpkins]

Hi Steve - the guidance I got was from an old Forum post around External authorisations hence why trying to clarify today as the Wiki didnt seem to mention said restrictions  Its a new node to me as I have not used it previously, and my other colleague has it setup in this new process so I was getting my head around it - apologies I was not clear in my comments above

Many thanks

[Steve Giller]

@Adrian Simpkins the External Authorisation basically sends an email with a link to accept/reject functionality. This means anybody can be an authoriser.

Some caveats are: a limited amount of text can be sent, there is minimal branding available, you cannot authorise as a group (and therefore cannot weight authorisations), and anyone with access to that email (either access to the recipient's mail or Hornbill's sent items) can use the functionality.

[Adrian Simpkins]

Thanks Steve - that is perfect for what we are looking to do here. Thank you for the pointers we will bear these in mind

Many thanks as always  

[Berto2002]

1 hour ago, Jim said:

there is no way for an analyst to set the outcomes or override them

@Jim there is a way. Yes it involves admins to an extent though.

When the Ext Auth feature was first released (as well as praise HB for it), I remonstrated that we needed a UI over-ride for Service Desk but HB resisted. There is a post abot this from a couple of years ago. They did, however, allow an admins over-ride and we give this to service desk seniors to help others in ICT if required.

Open the managed executed processes list and find the running BPMID in the list. Press the play button (green arriow) and you can respond on the external authorisation with one of the 2 or 3 options).

We use Ext Auth a lot. We find it's useful to include the 'tentative' (amber) and we word our emails to say we'd rather them respond with uncertainty with comments than not respond at all. We then have 4 decisions: approve, reject, tentative and expired which all get handled appropriately. We always include a loop to cycle back and send again and sometimes for Sdesk to be able to choose a new approver.

If I remember, the perms needed for the people to perform this back-end role to move-on an ext auth that is waiting is this:

Example of the set of workflow we have in one process to handle these which include a human task for how SDesk should react when we get an expiry:

[Jim]

@Berto2002 never knew that! at the moment I let them choose a field in the details section, and they have an autotask that restarts the bpm using the service switcher, and the decision is re-evaluated at the start of the process, This currently shows me an obvious trail of who changed the authorisation etc if so. Just tested the route suggested and the timeline showed nothing different that is was an 'override' Good to know though!

[Berto2002]

That is an innovative solution! Let me get this right:

Your analysts edit Details and put "something" in one of the fields. What field and what value for example?

The autotask picks up on this value and uses that to switch service; presumably to the one specified?

How does that then restart the process? What happens if the authorisation is mid-way through; how to you 'skip' the processing already done?

Do you then switch the service back to the original after this so it's correctly listed?

[Jim]

@Berto2002

So the purpose: Our agency/ Fixed term users get expiry dates on the accounts, we log a 'Leaver request' when they are created as part of our starter process, This basically goes on hold until 10 days before the expiry and send the auth out to the manager to advise if they are leaving, being extended or are now permanent (renamed the outcomes) and to return kit if leaving etc. if extended the analyst updates the account and the process goes back on hold and starts the loop all over again. - This helps us to be proactive rather than reactive to the Monday morning expired users - We also have a Board which moves these between the lanes to make it easier to see where actions are required on the requests or not

How it works: analysts set a field in the details section using the simple list to one of the outcomes, they click the custom button which triggers an auto task that switches the process (can be any random process but would recommend an empty process that doesn't modify anything, then flips the process again back to the original, which effectively restarts it) a decision at the start of the original process looks for this value, custom 41 I'm using but the field is irrelevant, and if the value is set it skips the authorisation and moves onto which ever stage it needs to, leaving, extended or permanent.

It was just much easier to teach them to 'pick an option and click a button', this also shows in the timeline who set the approval outcome

 

 

 

[Berto2002]

Like this. This is the best workaround I have heard of  It solves two issues where the platform falls short:

 - cutting-short the ext auth so we don't have to wait 3 days or have admins messing with the back-end

 - allowing a variable to be taken into an autotask - genius

@Fizza have a think if we can use something here. I like the idea of raising the 'leaver' for the contractor to "lie in wait" for the leave date

[Jim]

This is why I love working in IT, may not be a solution in our faces but there's always a way!  

[EWA]

On 01/07/2024 at 11:13, Berto2002 said:

@Jim there is a way. Yes it involves admins to an extent though.

When the Ext Auth feature was first released (as well as praise HB for it), I remonstrated that we needed a UI over-ride for Service Desk but HB resisted. There is a post abot this from a couple of years ago. They did, however, allow an admins over-ride and we give this to service desk seniors to help others in ICT if required.

Open the managed executed processes list and find the running BPMID in the list. Press the play button (green arriow) and you can respond on the external authorisation with one of the 2 or 3 options).

We use Ext Auth a lot. We find it's useful to include the 'tentative' (amber) and we word our emails to say we'd rather them respond with uncertainty with comments than not respond at all. We then have 4 decisions: approve, reject, tentative and expired which all get handled appropriately. We always include a loop to cycle back and send again and sometimes for Sdesk to be able to choose a new approver.

If I remember, the perms needed for the people to perform this back-end role to move-on an ext auth that is waiting is this:

Example of the set of workflow we have in one process to handle these which include a human task for how SDesk should react when we get an expiry:

@Berto2002Have you used this node with a service where a multiple approvers can approve the request - 1 approval sufficient?