• 0 Vote(s) - 0 Average
  • 5
  • 4
  • 3
  • 2
  • 1
Thread Modes

Workflows and Re-qualification
#1
My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!
Chris Catron - IT Manager, Youth Villages - member of EV CONNECT FORUM since Sep 2016

#2
(03-21-2019, 10:52 AM)catronYV Wrote: My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!

Two ways to handle this:

  1. Using a Closing Operation step rather an Operation Action. The Closing Operation step gives the person completing the action the ability to update the ticket category without forcing a workflow restart. I generally only recommend this for Incidents given the workflow is the same across the board.
  2. Add in a condition to the workflow that checks for the presence of a Re-qualification step in the workflow and gate your End User notifications behind that condition along the False line. If the ticket goes through a re-qualification, that action is present in the history and the workflow evaluates the condition as true and skips the email notification. If the ticket is following the workflow for the first time and no requal occurred, that condition evaluates as False and sends the email.
cmiller, proud to be a member of EV CONNECT FORUM since Oct 2015.

#3
(03-21-2019, 12:53 PM)cmiller Wrote:
(03-21-2019, 10:52 AM)catronYV Wrote: My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!

Two ways to handle this:

  1. Using a Closing Operation step rather an Operation Action. The Closing Operation step gives the person completing the action the ability to update the ticket category without forcing a workflow restart. I generally only recommend this for Incidents given the workflow is the same across the board.
  2. Add in a condition to the workflow that checks for the presence of a Re-qualification step in the workflow and gate your End User notifications behind that condition along the False line. If the ticket goes through a re-qualification, that action is present in the history and the workflow evaluates the condition as true and skips the email notification. If the ticket is following the workflow for the first time and no requal occurred, that condition evaluates as False and sends the email.

Thanks, I'll give it a shot!
Chris Catron - IT Manager, Youth Villages - member of EV CONNECT FORUM since Sep 2016

#4
(03-21-2019, 12:53 PM)cmiller Wrote:
(03-21-2019, 10:52 AM)catronYV Wrote: My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!

Two ways to handle this:

  1. Using a Closing Operation step rather an Operation Action. The Closing Operation step gives the person completing the action the ability to update the ticket category without forcing a workflow restart. I generally only recommend this for Incidents given the workflow is the same across the board.
  2. Add in a condition to the workflow that checks for the presence of a Re-qualification step in the workflow and gate your End User notifications behind that condition along the False line. If the ticket goes through a re-qualification, that action is present in the history and the workflow evaluates the condition as true and skips the email notification. If the ticket is following the workflow for the first time and no requal occurred, that condition evaluates as False and sends the email.

I am trying to add a condition in the workflow but it is not working for me...I'm sure it is my sql scripting.  Here's what I have:

I have an internal update step at the beginning of the workflow that grabs the request_id (i took this from a business rule that I have for something else):
SELECT REQUEST_ID 
FROM SD_REQUEST 
WHERE REQUEST_ID IN (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID IN (@ID@))

The result is stored in a variable called "ReqID"

and then i have a conditional step that checks for 'Requalification' actions that correspond with the request id from the internal update step:
SELECT REQUEST_ID FROM AM_ACTION
where AM_ACTION.ACTION_LABEL_EN ='Requalification' AND REQUEST_ID =  #[VAR.ReqID]#

If true, the workflow assumes it is a requalified ticket and sends emails accordingly.
If false, the workflow goes the normal route.

I'm not sure where I messed up, but it seems that the result is "False" in the conditional step every time I requalify a ticket.  I think it is worth noting that when I run the sql query in the conditional step and inserting the request_id for the ticket that was requalified, I get a value.  I think where it is breaking is in my Internal Update Step.
Chris Catron - IT Manager, Youth Villages - member of EV CONNECT FORUM since Sep 2016

#5
(03-27-2019, 02:56 PM)catronYV Wrote:
(03-21-2019, 12:53 PM)cmiller Wrote:
(03-21-2019, 10:52 AM)catronYV Wrote: My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!

