I saw a conversation in the Google+ ServiceNow community this week about a tweak that Carrie Padian wanted to make to her incident management process.
The conversation led to the topic of using system properties to store the configuration of your application (perhaps "application" is too grand a term for the tweak that Carrie wanted but the logic still applies)
What are System Properties? Well - in your new ServiceNow instance there are already loads that we provide. They can be changed to alter the behaviour of your instance and you should use them too when you write code.
Go and check them out in your instance by clicking System Properties > All Properties
You can see that there are around 600 in a fresh instance and they have names like change.conflict.blackout or com.snc.sdlc.scrum.pp.default_sprint_length. Basically a hierarchical name that stores a value that could be a string or True/False or some other types of values.
As a customer you are going to find these really handy. The benefit of storing configuration in a system property rather than in your code is that you can easily change the behaviour of your code without having to go through additional deployments or update set pushes.
Carrie wanted to send an email when a Problem record had more than 10 incidents associated against it which is quite a simple thing to do.
My first thoughts were to use a business rule containing a short script. Actually there's a much easier way which I've described at the bottom of this post.
You could create a business rule on the problem table that inspects the related_incidents field. If the number goes above 10 fire an event to create an email notification.
(Actually the code here is too simplistic - does Carrie want this to fire EVERY time the related_incidents field is changed? Only when the number is increasing? A few more use cases need to be taken care of here)
She'd also need to register that event so it can be fired.
And she'd need an email notification to listen out for that event.
But if Carrie wanted to change the number of incidents from 10 to something else she'd have to go back to her development instance and re-push update sets.
If she stores her threshold in a system property she can change the value with a zero code change.
What happens here is that the system gets the value from the property (and I've set a default of 10 in case the property doesn't exist for some reason)
The rest of the code is the same, but Carrie doesn't need to make a code change to make the application behave differently.
In summary writing code is an expensive activity in terms of time - regardless of the platform that you are writing on. To maximise your time you should consider using System Properties in ServiceNow to store the configuration of your application or customisations.
As the developer responsible for driving improvements to your instance you don't have time to spend on tweaking features - instead delegate the configuration to business owners so you can concentrate on your next awesome feature.
Hope that helps Carrie!
P.S
Oh - the easier way to do what Carrie needs!! Email notifications can be configured to run when records are updated.
The configuration below would send a notification when the number of incidents goes above 10 and doesn't need any code at all!
1 Comment
