Custom Routing Is Not Working SD 7.1

[Migration User]

I know that there have been a few posts on this topic in the past but nothing about 7.1. No matter how I try to create custom routing rules, they simply do not work. Here's my process...

 

1) Create a new group in Admin - Users - Accounts

2) Added the group in the Profile Definitions of ServiceDeskSettings under Admin - Data - Application Properties

   a) Created a Group Name

   b) Set Category to: User Groups

   c) Set Default Value to: SD.IncidentManagement

   d) Restart IIS

3) Went to Admin - Data - Application Properties, clicked on ServiceDeskSettings and went to the groups. I renamed the group there from SD.IncidentManagement to a more common name that matches the actual group name such as Group3.

3) In workflow I have opened the SD.RoutingRules Project and did not rename the project (to add the space: SD.Routing Rules). I have tried with the space and without, not sure which is the preferred method as the customization guide mentions changing the name with SD.IncidentManagement but never mentions it again so I don't know if it should be done or not for every project...

Now there are 2 ways I've tried this from here:

4) Added a Matches object and entered some text on the line like "Intake Form" (without the quotes) and compared to variable Incident.IncidentName

5) Added another GetGroupByName object. 

    a) Left the Outputs the same as "Get Support Group I" which is SupportIGroup

    b) Under Inputs I have tried statically setting the name of the group it the common name of the group in SD such as Group3 as well as using the process variable as it is available to me now that I have set it in SD.

6) I reconnected all of the objects correctly so that the input goes to the matching and if it matches to go to set the group name and if not set it to Support I.

7) Save and publish.

8) Log into SD and create a ticket with the correct IncidentName that will match and save it.

 

When I test this, nothing I do works and sometimes I get a ticket stuck in processing and so nothing else will be posted. Fatal errors appear in the log saying that SD.IncidentManagement could not read in object. When I don't get this error the tickets go in but all get assigned to Support I.

I have also tried this with the more simple Priority which is a static name rather than a longer string like in Incident.IncidentName.

If anyone has any ideas where I might be going wrong or why this might not be working, I would love some advice. Thanks!

[Migration User]