Two ways to handle this:

  1. Using a Closing Operation step rather an Operation Action. The Closing Operation step gives the person completing the action the ability to update the ticket category without forcing a workflow restart. I generally only recommend this for Incidents given the workflow is the same across the board.
  2. Add in a condition to the workflow that checks for the presence of a Re-qualification step in the workflow and gate your End User notifications behind that condition along the False line. If the ticket goes through a re-qualification, that action is present in the history and the workflow evaluates the condition as true and skips the email notification. If the ticket is following the workflow for the first time and no requal occurred, that condition evaluates as False and sends the email.

I am trying to add a condition in the workflow but it is not working for me...I'm sure it is my sql scripting.  Here's what I have:

I have an internal update step at the beginning of the workflow that grabs the request_id (i took this from a business rule that I have for something else):
SELECT REQUEST_ID 
FROM SD_REQUEST 
WHERE REQUEST_ID IN (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID IN (@ID@))

The result is stored in a variable called "ReqID"

and then i have a conditional step that checks for 'Requalification' actions that correspond with the request id from the internal update step:
SELECT REQUEST_ID FROM AM_ACTION
where AM_ACTION.ACTION_LABEL_EN ='Requalification' AND REQUEST_ID =  #[VAR.ReqID]#

If true, the workflow assumes it is a requalified ticket and sends emails accordingly.
If false, the workflow goes the normal route.

I'm not sure where I messed up, but it seems that the result is "False" in the conditional step every time I requalify a ticket.  I think it is worth noting that when I run the sql query in the conditional step and inserting the request_id for the ticket that was requalified, I get a value.  I think where it is breaking is in my Internal Update Step.

In ours, we check for the type of action to determine if requalified.

select request_id
from am_action
where action_type_id = 15
and request_id in (@ID@)
jhendrix, proud to be a member of EV CONNECT FORUM since Apr 2016.

#6
(03-27-2019, 03:22 PM)jhendrix Wrote:
(03-27-2019, 02:56 PM)catronYV Wrote:
(03-21-2019, 12:53 PM)cmiller Wrote:
(03-21-2019, 10:52 AM)catronYV Wrote: My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!

Two ways to handle this:

  1. Using a Closing Operation step rather an Operation Action. The Closing Operation step gives the person completing the action the ability to update the ticket category without forcing a workflow restart. I generally only recommend this for Incidents given the workflow is the same across the board.
  2. Add in a condition to the workflow that checks for the presence of a Re-qualification step in the workflow and gate your End User notifications behind that condition along the False line. If the ticket goes through a re-qualification, that action is present in the history and the workflow evaluates the condition as true and skips the email notification. If the ticket is following the workflow for the first time and no requal occurred, that condition evaluates as False and sends the email.

I am trying to add a condition in the workflow but it is not working for me...I'm sure it is my sql scripting.  Here's what I have:

I have an internal update step at the beginning of the workflow that grabs the request_id (i took this from a business rule that I have for something else):
SELECT REQUEST_ID 
FROM SD_REQUEST 
WHERE REQUEST_ID IN (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID IN (@ID@))

The result is stored in a variable called "ReqID"

and then i have a conditional step that checks for 'Requalification' actions that correspond with the request id from the internal update step:
SELECT REQUEST_ID FROM AM_ACTION
where AM_ACTION.ACTION_LABEL_EN ='Requalification' AND REQUEST_ID =  #[VAR.ReqID]#

If true, the workflow assumes it is a requalified ticket and sends emails accordingly.
If false, the workflow goes the normal route.

I'm not sure where I messed up, but it seems that the result is "False" in the conditional step every time I requalify a ticket.  I think it is worth noting that when I run the sql query in the conditional step and inserting the request_id for the ticket that was requalified, I get a value.  I think where it is breaking is in my Internal Update Step.

In ours, we check for the type of action to determine if requalified.

select request_id
from am_action
where action_type_id = 15
and request_id in (@ID@)

