owner status is not cleared when re-assigning tickets

[Gary@ADL]

Hi Guys - im having a problem whereby the "owner status" on a ticket doesn't seem to clear when you re-assign it to a team (DEV) without an owner.

 

background is; im writing a workflow which will send out a notification when a ticket has been unassigned within a specific team for a period of time.

 

ive got no problems with tickets that are assigned directly to the DEV team

also no problem with tickets that are assigned to another team first (but an owner/analyst is not specified), and then that ticket is passed up to the DEV team.

I do have a problem when the ticket is assigned to another team, and an owner/analyst is assigned, and then the ticket is passed up to the applicable team with  no owner assigned

I can see its getting to the point of my decision logic to check for an owner,  as its setting the checkpoint in the 2nd "get request info" box, that comes after the "wait for request resolution" box, but rather than send an email, its just looping back round (so its going down no match route) rather than matching the logic of an owner not being set.

 

ticket number of test ticket is IN00161935 (which ive now cancelled by mistake!) - as you can see from the screenshot, it has no owner assigned, (it does have me a member though, unsure if this was because I am the customer, or because I assigned it to myself first, then passed it upto the DEV team)

 

 

please see attached image of my workflow, and also the logic im using to check for an owner,

the wait for incident owner and wait for request resolution have expiries on them so they will move on and round after X minutes,

 

 

 

 

 

[James Ainsworth]

Hi Gary,

Possibly a bit of guess work for me as I can't see what is behind each node.  At the start of this segment of the workflow it has a Suspend and Wait for Owner.  This suggests that it will wait here until an owner is set.  If that is the case, it would always go down the owner set path.  There may be more happening behind the scenes that I can't see, but I'm wondering if you need this first decision node at all.  Can you go from Suspend and Wait for Owner straight to Set Status Open?

 

 

The issue in this next segment of the workflow may stem from the above segment. When it arrives on the Wait for Resolution, I believe that the owner will always be set by the time it gets here.  So, once a resolution is provided and the Get Request Info is called, the following decision node will not go down the dev and no owner as the owner is set within the above workflow segment.  It is possible that the status resolved path is not set up correctly so it doesn't head down that route.  This would only leave the No Match as a path to take.

 

Hope that helps.

[Gary@ADL]

hi @James Ainsworth thanks for your help,

 

 

so I need the first "loop" after the "suspend wait for owner" as this has a timer in it, after 8 hours, if the ticket is unassigned and in the dev queue an alert needs to go out. so this first "loop" takes into account tickets logged directly into the Dev queue - rather than being logged to a 1st line analyst first, then escalated" (otherwise the tickets would sit, wait for an owner, and no notification would be triggered). when we escalate the ticket though from first line, we would assign it into the DEV queue, but without an analyst (so just into the DEV bucket), this is the reason for the second loop after "wait for request resolution", which again has a timer on it. the ticket is proceeding through the second loop after the timer expires, but its not seeing that theirs no analyst set, its treating it like it is still set, hence going down the "no match" option.

 

im assuming "owner" is the same as "analyst assigned" by the way? as I cant seem to refer to analyst assigned, just owner?

[James Ainsworth]

Yes, having the Expiry makes sense.  So, the first loop looks like it will only complete once a request owner (analyst) is set.  So the starting point when it hits the Wait for Resolution before the second loop is that an owner will already be assigned.  From what I can see, it will only go down the dev and no owner path if someone manually removes the owner while it is waiting for resolution, and the request is assigned to the dev team.  Does that sound right to you?

 

[Gary@ADL]

On ‎3‎/‎6‎/‎2020 at 8:22 PM, James Ainsworth said:

Yes, having the Expiry makes sense.  So, the first loop looks like it will only complete once a request owner (analyst) is set.  So the starting point when it hits the Wait for Resolution before the second loop is that an owner will already be assigned.  From what I can see, it will only go down the dev and no owner path if someone manually removes the owner while it is waiting for resolution, and the request is assigned to the dev team.  Does that sound right to you?
 

