lomixture Posted November 13, 2018 Share Posted November 13, 2018 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 More sharing options...
Victor Posted November 13, 2018 Share Posted November 13, 2018 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 More sharing options...
lomixture Posted November 13, 2018 Author Share Posted November 13, 2018 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 More sharing options...
lomixture Posted November 13, 2018 Author Share Posted November 13, 2018 Also, congratulations on your promotion to Sith Lord! Link to comment Share on other sites More sharing options...
Victor Posted November 13, 2018 Share Posted November 13, 2018 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... Link to comment Share on other sites More sharing options...
lomixture Posted November 16, 2018 Author Share Posted November 16, 2018 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 More sharing options...
Victor Posted November 16, 2018 Share Posted November 16, 2018 18 minutes ago, lokent said: Is there a way of changing the way things are assigned in and out of hours? What do you have in mind? Link to comment Share on other sites More sharing options...
lomixture Posted November 19, 2018 Author Share Posted November 19, 2018 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 More sharing options...
Victor Posted November 19, 2018 Share Posted November 19, 2018 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 More sharing options...
lomixture Posted November 19, 2018 Author Share Posted November 19, 2018 How would the above process alleviate the authorisation node error, would it do as I suggested on my previous response for OOH? Link to comment Share on other sites More sharing options...
Victor Posted November 19, 2018 Share Posted November 19, 2018 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 More sharing options...
lomixture Posted November 19, 2018 Author Share Posted November 19, 2018 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 More sharing options...
Victor Posted November 19, 2018 Share Posted November 19, 2018 43 minutes ago, lokent said: will implement straight away! Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now