Jump to content

Authorisation tasks


lokent
 Share

Recommended Posts

One for @Victor:

 

You recently responded to my colleague @Lauren RE: authorisation nodes on our business processes that keep failing. Your response was:

Quote

From our investigation, the affected requests have a process that has an "Authorisation" stage. In this stage, there is a "Gather Authorisation " human task node configured to assign the task to the request owner. However when the node was reached the request did not actually have an owner hence the error.

Our authorisation tasks currently are set to assign to OwnerID, but the team have a working practice whereby if the individual is not going to be in the office for a period of time, they unassign the job and it gets assigned to someone else in the team to complete.

If we change the assignment to Assigned Team instead of OwnerID, would this alleviate the issue? As even when reassigned, it always stays within the same team.

Thanks

 

Link to comment
Share on other sites

25 minutes ago, lokent said:

If we change the assignment to Assigned Team instead of OwnerID, would this alleviate the issue? As even when reassigned, it always stays within the same team.

This is one of the options, yes. You need to use Assigned Team (For Tasks) variable (this is the team ID that the process uses). As a note, this only works however if the request is assigned to a team.

Link to comment
Share on other sites

Could part of the problem be us using the 'Round Robin' assignment, in that if jobs come in during our non-working hours it sits without an owner until someone comes in the next day and logs in?

Link to comment
Share on other sites

23 minutes ago, lokent said:

Could part of the problem be us using the 'Round Robin' assignment, in that if jobs come in during our non-working hours it sits without an owner until someone comes in the next day and logs in?

Yes, most likely... in this case is best to assign the task to the team

 

 

I will bring peace to the galaxy... :P

return of the jedi episode 6 GIF

Link to comment
Share on other sites

Is there a way of changing the way things are assigned in and out of hours?

Our old working practice was for the supervisor to assign individual's work throughout the day, but part of the pull of SM was the 'most available' and 'round robin' options as this frees up the supervisor to complete other work.

We would not want to remove this option unless as a last resort as it has saved us so much time!

cc @Gemma Morrison

Link to comment
Share on other sites

Is there a way in which Round Robin can be time limited?

As an example - could we set working hours of the Round Robin to 8am - 5pm, and this would mean the RR would work as it currently does assigning to the individual within the team automatically and the task being assigned to the team rather than the individual  (this is a setting we need to change at the moment, but want to rectify the error first).

Then, during the hours of 5pm - 8am all requests assign to the team and get manually allocated in the morning by the supervisor.

This is no different to how it currently works at the moment, as the RR cannot find anyone to assign to out of hours so they just sit there, but the RR seems to recognise this as a failure and so this is why the task assignment is failing?

We are open to suggestions, anything to keep the error gremlins at bay!

Side note - the refresh of the previous stage does not work on these jobs, I think again, because of no-one being logged in during the time of the job being created.

@Gemma Morrison please elaborate on this if it doesn't make sense!!

Link to comment
Share on other sites

23 minutes ago, lokent said:

could we set working hours of the Round Robin to 8am - 5pm

I'll tell what I implemented for our service desk which I think it will work for you... A while back I thought it would be nice if a request is raised out of hours (between 17.30 PM and 09.00 AM) or during the weekend we send out a different confirmation email mentioning the request was raised OOH and we will get back to the person who raised the request as soon as the office opens. I have done this by having a decision node to check what time of the day the request was raised... if between 17.30 PM and 09.00 AM then the process branches and send out the email using OOH template, if between 09.00 AM and 17.30 PM the then the process branches on another path that sends out an email using the normal template... I think you can see now how this might be working for you ... if you think it would work for you and want details on this, let me know...

Link to comment
Share on other sites

12 minutes ago, lokent said:

How would the above process alleviate the authorisation node error, would it do as I suggested on my previous response for OOH?

If your main/only objective is to eliminate the error when the task is created and assigned to the request owner then why not simply add a node prior to task creation which checks if the request has an owner. If it does then go ahead create the task. If it does not then create a small detour, before creating the task, where the request waits for an owner...

Link to comment
Share on other sites

Sorry for seeming dense, I was hoping this would disappear when I got rid of the blonde hair!

That is primarily our issue - that the authorisation nodes fail when individuals are not signed into the system. Therefore, if:

Quote

If your main/only objective is to eliminate the error when the task is created and assigned to the request owner then why not simply add a node prior to task creation which checks if the request has an owner. If it does then go ahead create the task. If it does not then create a small detour, before creating the task, where the request waits for an owner...

alleviates this issue we are laughing and will implement straight away!

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
 Share

×
×
  • Create New...