I was overcomplicating things!  I removed the internal update step and added your code.  It worked.  Thanks so much for your help!
Chris Catron - IT Manager, Youth Villages - member of EV CONNECT FORUM since Sep 2016

#7
(03-27-2019, 03:31 PM)catronYV Wrote:
(03-27-2019, 03:22 PM)jhendrix Wrote:
(03-27-2019, 02:56 PM)catronYV Wrote:
(03-21-2019, 12:53 PM)cmiller Wrote:
(03-21-2019, 10:52 AM)catronYV Wrote: My current ticket workflow is set up like this:

Ticket gets created on Service Apps by selecting a Ticket Category.  The requester gets an email.

The Ticket Category has a group assigned to it, so that group gets the ticket and an email.

We don't have a qualification step, so the ticket goes directly to the group associated with that category.  

Occasionally we need to requalify a ticket/incident to another category (and as a result, group).  Therefore, we have a Requalify Ticket button.  When you click this button, it is my understanding that the ticket goes back to the start of the work flow, so the emails start again.

Is there a different wizard we should be using for this purpose or is there a way for me to use logic to send a "requalification email" instead of going back to the beginning of the workflow?  The problem right now is that the requester gets the "new ticket" email again, which may cause some confusion.

Thanks for your help!

Two ways to handle this:

  1. Using a Closing Operation step rather an Operation Action. The Closing Operation step gives the person completing the action the ability to update the ticket category without forcing a workflow restart. I generally only recommend this for Incidents given the workflow is the same across the board.
  2. Add in a condition to the workflow that checks for the presence of a Re-qualification step in the workflow and gate your End User notifications behind that condition along the False line. If the ticket goes through a re-qualification, that action is present in the history and the workflow evaluates the condition as true and skips the email notification. If the ticket is following the workflow for the first time and no requal occurred, that condition evaluates as False and sends the email.

I am trying to add a condition in the workflow but it is not working for me...I'm sure it is my sql scripting.  Here's what I have:

I have an internal update step at the beginning of the workflow that grabs the request_id (i took this from a business rule that I have for something else):
SELECT REQUEST_ID 
FROM SD_REQUEST 
WHERE REQUEST_ID IN (SELECT REQUEST_ID FROM AM_ACTION WHERE ACTION_ID IN (@ID@))

The result is stored in a variable called "ReqID"

and then i have a conditional step that checks for 'Requalification' actions that correspond with the request id from the internal update step:
SELECT REQUEST_ID FROM AM_ACTION
where AM_ACTION.ACTION_LABEL_EN ='Requalification' AND REQUEST_ID =  #[VAR.ReqID]#

If true, the workflow assumes it is a requalified ticket and sends emails accordingly.
If false, the workflow goes the normal route.

I'm not sure where I messed up, but it seems that the result is "False" in the conditional step every time I requalify a ticket.  I think it is worth noting that when I run the sql query in the conditional step and inserting the request_id for the ticket that was requalified, I get a value.  I think where it is breaking is in my Internal Update Step.

In ours, we check for the type of action to determine if requalified.

select request_id
from am_action
where action_type_id = 15
and request_id in (@ID@)

I was overcomplicating things!  I removed the internal update step and added your code.  It worked.  Thanks so much for your help!

I was able to get this to work and finally implemented it in production this week.  However, I'm now seeing a problem where when we use the Quick Call form to create a ticket, we can't dynamically assign the ticket to a group and/or person when we hit the "Assign" button that runs the "Transfer" Wizard.  The wizard just shows the SLA information, then a Finish button and a cancel button.

It seems to be due to the fact that I have a conditional step as the first step in my workflow.  Is there a workaround?  I have a ticket in with Support, but I figured I would ask here as well.

Can I throw a different automatic step in there or configure my conditional step differently?  I've attached a screenshot of my workflow if that helps

Thanks

Thumbnail(s)
   
Chris Catron - IT Manager, Youth Villages - member of EV CONNECT FORUM since Sep 2016






Users browsing this thread: 1 Guest(s)