hi @James Ainsworth  - is "owner" and "assigned analyst" the same thing? -if not, then I think this maybe where im going wrong - but I cant seem to reference "assigned analyst" in workflow logic? only "owner", or "owner for tasks"? (does

 

yes when it gets to "wait for resolution", the ticket has had an analyst previously assigned in a different team, the ticket then gets escalated to another team (e.g. DEV team), but not assigned to an analyst, so the ticket would be in the DEV bucket, but with no analyst assigned - this is what I want to alert on.

 

does the first analyst then gets assigned the ticket become the owner? as its not something we set manually?

 

thanks

 

[James Ainsworth]

We don't generally use the term analyst on a Service Manager request.  There is only an owner.  So, yes the owner of a request is the assigned analyst or support person.  

 

10 hours ago, Gary@ADL said:

the ticket then gets escalated to another team (e.g. DEV team), but not assigned to an analyst,

I can't see within your workflow when or where this is done.  Is this an automated Service Level escalation?  If that is the case, you may need to make sure that the expiry on Wait for Resolution node is longer than the longest possibly escalation time set in the Service Level.  The expiry on a node does not use Working Hours, whereas the Service Level targets do.  For example if your working time calendar is set for 8 hours days, and you have an escalation in your service level set to 8 hours and the expiry on the node is set to 9 hours, the expiry on the node will always come first as the Service Level will escalate at the start of the next working day. 

[Gary@ADL]

On ‎3‎/‎9‎/‎2020 at 6:31 PM, James Ainsworth said:

We don't generally use the term analyst on a Service Manager request.  There is only an owner.  So, yes the owner of a request is the assigned analyst or support person.  

 

I can't see within your workflow when or where this is done.  Is this an automated Service Level escalation?  If that is the case, you may need to make sure that the expiry on Wait for Resolution node is longer than the longest possibly escalation time set in the Service Level.  The expiry on a node does not use Working Hours, whereas the Service Level targets do.  For example if your working time calendar is set for 8 hours days, and you have an escalation in your service level set to 8 hours and the expiry on the node is set to 9 hours, the expiry on the node will always come first as the Service Level will escalate at the start of the next working day. 

thanks @James Ainsworth 

 

so does the "ownerisnotset" variable not the refer to the assigned analyst? or can a ticket have an owner, but not an assigned analyst?

 

the escalation would be a manual one by an analyst, and would be done at the point that the ticket is at the "wait for resolution stage",

 so in the scenario that's not working;  the ticket would be logged, prioritised, and assigned to an L1 analyst, this would take the process through to the "wait for resolution" node, which is set to wait for resolution of the ticket, but also has an expiry of 8 hours on it. every 8 hours the node expires and the process moves on to the decision, here it checks if the ticket has been resolved, or if its currently assigned to the dev bucket with analyst not set, or no match, the latter 2 result in it going back to the wait for resolution. At this point, or any point while the ticket is open in the "wait for resolution" loop, the L1 analyst may assign the ticket to the DEV team, but no analyst initially until one of the DEV guys picks it up and assigns it to themselves.

its these tickets, where they have been manually escalated to the dev team but not assigned an analyst, that I want to alert on, but its not working as its not going through the "dev and no owner" gate, its going through "no match" instead, even though it should be meeting the correct criteria of being in the "development" team, and having "ownerisnot" set. (as you can see in the screenshot of the ticket above - IN00161935, theirs no analyst assigned (its blank) - this is what I mean by no owner set, as ive no other way to refer to this field that I can see?) 

 

[James Ainsworth]

11 hours ago, Gary@ADL said:

so does the "ownerisnotset" variable not the refer to the assigned analyst? or can a ticket have an owner, but not an assigned analyst?

Once an analyst is assigned to a request, we refer to this analyst as "the owner". 

[Gary@ADL]

@James Ainsworth ah ok, so if the ticket is reassigned with no analyst, the owner still remains on the ticket until another analyst is assigned? at which point they become the owner?

 

is there any way for me to refer to just the assigned analyst in a workflow decision? can this be added in? otherwise I guess the only option would be to manually remove myself as an owner from the ticket after escalating it?

[James Ainsworth]

If a ticket doesn't have an analyst assigned, then there is no owner. 

[James Ainsworth]

At this point, I'd probably suggest removing / deleting the connections from this decision node and recreating them.  If the request is assigned to the DEV team and an owner is assigned prior to the expiry of the Wait for Resolution node is reached, then it must point back to something odd with your decision node branches.

[Gary@ADL]

thanks @James Ainsworth, sorry can you point me at which node I should be recreating? none of the nodes in the workflow do anything to assign an owner?

 

the ticket shows that theirs no owner assigned in the information section "no owner", and I can see that the workflow is going round the loop as expected (as i've set some additional checkpoints which show me the its getting the assigned team correct "development", just its not picking up that owner is not set,) ive also checked the database direct and I can see that the "request owner name" field is blank,