Business Rules = Buggiest feature in product today
I have to tell you, the number of bugs and issues I have found with the Business Rules feature in the last 30 minutes has me believing this portion of the product needs to be absolutely scrapped and the developers need to start all over from scratch. They clearly don't have this feature "right". There are so many quirks and issues affecting function that it's all but practically useless. It is easily the most bug-ridden area of the product I've come across. A few quick notes of just a few of my findings are below.
-----
All these tests were conducted with Requesters submitting Web forms. No inbound email Business Rules were evaluated. I'm not certain if all issues exist in both input conditions.
1. Business Rules are not observed when requests are being added via back end WebForm by a Technician or Admin.
Each business rule should apply ALL THE TIME. That's what makes them rules. They are not available to be considered "options". A product feature to "Allow admin to override" and/or "Allow tech to override" when submitting on the backend may be reasonable option to allow this functionality for customers who desire it.
2. Only fields that possess no default values as configured in in "Request Default Values" can have ACTIONS taken on them.
If you have a "Request Default Value" so that all new requests go to the "Helpdesk" GROUP by default, you can create NO Business Rule that allows you to manipulate which group the requests goes to. Likewise, if you have a "Request Default Value" that sets the default LEVEL for any new request to "Level 1", you can create NO Business Rule that allows you to change the Level as part of the action. "Request Default Values" seem to remain absolute, regardless of configured business rules. Business Rules should take priority over default (absent of specifics) parameters.
NOTE: I originally thought that after removing all default request fields, a business rule triggering only on: "Subject contains 'test'" worked for a request ONLY containing the word 'test', but didn't execute any rules on a request containing the subject of, "This is a long subject with lots of crappy test stuff." My initial thought was long subjects weren't matching "Subjects containing test', but after more careful analysis...I noticed this bug:
3. A Business Rule with "Subject contains..." after havig been saved and re-edited, converts itself to "Subject is", without intervention. I numerous occassions, I have found my Business Rules with "Contains" magically convert themselves to "IS", rendering them incorrect. This isn't consistent, it doesn't happen with EVER edit. I suspect it has something to do with the AND/OR operands and which radio button is selected upon saving.
4. Business Rules triggering on a given Criteria, can't manipulate that same Criteria in the Action.
If you have a Business Rule set with: "(IF) Category is General" -> "(THEN) Move to Category Operating Systems" - no action is taken. The Business Rule won't work. Your request won't be moved to the Operating Systems category if it is opened under the General Category. I have found Business Rules can't take ANY action on anything used to trigger them in the criteria. IF the criteria and the action are referencing the same field, the business rule is ignored.
5. A Business Rule with "IF Category = Network", "THEN Assign to Group Network Services", ALSO assigned a Technician every time.
Although, no action was defined to assign a technician, you cannot stop the application from assigning one when assigning a group. In my tests, the Business Rule assigned the same technician every single time (wasn't random). It happened to be the first technician of a Group, by alphabetical sorting of names, but I'm not sure that's relevant. EACH Business Rule I defined to move to a particular GROUP also resulted in the request being assigned to a TECHNICIAN.
That's all I've bothered to write down at this point, but I've noticed lots of other Business Rules not performing as expected. I've absolute certainty that if I take the time to troubleshoot and narrow down through the process of elimination, I can isolate and identify each and every quirk this particular feature has. I'm not going to do so, because as utterly flabbergasted as I am about how poorly tested the entire Business Rules subroutines are, especially compared to how well this type of feature works in more robust (i.e. expensive and enterprise driven) competing products, I can't bring myself to spend more time QA'ing for AdventNet. My opinion would change of I were on their payroll to find all and bring to their attention each piece of their software that didn't work right. I would seriously question if any Quality Analysis was done on this (seemingly) quickly thrown together feature.
I hope I don't seem to overly critical of this, but there are some very basic properties of this feature which are completely non-functional. It seriously looks like someone just through some code together and slapped a big 'ol "Done poorly" sticker on the cover. As-is, it's fairly incapable of being deployed to production in the manner competitors are allowing customers to do with their products.
It's a fairly straight forward feature and I'm surprised it has this many issues. As my organization is evaluating the ServiceDesk application as a potential Magic Service Desk replacement, we would be unable to take our existing Magic Business Rules and successfully implement them with AdventNet Business Rules. The existing bugs would make any efforts to configure futile.
-----
All these tests were conducted with Requesters submitting Web forms. No inbound email Business Rules were evaluated. I'm not certain if all issues exist in both input conditions.
1. Business Rules are not observed when requests are being added via back end WebForm by a Technician or Admin.
Each business rule should apply ALL THE TIME. That's what makes them rules. They are not available to be considered "options". A product feature to "Allow admin to override" and/or "Allow tech to override" when submitting on the backend may be reasonable option to allow this functionality for customers who desire it.
2. Only fields that possess no default values as configured in in "Request Default Values" can have ACTIONS taken on them.
If you have a "Request Default Value" so that all new requests go to the "Helpdesk" GROUP by default, you can create NO Business Rule that allows you to manipulate which group the requests goes to. Likewise, if you have a "Request Default Value" that sets the default LEVEL for any new request to "Level 1", you can create NO Business Rule that allows you to change the Level as part of the action. "Request Default Values" seem to remain absolute, regardless of configured business rules. Business Rules should take priority over default (absent of specifics) parameters.
NOTE: I originally thought that after removing all default request fields, a business rule triggering only on: "Subject contains 'test'" worked for a request ONLY containing the word 'test', but didn't execute any rules on a request containing the subject of, "This is a long subject with lots of crappy test stuff." My initial thought was long subjects weren't matching "Subjects containing test', but after more careful analysis...I noticed this bug:
3. A Business Rule with "Subject contains..." after havig been saved and re-edited, converts itself to "Subject is", without intervention. I numerous occassions, I have found my Business Rules with "Contains" magically convert themselves to "IS", rendering them incorrect. This isn't consistent, it doesn't happen with EVER edit. I suspect it has something to do with the AND/OR operands and which radio button is selected upon saving.
4. Business Rules triggering on a given Criteria, can't manipulate that same Criteria in the Action.
If you have a Business Rule set with: "(IF) Category is General" -> "(THEN) Move to Category Operating Systems" - no action is taken. The Business Rule won't work. Your request won't be moved to the Operating Systems category if it is opened under the General Category. I have found Business Rules can't take ANY action on anything used to trigger them in the criteria. IF the criteria and the action are referencing the same field, the business rule is ignored.
5. A Business Rule with "IF Category = Network", "THEN Assign to Group Network Services", ALSO assigned a Technician every time.
Although, no action was defined to assign a technician, you cannot stop the application from assigning one when assigning a group. In my tests, the Business Rule assigned the same technician every single time (wasn't random). It happened to be the first technician of a Group, by alphabetical sorting of names, but I'm not sure that's relevant. EACH Business Rule I defined to move to a particular GROUP also resulted in the request being assigned to a TECHNICIAN.
That's all I've bothered to write down at this point, but I've noticed lots of other Business Rules not performing as expected. I've absolute certainty that if I take the time to troubleshoot and narrow down through the process of elimination, I can isolate and identify each and every quirk this particular feature has. I'm not going to do so, because as utterly flabbergasted as I am about how poorly tested the entire Business Rules subroutines are, especially compared to how well this type of feature works in more robust (i.e. expensive and enterprise driven) competing products, I can't bring myself to spend more time QA'ing for AdventNet. My opinion would change of I were on their payroll to find all and bring to their attention each piece of their software that didn't work right. I would seriously question if any Quality Analysis was done on this (seemingly) quickly thrown together feature.
I hope I don't seem to overly critical of this, but there are some very basic properties of this feature which are completely non-functional. It seriously looks like someone just through some code together and slapped a big 'ol "Done poorly" sticker on the cover. As-is, it's fairly incapable of being deployed to production in the manner competitors are allowing customers to do with their products.
It's a fairly straight forward feature and I'm surprised it has this many issues. As my organization is evaluating the ServiceDesk application as a potential Magic Service Desk replacement, we would be unable to take our existing Magic Business Rules and successfully implement them with AdventNet Business Rules. The existing bugs would make any efforts to configure futile.