Servicecnow Versions

Aspin
Berlin
Calgary
Dublin
Eureka
Fuji
Geneva
Helsinki
Istanbul
Jakarta......

Watch Lists:
We can make incident to visible to others in Group

Cloning of Instance

Synchronizing the data in all Instances is called Cloning of Instance.

Must be same version and same patch

Roles:
----End User, ITIL, Admin
----Don't give roles to users
----Add roles to group to access Incidents

Users

----User is one record stored in the user [Sys_user] table.

----Self Service>My Profile

Group:
A group is one record stored in the sys_user_group table.
Email Notifications
192.168.0.1

1.Outbound Notification: the emails which are sending from the servicenow.
2.Inbourd Notification:The emails which are sending to servicenow.

Outbound :In the servicenow we can configure in two ways...

1.Record insert or Updated----ITIL and ITSM
2.Event trigger --------gs.eventQue('evnt name',record
objct,evnt.param1,evnt.param2);

ITIL Framework
1.Incident :Incident is nothing but if the end user facing the any issues: 1.emails
2.Phone(Customer care) 3.Self Service 4.Walk-in
2.Change:
3.Problem:

http://www.newmaturetube.com/en/41/indian/long/
Inbound Notiriactions:The notifications which are sending to servicenow
1.New
2.Reply
3.Forward

UI Policies
UI policies are mainly 3 operations
1.Read only
2.Visible
3.Mandatory
http://rexxx.com
Update sets.
According to ServiceNow, update sets can be defined as:
A grouping of customizations into a single package that can easily be promoted to
other instances.

Update sets nothing but, if you want move the changes or enchancements from
once instance to another instance we can use update sets.
---In Servicenow each and every instance has its own database...
---In real-time we have three instances are there: Dev Instance, Test Instance and
Prod Instance.... (MySQL backend is Database for Service now)
---Each and every Instance won't depend on each other.

How to export and import data from one instance to another Instance?
---From one instance we have the option called export from there we can export
the data to XMl,Pdf,etc
---Using import option we can import the data.
Customizations include:
Tables, Forms, Fields, Business Rules, Clients Scripts, Views, etc.
:::::: Update Set:
Captured Uncaptured

1. Business rules Modified CIs

2. Fields Modified Data Records
3. Client Scripts New Data records
4. Forms and Form Sections New Users and Groups
5. Reports Schedules
6. Tables Schedule Jobs
7. Views
8. Workflows

....Records in tables that contain the update_synch=true attribute. (Dictionary

entry for table, type=collection, and add the attribute update_synch=true)
Use update sets:
To make change you intend to apply to other instances
To ensure instances are in sync.
No need to use an update set when:
You are moving data from one source to another (use data extracts/import sets.)

All changes when not within a custom update set will be tracked in the Default
update set. ServiceNow says that This way we can see can see what you have
changed and use this for problem resolution as your change is at least tracked
somewhere.

Naming conventions.
Update sets should have relevant naming conventions.
Suggested convention is:
For immediate fixes, suggested naming is update set name + FIX
Alternative naming convention
(No point putting in description in title as it would be too long)
For immediate fixes, suggested naming is update set name + FIX
For Emergency Change; update set name + EChg

Release dates
Schedule release dates accordingly. When you are in the project phase, or during
implementation its difficult to wait for the next release date, but once youre past
these phases, you should be able to start doing monthly or bi-weekly updates.
Allowing for of time to develop, test, document, and communicate the updates to
the end users through Release Notes.

Schedules to be based on priority and estimated development effort.

The life-cycle of an update set:

Play, test, break, compare, preparedo all this in Sandbox.
Create update set in DEV
Create / recreate your changes in DEV
Capture Customizations
Compare/Merge as needed
Mark completed
Test changes in DEV
Retrieve update set in QA
Preview
Commit
Test changes in QA
Retrieve update set in PROD
Preview
Commit
Communicate