I fixed the fatal errors as I was overwritting dlls that I shouldn't have been but the routing is still not working.  I don't know if the SD.RoutingRules is ever running! I put a ton of logging in so that I could potentially see what might be happening and no logs are ever written ( and I can only assume I'm doing that part right). I can see the SD.RoutingRules running in the workflow explorer and I restart server extensions after each publish to ensure that there aren't more than one project running at the same time and still no luck at all.

 

[Migration User]

Still no go but now I am wondering if it is due to an error during install. Every time I install ServiceDesk, and that has now been 15 on this machine, I get the exact same error during the SD installation section:

 

 

An error has occurred at: Item Is In Collection

 

Error Message: you cannot perform an array function on a null object

 

Stack Trace: System.Exception: you cannot perform an array function on a null object at LogicBase.Core.Data.OrchestrationData.GetValue(String name) at LogicBase.Core.Data.OrchestrationData.get_Item(String name) at LogicBase.Components.Default.Process.ItemIsInCollection.Evaluate(IData data) in c:\build\projects\MP1_KB54090\components\LogicBase.Components.Default\Process\CollectionHandling.cs:line 392 at LogicBase.Core.AbstractRuleComponent.Run(IData data) at LogicBase.Core.ExecutionEngine.MultiPathProcessComponentExecutionDelegate.Execute(IData data, IOrchestrationComponent comp, String& outputPath, IExecutionEngine engine, TLExecutionContext context) at LogicBase.Core.ExecutionEngine.AbstractExecutionEngine.RunComponent(TLExecutionContext context, IData data, IOrchestrationComponent comp)

 

which is during the "Creating Hierarchy Categories" segment of the install. Anyone know what this error might be or at least if it is causing the issues I am having with routing?

 

[Migration User]

I fixed this error message by installing all components of SD including Change Management and Release Management even though we don't plan on using those features. That being said, I should have a fully functioning SD installation now but incidents are still not being passed off to the SD.RoutingRules project.

[Migration User]

Regarding step 1 above, when you go to Admin - Users - Accounts , then , ththen to the submenu Users - Accounts - List Groups, do you see "Group3"?  If there are too many groups, can you use the search feature on the left to find Group3?

Regarding step 4 above, I would change this to a "Text Contains" rule instead.

Regarding step 5 (b) above, make sure that on the Inputs Tab, under Parameters, the value of  Name corresponds with the process variable "[[ProfileProperties].service_desk_settings_group_3]" (or whatever is appropriate).

One last note, in my experience, the RoutingRules seem to only affect incidents that are handled via the Email Monitoring process. Currently, we do have custom routing working with emailed tickets.

Can someone else comment on their experience with this?

[Migration User]

I do see the groups on the Groups page and I can add them to the ServiceDesk settings so that I have the process variables appear as well. It's interesting that you say that you only have it working on email monitoring which might explain the issue as even with all of the logging in place and no modifications to SD.RoutingRules, nothing ever gets logged which tells me that that library is never used. This, then, leads to the question on how to route incidents NOT using email monitoring. Its obviously something that exists in Helpdesk 6.5 so I would think by now there would be a method to do it in SD.  I know there are some routing rules that can be configured in SD but they're not as dynamic as being able to choose a specific IncidentName or things like that.

 

I imagine that SD.RoutingRules should be working as this is the definition of the Project in the Implementation Guide:

Routes (assigns) an incident. By default, all emergency and high priority incidents are assigned to the Support II group. All other incidents are assigned to Support I.

 

The Determine Escalation model in this project contains the routing rules that define the criteria for escalating an incident. When an incident meets those criteria, it is escalated automatically.

[Migration User]

Just to add some more testing, at least for me, SD.RoutingRules doesn't seem to be running from the SD console at all, even on a new installation without any modifications. The way I understand it is if I set an incident to the status of Emergency, it should route to Support II, but it doesn't. For me all tickets route to Support I.

[Migration User]

As I continue to dive deep into this, it appears that SD.IncidentManagement is not calling to SD.RoutingRules at all but instead use an internal routing component. This really is too bad because we route on more items than are available to us in the SD such as IncidentName.

However, I have been able to force the use of SD.RoutingRules when we use custom forms for certain processes by making sure that we use a DetermineAssignmentComponent before a SubmitIncidentAdvancedComponent and then map SpecificAssignments to DetermineAssignmentComponentResult[last].

This may have to be the answer that I have unless I can figure out how to remove the internal SD routing and replace it by calling SD.RoutingRules but I might not be ambitious enough to do that.

[MRenfrow]

This is exactly what I was running into!  I cant believe they would totally abandon the SD.RoutingRules with the internal component being so limited!

[Migration User]

i can.

Its all part of the end goal of removing all customization ability, and general short sightedness.  I was told early on that due to all the trouble it was causing by letting people muck around with the 'shipped flows' they were going to move towards a black box scenario. I do understand why, as trying to support everyone's changes is a nightmare, but when you use the idea of being customizable as a selling point, its a conflict.

[Migration User]

I also understand why they would consider it but they really need to understand their customers before they make these moves. HD 6.5 let us route based on nearly anything we wanted and it worked great so if they go black-box then they need to ensure that the most customized features are included such as deep routing rules, multiple inbox monitoring, email templates, customer surveys, an ability to create custom forms (unless this can still be done with WorkFlow as it is now and the license remains included), a way to look up users in incidents other than just an email address without needing to press the "search" button, a quick re-assignment option meaning list all groups in the box without needing to search for them and I'm sure there's a whole lot more. If Symantec doesn't put in this much depth to the product, the risk alienating a lot of clients and driving them to other solutions that can do all of this.

There's a headache in all products when it comes to customization but that's why we're drawn to them. To make them fit our own organizations.

On a different note, it would be nice if their documentation was right. They say what SD.RoutingRules does but never tells you that SD doesn't use it when you create incidents inside of SD and that you have to call it specifically when you create custom forms and workflows. That's just bad documentation.

[MRenfrow]

Has anyone offically called Symantec about this problem?

[Migration User]

I did pose the question to technical support, with regards to SD.RoutingRules and here is the response:

"New to ServiceDesk 7.1 are Automation Rules. If Automation Rules were chosen during installation, SD.RoutingRules do not apply. Automation Rules were implemented in this release to allow setup without modification of projects."

I was also told that the SD 7.1 Customization Guide does not contain information about editing SD.RoutingRules however to the best of my knowledge that guide isn't available or at least I haven't found it yet.

Regardless, on page 26 of the SD 7.1 Implementation guide it does talk about SD.RoutingRules, as I've mentioned before so you can see my initial confusion.

 

The long and short as I understand it now, if you choose Automation Rules during installation the the SD.RoutingRules are not used. I have not confirmed the reverse yet but hope to do so in the next few days.

[Migration User]

I have verified with Symantec today that inside of ServiceDesk, SD.RoutingRules is never called no matter what, if you enable automation or not. Basically all automation inside of SD needs to be done with the new Automation Rules, which of course are not as deep as I would like. I am going to look to see if I can edit the Automation Rules in Workflow but for now this "issue" has been solved.

[MRenfrow]

Thanks for the update!

I hope they have a update soon with a more robust set of options for the Automation Rules or looks like we need to go back to 7.0.