Cloning Strategy

[Richard101]

We have been using ServiceNow for about 2 months now, and ran into a few hiccups with cloning. The first was around users. We created a bunch of invalid references in our testing environments since we excluded user data from our initial clones. We fixed this by now bringing down all users, roles, groups and the three membership tables. We initially had the users excluded since we wanted to keep the access we had in the testing instances. So, my questions around this are:

• What is your strategy around user access?
• Do you have connections to non-prod versions of your HR system and AD to import test users and create/assign groups?
• Is there anything around users that you would exclude, preserve, or script in a cleanup script?

The second issue we just ran into was the loss of activity on our SDLC module. This is something we had in test, but not active in our production instance. When we cloned down, we've seem to have lost all of the activities on defects and enhancements except the most recent.

• How could we have avoided this situation?
• Are there other tables like the Activities table with which we should take special care?

Finally, are there any other suggestions you have around cloning that aren't in the wiki or do you have any favorite ServiceNow-endorsed suggestions?

We just did our first upgrade, so we are learning lots very fast! I look forward to learning from veteran developers/administrators.

[Mwatkins]

In regards to your question about the SDLC module losing "activity", are you referring to the Activity Stream? If so, then this is caused by checking the "Exclude audit and log data" box on your clone request. The activity stream works by pulling from the sys_history_set table and the sys_history_set table pulls from the sys_audit table. When cloning with the "Exclude audit and log data" option checked none of the underlying data for the Activity Stream (aka "Activities (filtered)" in older versions) comes across.

[Richard101]

I am talking about the capturing of state changes or comments/work notes that contain the old and new values. I think the table is the Journal entry table. It's labeled Activities on the form. Is that not the normal thing they are referred to as? Is there a difference between the audit history and activities?

[Mwatkins]

Yep, that's the one. The item labeled "Activities" on the form (also known as Activity Stream or Activities (filtered)) is what's known as a UI Formatter (find it under "System UI > Formatters"). The way it works is that it combines data from different sources into a chronological list of update groups. It pulls its data from lots of different places including sys_audit, sys_email, and sys_journal_field. The audit history item is usually seen by right+clicking on a form header and selecting either History Calendar or History List. The details in audit history are also backed by the sys_audit table so the two things have some overlap.

[HugoFirst]

I can give you feedback on our cloning experience with regards to your 3 questions:

• What is your strategy around user access?  
  Any user who can access prod can also access our dev and test instances.   In fact, we often do this to preview changes requested by users and we have the users accept the change prior to promoting it to production.
• Do you have connections to non-prod versions of your HR system and AD to import test users and create/assign groups?  
  We use the same "production" LDAP server for dev,test and prod instances.   That way our users can access any of the instances with the same userid and password.   NOTE: We color code our instances to make it easy to tell which site you are one.   dev=red,     test=yellow and prod=green.
• Is there anything around users that you would exclude, preserve, or script in a cleanup script?
  In general, we preserve anything from the prod instance when we clone to a dev/test instance.   We do NOT however, promote "DATA CHANGES" from dev or test to prod.   These are made directly in prod.   A "DATA CHANGE" might be membership in a new group, new phone number, etc.

I also want to pass along an observation.   We bring over incidents, change requests, change tasks, requests, requested items and catalog tasks in our clone.   However, the workflow contexts do NOT come across.   Records cloned to dev or test   may show a status of open, but will not trigger new tasks when closed since there will be no workflow context.

So any testing on workflows has to be performed on a new record created in the dev or test instance after the clone.