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.
System security is probably one of the more challenging things to implement in Service-now.com. While an out-of-box ServiceNow 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.
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.
ervice-now.com provides a very robust and simple way to manage your tasks and approvals (among other things) through its graphical workflow engine.Â It is very common to use graphical workflow to help facilitate some change management process within your organization.Â One common requirement in change management is to be able to cancel or close the change request at any time during the process.Â “Simple”, you say.Â “Just allow the user to change the value of the ‘State’ field to ‘Closed’.”
You would not be incorrect in saying something like that, but you would be forgetting about part of the problem with closing or canceling a change request or other task ticket.Â What if the attached workflow(s) still think that the change request and its associated tasks and approvals are still in progress?Â Should the attached workflow context(s) continue to run indefinitely?Â If your workflow doesn’t have a way to know about the completion of the change request then it will continue to run (or more likely just sit and be forgotten).
hen implementing the Change management process in ServiceNow you’ll probably encounter a scenario where your entire change workflow (including all tasks and approvals) needs to be reset. The first option to consider (assuming you’re using the graphical workflow engine to manage the tasks and approvals) is the Rollback workflow activity. The rollback activity works great for a lot of scenarios, but what if you don’t have a defined point in the workflow where everything should be rolled back? What if the rollback (or reset) can happen at any point in time? There’s not really an easy way to handle this within the workflow itself since you would need to check for a rollback condition at an infinite number of places.