Conditional Plan Task Based on Customer Value

[joshua kobow]

Trigger Task in Plan that will route a service ticket to a different group based on Customer field

I have a hardware request form.  I would like to route the task to a group based on the location of the customer.  Our company has approx 147 distinct locations and the request for a hardware request will get routed to approx 20 different Tier 2 groups based on the customer's location.

First off, I am not using Request Center for service delivery.  I am using a servicelink agent to route a ticket to HP Service Desk.  I was planning on using the conditionals in the plan and create a 20 tasks for each Tier 2 group I need to route to.  The conditionals would look like this:

Service.Data.Customer_Information.Location_Code = "ATLNTA1100" OR Service.Data.Customer_Information.Location_Code = "AUSTIN7600" OR Service.Data.Customer_Information.Location_Code = "BIRMIN3595"

The problem is that the conditional section only allows for up to 255 characters.  There are 25+ locations that would route to one of the Tier 2 groups.

Can someone think of a different way I could route this?

[Tylor Hagerman]

I would try moving that logic into the form instead of the delivery plan.  The easiest way I can think of is to have all of your locations in a database table (or use a RC Standards table).  If there was a field for location and another field for fulfillment group, you could use data retrieval rules to populate the unique locations in a customer viewable selection, then have a second data retrieval rule to look up the assignment group and populate that in a field (that could be hidden).  Then you only need one plan task that assigns the work dynamically to the value pulled from the database.  That would also allow you to update/maintain the list of locations and fulfillment groups without having to re-code the service.

If that is too complicated, you could use ISF or conditional rules to hard-code assignment logic.  Set "onChange" event for the location selection to fire code that determines the fulfillment group and set the value into a hidden field.

A final thought - If you need that kind of logic in multiple services, make sure you put it into a stand-alone active form component so you can reuse the code.  You could also always add logic to your HP application to auto-assign based on location.

[joshua kobow]

Thank you.  Moving the assignment out of the delivery plan worked best.  I created a DB table with all of the locations and all of their group destinations.  Then, I set the assignment group in a hidden field on the form.  That allowed me to use more sophisticated rules around the assignment.

[Brian Papa]

We are doing something similar to Joshua.  In our environment, every user has a location code tied to their HR record, which we pull in through a directory integration.

when ordering, there is a DDR on the form that looks up the location code in a SQL server table we have created.  In that table, addition to the site logistics, like street, city, stat, country and zip, we also have columns for various performer roles that exist, like desktop support, blackberry support, phone support, desktop purchasing, etc.  We pull that back into the form and then let the customer override and validate a different location if they need something for a different location. 

We have about 2000 location codes in our system to support our 50,000 employees, many of which are just different parts of a floor or floors in a building.  We set the performer roles to the queue name that gets the work(we are using Service manager for Fulfillment).    so, we have one task, but it route to a performer based on an expression, which is the looked-up value for that support function.

that enables us to change routing or add locations via data changes in SQL rather than  Catalog deploying a new version of a service or writing a massive client-side javascript.  We've been using this for about 3 months and it works very well.