Save time and effort by using condition fields on your forms effectively. Chuck and Andrew will show you options available to manage data instead of hard coding conditions in to your requirements and the use cases for each. One of these choices is the condition field. This is an easy to implement solution that offers incredible flexibility and avoids costly development/test time as conditions change.
Originally recorded: Friday March 14, 2014 - 10:00AM US/Eastern
Featured Experts
Chuck Tomasi is a Platform Architect for ServiceNow. He is a computer science major with over 30 years of IT experience. As a former ServiceNow customer, Chuck won the first Innovation of the Year Award at Knowledge 10. Since joining ServiceNow in 2010 as a Technical Consultant, he has done many large scale ITSM implementations and custom applications, acted as an adjunct instructor for Education Services, created and lead the Technical Best Practices program, and co-hosts the ServiceNow series "TechNow".
Andrew Kincaid is a Sr. Software Engineer for ServiceNow. His extensive platform knowledge extends back to 2009 as a customer, Technical Consultant, and Developer.
Chuck and Andrew - Great video and very helpful. I already have a variety of places where I can use this in our ServiceNow instance, plus make my life a whole lot easier.
I've been working with the condition builder field based on your presentation. The business rule I've implemented is successfully matching conditions in my rule table and completing a correct Incident assignment. However, if no condition is found, the script seems to be defaulting to the last rule (either by Order or by last created). Is this expected behavior or should the business rule simply drip out if now match is found? My business is below:
checkRules();
function checkRules(){
var rule = new GlideRecord('u_nimsoft_routing_rules');
rule.addNotNullQuery('u_condition');
rule.orderBy('u_order');
rule.query();
while (rule.next()) {
var match = GlideFilter.checkRecord(current, rule.u_condition);
If no conditions match, you shouldn't get anything. I always recommend a default condition in that case (e.g. set a property and use that if you didn't get any hits.
That being said, I see your issue... you don't have curly braces on your if statement so despite the indentation, you're if will only do the gs.addInfoMessage() if it 's matched. The current.assignment_group will be run ALWAYS for every record.
Thanks for the clarification on my "if" statement. I have another question regarding case on a "contains" condition. Does the condition builder field handle case they same way as a standard condition builder? For some reason, my rules are case sensitive.
For example, I have a rule to assign an incident to our Linux team if the incident short description contains "vRanger". The rule will not match for "vranger" or "VRANGER", it only matches on "vRanger"
Again, probably something simple I'm missing. Thank you for any advice.
That one surprises me. I would have though the contains searches were case insensitive like the list filters are. You may want to contact support to find out more. I don't have an answer for you at this time. Sorry.