Category: Business rules
Posted by Mark Stanger in Business rules Monday, 21 June 2010 11:47 No Comments
C
hange management in Service-now includes the use of a parent ‘Change request’ ticket and (usually) the use of multiple ‘Change task’ tickets that can be assigned to separate groups or individuals to perform specific pieces of work. Because these change task tickets should factor into the overall plan for the parent change request, it often makes sense to take the expected start and end dates of change tasks into account when setting a planned start and end date for the parent change request. The purpose of this script is to allow you to automate the calculation of the planned start and end dates for the parent change request based on updates made to the child change tasks. Whenever an update is made to the expected start or end dates of a change task, this script will run and evaluate the start and/or end dates of the other change tasks for the same change request. The earliest start date and latest end date from the tasks are then populated as the overall planned start and end dates for the change request.
Posted by Mark Stanger in Business rules, Client scripts Saturday, 22 May 2010 16:18 9 Comments
A
while ago I helped to answer a forum posting for someone who was looking for a way to present catalog variables to an end-user on a Request Item form but restrict the editing of those variables. At the time, I came up with a solution that worked, but that I really wasn’t happy with. I recently came across another forum posting where the poster wanted to do something similar. The difference for the most recent poster was that the variables were to be shown on an Incident form (which had been generated by a record producer). There were some subtle differences in the way variables were presented on the different forms that made my original script unusable for the incident form. So, I’ve had to revisit this topic to come up with a better solution and I’ve decided to compile all of the different options for making variables read only on a regular form. These solutions can be used in a variety of places, but will most often be applied to the Catalog Item, Catalog Task, Incident, or Change Request tables. Enjoy!
Posted by Mark Stanger in Business rules, System Definition Tuesday, 4 May 2010 09:40 6 Comments
I
f you’ve taken a look at the ‘My Groups Work’ module (or maybe a particular security rule or report) you may have noticed that the condition or filter for that record makes a function call to return a list of values to compare against the value in the given field. In the case of the ‘My Groups Work’ module under the ‘Service Desk’ application there is a function called ‘getMyGroups’ that is used to identify task records where the assignment group value is one of the groups for which the current user is a member.
The ‘getMyGroups’ function simply returns an array of group sys_id values for the groups that a user belongs to. I saw a forum posting recently that pointed out (correctly) that the ‘getMyGroups’ function only returns group membership, but doesn’t return groups where the user is listed as the manager. The function also doesn’t attempt to return child groups of the groups where a person is a manager or group member. So, if I am the Director of Operations and I want to see a list of all tasks for the Operations group (which I am a manager of) as well as the sub-groups of that group, I would have to be added specifically to each sub-group to have all of the groups that I am interested in tracking be displayed in the list.
With some help from John Andersen, I’ve created the ‘Advanced getMyGroups’ function. This function is designed to give users a better way to display group membership information.
Posted by Mark Stanger in Business rules Tuesday, 26 January 2010 06:53 No Comments
H
ere’s a quick tip that shows you how to retrieve the name or URL of your Service-now instance. This can come in handy if you need to construct a URL in a business rule or mail script or if you have some automated post-clone configuration when dealing with multiple Service-now instances in your environment.
Posted by Mark Stanger in Business rules Monday, 4 January 2010 10:44 1 Comment
S
ystem security is probably one of the more challenging things to implement in Service-now.com. While an out-of-box Service-now instance comes with the core security built-in, any implementation will inevitably have customizations in this area. At some point, I plan on writing a basic security guide to help administrators and consultants make informed decisions about how security should be implemented in their systems. You can subscribe to any post, category, or tag on this blog by adding “/feed” to the end of the url so that you can be updated.
One little-known, but extremely useful access control method is to use business rules to restrict record access in your system. You can do this by creating what I call a ‘Before Query’ business rule. These business rules have a ‘When’ value of ‘Before’ and also have the ‘Query’ checkbox selected. ‘Before Query’ business rules are only used when you need to restrict access to certain rows within a table for certain groups of individuals. Because the security is controlled by a script, the restriction can be applied based on roles, group membership, company or department information from the user record, or pretty much anything else that you can derive about the user trying to access a set of records. There are a few of these business rules out-of-box that serve as great examples of how to implement security in this way. When I need to implement security with a ‘Before Query’ business rule, I usually start with the ‘incident query’ business rule as my template.
Recent Comments