Change management

Service-now allows you to easily create relationships between tables without

This post is written in response to a question I

One of the great features of Service-now.com is its CMDB and relational mapping. You can easily set up relationships between any CIs in the system. Once the relationships are defined, it becomes very simple to pull up a visual representation of a CI and its dependencies by using Service-now BSM maps. Using this feature allows an end user to look at that CI and identify what else in the environment is impacted by an outage or a change to that CI.

One common problem I encounter with Service-now deployments has to do with the sharing of a field between many tables extended off of the same parent table. Because the Task table and the Configuration Item table make heavy use of extended tables this is where I see the problem most often. What is the best way to make changes to a shared field for the table that I'm working on, but not impact other tables that may be using the same field?

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.

When implementing the Change management process in Service-now 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.

There are a variety of ways to implement copying functionality...