Admin Duties
Set release date and time, taking into consideration when the least impact to the
business is.
Prepare RFC for CAB
Prepare Release Notes
Prepare a list of update sets on the day to be updated.
Communicate date of release to end users.
Commit update sets to QA in correct order. ie order they were created and by
application.
Commit update sets to PROD in correct order. ie order they were committed in
QA IF QA testing is agreeable.
Set date for next instance clone.
Best Practices.
Dont keep update sets open which will span upgrades.
No open update sets during cloning. All updates promoted to PROD before cloning.
Ensure that all instances are on the same version
All instances should be clones of Production
Identify common path for update sets to move to/from
Good practice: dev > QA > prod
Bad practice: dev > < QA > prod
Use meaningful names and descriptions in your update sets
Be cognizant of what will and will not be captured in an update set
MAKE SURE YOUR UPDATE SET IS ACTIVE!!!
DO not delete any update sets. If you have merged update sets, and they have
migrated successfully, you can delete them to save confusion later.
Do not touch Default update set, its properties or values.
Dont delete anything from Default update set. It may save your bacon!
Never modify the update set field value in a customer update set. (i.e. do not
manually move changes between update sets). Unless there is no alternative.
Only complete an update set when its 100% complete
Commit update sets to QA in correct order. ie order they were created and by
application.
Commit update sets to PROD in correct order. ie order they were committed in
QA IF QA testing is agreeable.

If committed update set has problem, complete your fixes in another update set
(in dev) and promote fix with the correct naming convention ie meaningful.
Promote fixes in the same way as normal changes. See Life-cycle of an update set
Know who is doing what
To prevent stepping on another admins toes,
Communicate between admins/developers
Dont use other developer update sets, create your own
Consider merging update sets prior to committing. According to ServiceNow, Last
update wins!
Allow for an emergency change process to quickly promote an emergency fix
through DEV>QA>PROD
Merge completed update sets that you are going to promote together, and delete
the original sets that were merged. (If you plan to use merged update sets)
Always run preview just prior to committing an update set.
Create FIX update sets to promote any changes needed from QA testing
Set completed local update sets in production to a state of "ignore" so they are not
reapplied after cloning production over DEV and TEST. I dont think you have to
do this anymore, but I havent tested it yet!
Use one update set for a workflow; do not use multiple update sets to transfer a
workflow change.
Publish the workflow before you close the update set.
Schedule updates after hours time of least end user impact (example of when
user was updating an RFC)

Common mistakes.
Update sets are committed to QA, but not to PROD. All instances should be the
same.
Update sets are created, and deleted before use. Can you confirm that none of
these changes impact changes in another update set?
Users both working on the same application, especially workflows.
Making on the fly changes in PROD. This breaks future update sets.
Leaving workflows checked out when you complete an update set.
Cannot publish a workflow Set? I have found that if I am testing a workflow, a
record may have the new workflow open. Close those records!

Workflow issues

Overview.
Workflows are tracked in update sets differently from other records because the
information is stored across multiple tables. Changes made to a Workflow Version
are not added to the update set until the workflow is published, at which point the
entire workflow is added into the update set.

Avoiding Duplicate Workflows

Duplicate workflow records may be created on the target instance if you use
multiple update sets that do not include all of the intermediate changes. Changes
may be missed if an intermediate update set is not applied to the target instance
or if some changes were applied to the Default update set by mistake.

To avoid duplicate workflows, ensure that every change is moved to the target
source. Use the following practices for the best results:
Use one update set for a workflow; do not use multiple update sets to transfer a
workflow change.
Publish the workflow before you close the update set.

Trick if you see duplicate workflows de-activate/activate the newer workflow

and the older version will disappear.

Example
For example, duplicate records can occur in the following scenario:

A workflow is created and published in update set 1, which is moved to the target
instance and applied.
The workflow is checked out, changed, and published in update set 2. This
workflow is not moved to the target instance.
The workflow is checked out again, changed, and published in update set 3, which
is moved to the target instance and applied.
This scenario results in duplicate published versions of the same workflow because
the original workflow was marked as unpublished as part of update set 2, which
was not moved.
Before starting the deployment disable the LDAP server to prevent users from
logging in
Kill all active user sessions (including the prod MID server?) the do the
deployment part
Re-enable LDAP server.

Additional Notes - from worthy contributors:

When you run a clone from prod to dev/test, the clone uses the previous day's
backup, not a real-time snapshot of your prod environment. Therefore, if you
complete and migrate your update sets to prod, then do the clone back to dev/test
on the same day, your dev/test instances will not have the latest update sets in
them and your instances will now be out of sync.

Data policies
Data policies are used to maintain the data concistancy.
Data policies are execute at the server side.
Data policies are worked on
---Read-only |
---Mandatory | Data policy Exception

Import sets [Transform Map]

Import set is a powerful tool used to importing data various data sources and
the map that data into service now tables.
-Its acts as a STAGING (table) area for records imported from service now
-Create a Test Excel file