User Pages - Confirmation of Resolution Buttons

[ChrisN]

Afternoon all,

So, during some testing of a new workflow (specifically the resolution element) I've noted a bit of a odd behaviour when looking at things from a users perspective.
Now I have a query as neither myself or my colleague know the answer. On the users screen two options are presented (as shown).

 

'It's Working! - Appears to pass a closure status [Request Status == status.closed]
-- Determined from existing workflows, which I used as a template for new work, and the request closed successfully as expected.

'It's still broken' is a bit of an unknown
--I'm less clear on as existing workflows 'appear' to route this via a No-Match condition and then re-opens the request.
    However, it does not appear to re-assign to the resolving team. I added in a step to do so but the status remains unassigned.

Thus my question is what exactly does the 'It's Still Broken' pass back as a return? Not sure if this is configured by us historically or out the box behaviour.
I believe we may need another branch in the decision to specifically look for that being clicked and pass back to the resolving team.

As a bit of a disclaimer both I and my colleague are having to re-work a lot of items historically done by others.
Consequently I am not sure if users selecting this has always resulted in ticket re-opened and being left un-assigned, but its definitely not what we want to happen.

The concern being that if our Service Desk (external) are filtering based on their Service Desk queues tickets responded to in this way by users may not be picked up.
Obviously we don't want anything we do potentially landing back in an unassigned team  / person state potentially unnoticed by support staff or team queue managers.
 

[Steve Giller]

8 minutes ago, ChrisN said:

Thus my question is what exactly does the 'It's Still Broken' pass back as a return?

It doesn't really pass anything back - it changes the Request Status to Open.

9 minutes ago, ChrisN said:

However, it does not appear to re-assign to the resolving team.

No, it doesn't "do" anything, your Workflow needs to respond to the change in status and act accordingly - as this will be different depending on a Customer's procedures, there are no default actions.

From your description the Workflow will, on Resolution:

• Suspend - Wait for Status Change
• Test for "status.closed" (optionally also expiry - if there's no response after 5 working days you may wish to assume it's satisfactorily resolved)
  • If Match, close the Request
  • If not return to the main Workflow

What it does at this point is solely down to your Workflow configuration. A common set of actions would be:

• Email the Customer to confirm it's re-opened
• Reassign to the previous Team/Owner
• Rejoin the original Workflow at the Suspend - Wait For Request Resolution node.

[ChrisN]

19 minutes ago, Steve Giller said:

It doesn't really pass anything back - it changes the Request Status to Open.

Great thanks for that, so sets to 'Status.Open' - that's what I expected. (confirmation appreciated)
Not entirely sure why there's a legacy step to do the exact same then as next item  - I'll remove that

 

19 minutes ago, Steve Giller said:

From your description the Workflow will, on Resolution:

• Suspend - Wait for Status Change
• Test for "status.closed" (optionally also expiry - if there's no response after 5 working days you may wish to assume it's satisfactorily resolved)
  • If Match, close the Request
  • If not return to the main Workflow

Already in place, but thank you.



Expanding on this... 
Once a ticket is in the Resolved State, with assignments etc already set, why would the ticket not still appear to have these set once the above 'It's still broken' is selected. 
The action of clicking on this and applying a [status.open] value should not change this (correct?) but upon re-opening as an licenced operative this does appear to be the case.
I am both the user, approver and operative in my testing and the assignment is definitely vanishing. 

There are Suspend Automations downstream on the loopback, do suspensions clear these variables?

Below is the flow for clarity. Assignment was re-added after the Status Open (now to be removed) but failed to remedy.

[Steve Giller]

4 minutes ago, ChrisN said:

The action of clicking on this and applying a [status.open] value should not change this (correct?)

No, as far as I'm aware that shouldn't affect assignment.

5 minutes ago, ChrisN said:

Below is the flow for clarity. Assignment was re-added after the Status Open (now to be removed) but failed to remedy.

That looks fine, however I've come to refuse to rely on the Node description matching the actual node configuration (i.e. the UPDATE Request (Status Open) node might actually be configured to remove the Owner!) so I make no promises until these have all been checked.
If an assignment node fails to apply an Owner this is commonly due to one of two things:

• The specified Owner is not in the Team provided in the node config
• The specified Team does not support the Service
  • This did not previously prevent assignment due to a bug that is now fixed, so if this is the case it may have "just worked" until recently.

 

[ChrisN]

3 minutes ago, Steve Giller said:

The specified Team does not support the Service

• This did not previously prevent assignment due to a bug that is now fixed, so if this is the case it may have "just worked" until recently.

 

Thanks for that 
We have a 'Test Service' in our Catalogue, to hide testing from the user community.
... and it looks like the new team names following a re-structure are not in that list.
DOH!

Very much appreciated, in short an issue that would have vanished once I made it LIVE for all.