50% found this document useful (2 votes)
960 views9 pages

ServiceNow Notes

Uploaded by

Virush
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
50% found this document useful (2 votes)
960 views9 pages

ServiceNow Notes

Uploaded by

Virush
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

ServiceNow Introduction

4 Environments or instance will be created for the company with their preferred name:-

A. Development or Dev
B. TEST or QA
C. UAT or Stage
D. Production or Live environment

UAT --> User Acceptance Testing

servicenexusdev.service-now.com
servicenexustest.service-now.com
servicenexusuat.service-now.com
servicenexus.service-now.com
Incident management -- Process owner

Unit testing: Developers should perform the functional testing before moving to QA team for their validation.

ServiceNow versions:

Rome --> SanDiago --> Tokyo --> Utah --> Vancouver


n-1
n --> Latest version
2 versions in a year will be released by ServiceNow
Utah --> Latest version
support.service-now.com --> we need to request for version upgrades

1. New features
2. Updates to the existing functionalities
3. Deprecating the existing functionalities

PDI -> Personal Developer Instance


dev126450
>> If we didn't login for 24hrs then instance will go for hibernate mode -- 5 to 10mins to wake up the instance.
>> If we didn't login for 10 days continuously, then ServiceNow will claim the instance and assign to it someone else.

Useful links:

Product documentation: https://docs.ServiceNow.com/


Personal Developer instance: https://developer.ServiceNow.com/dev.do#!/home
Now learning: https://nowlearning.ServiceNow.com/lxp
ServiceNow community: https://www.ServiceNow.com/community
User Administration
1. Users: Who all are going to use the ServiceNow application to create the tickets.

A. Through integrations
B. Through data imports (excel or csv etc.)
C. Manual creation

2. Groups: To pass the information to the multiple people in the same team at the same time.

>> User can be part of multiple groups

3. Roles: To control user activities or permissions in ServiceNow application.

400+ --> OOB

OOB -> Out of the box -> which are provided by ServiceNow as part of initial setup.

1. End user (internal_user) or Self-service: Create the tickets or track the status of the tickets or read the
knowledge articles.
2. ITIL: To provide the approval or act as a product owners or process owners.
3. Admin: Super user role and the users will have the full permissions with in the application.
4. Delegate: To represent someone in their absence.
5. Impersonation: To test as an end user.
6. Security_admin: Provide the access to the ACLs for admin users.

>> It is time sensitive permission which need to be enable every time when we logout and login or when system has
terminated our session due to inactivity.

5000
200 -- Itil -- 30 to 40USD per month per itil user

>> FD should create in production first and then it has to move to sub prod instances.

>> When we make any of the existing group as a parent for any other groups, all the permissions from parent group
will automatically passed to the child group.
Reporting in ServiceNow

Reporting: Visualization of the data which can be shared with users or added to the dashboards or we can email the
reports to the required users or schedule the reports to trigger at specified times etc...

Itil role or report_user role or report_admin role

>> Please create a report to display the incidents data which are created in the last 3 months for software category.

>> As part of the licensing ServiceNow will provide the default reports in the instance which we can able to use.

Logged in user --> the person who logged in to the instance at the time of performing any activity

Sharing the report: To grant the permission for a visibility of the report

Scheduling a report: Schedule the report to send in a specific time of the day or specific day of the week or month
without needing to generate manually.

Insert: It will create a copy of the record with modified values and redirect to the previous page.

Insert and Stay: It will create a copy of the record with modified values and stay on the same form.

Dashboards in ServiceNow

Dashboards: It's a page or landing page where we can keep all our work related items which need to track.

>> Users with any role (itil or admin) in ServiceNow can be able to create dashboard.

Req: Can you please a dashboard and add the below reports to the dashboard.

Dev and QA instances have an access to the admins/developers and QA team.

UAT or Stage and Production instance will be accessed by the ITIL users and end users.

Subprod (Dev, QA and UAT)

Preprod (Dev, QA and UAT)

Production or Live
>> Dashboards with lowest order will display first and highest order will display at the end.

>> Dashboards can be shared with other users or groups or roles.

Tables and Columns


Table: Collection of records

Record: Collection or Combination of columns

Column or Field: It holds the information of a particular attribute.

95% of the work will be performed on the OOB tables

4000+ OOB tables

Different types of tables:

1. System created tables (prefix starts with sys_ or sn_ or imp_ or snc_)

A. Table prefixes which starts with sys_ or sn_ or snc_ are store the actual data
B. Table prefixes which starts with imp_ is called import set tables and holds the data temporarily for 7 days.

2. Custom tables (prefix starts with u_)


3. ITIL tables (incident, problem, change_Request, cmdb_ci, sc_Request etc..)

>> A table is a parent for any of the table in the system which is not a child for any other table is called base table.

1. Task (incident, problem, change_Request, incident_task, sc_Request, sc_req_item etc...)


2. Cmdb_ci (Configuration item) (cmdb_Ci_computer, cmdb_ci_server, cmdb_ci_hardware etc...)

>> When we extend (making a parent) of any existing table to our newly created tables, system will automatically
pass all the columns information to the child table.

>> Do not create any custom tables without proper approvals as they may attract the extra licensing cost.

>> There are four operations (Create, Read, Update and Delete) for each table which controls the permissions and
allow only the authorized people to perform the operations.

C -- Create
R -- Read
U -- Update
D -- Delete

>> By default only admin users will have an access to all these four permissions.
User (sys_user)
Groups (sys_user_group)

1. Employee name -- Reference - User


2. Employee id -- String or string - utf 8
3. Start time -- Date/Time
4. Is transport required? -- True/False
5. Location -- Reference -- Location
6. Floor -- String
7. Desk number -- String
8. Reporting manager -- Reference --User
9. End time -- Date/Time
10. Country -- Choice -- India, USA and Canada

>> 54 types are available to create the columns in ServiceNow

>> By default ServiceNow will create 7 columns

A. Created
B. Created By
C. Updated
D. Updated by
E. sys_id -- Servicenow will generate unique id for each record in ServiceNow which is 32 chars length
F. Updates
G. Class name

>> For all the system created fields the prefix of the database name of a field starts with sys_
>> For all custom fields the prefix of the database name of a field starts with u_
>> All reference fields will have a default length of 32 chars
>> We cannot make a field read-only and mandatory at the same without having a default value.

>> We can create the columns to the table in multiple ways,

1. From the table configuration


2. Dictionary
3. Form configuration

Form Configurations: To arrange the fields/columns in the form or to create the fields in the table, we can use form
configurations.

Form Sections: Groups the related fields in a separate section to track

Form Views: Create different views for a same form to display it to the required users

Dependent fields: To dislay the choices for a field based on the input from the previous field, we will use dependent
field configuration.

Dictionary overrides: To change field behavior (making field mandatory, read-only etc..) on the child table without
impacting on the parent table level for a field which is inherited from the parent.
Application Menus
Application Menus: Application menus will help the users to create or view the records from the left navigation with
a single click.
1. If an application menu doesn't associated with any of the modules, it will not display in the left nav even it is
in active state.
2. We can control the module visibility to a specific user based on their role, even if the application menu will be
visible to everyone.
3. Seeing the application menu will not guarantee you to provide the access to the data, still you need to pass
the ACLs on the table to view or to create or to delete or to update the data.
4. "Security constraints prevent access to requested page" If users are complained about seeing this message
when they are trying to access the data in a table, we need to check the ACLs on the table and provide the
necessary role to the users to access the data.

Application Scopes or Scoped applications:

https://docs.servicenow.com/bundle/tokyo-application-development/page/build/applications/concept/
cApplicationScope.htmlpermissions

ITIL Framework

ITIL --> Information technology infrastructure library

1. Incident Management (IM): Incident: An inturption to the service


1. Priority of an incident will be set based on the impact and urgency combination.
2. There is 7 days of lead time will be provided to the users to reopen if the same issue is reoccurring to them
when an incident has been resolved.
A. Verify the issue details mentioned in the incident.
B. Replicate the issue in sub prod instance by impersonating the impacted user profile.
C. If the issue is replicated then start applying the fix in sub prod instances and get it verified by QA and UAT team.
D. Once the fix is approved we need to deploy the changes in production instance.

2. Problem Management (PM): If an issue is reoccurring to the multiple users or to the same user then we will create
the problem ticket to provide the investigation details and apply the permanent fix.

Incident -> Problem can be generated if there is a need to provide the permanent fix

3. Change Management (CM):


A. Normal change: These change requests are require an approval and will be used for regular deployment cycles.

Peer review -> Manager approval -> CAB approval

B. Standard change: These are pre-approved templates which doesn't have any impact to the system.

C. Emergency change: To restore the services immediately we will use emergency change request.

4. Request Management (RM):

5. Knowledge Management (KM): To defer the incident creation by providing the documented steps to the users, we
will use KM

6. Release Management (RM):

>> Only published articles are going to visible to the users in the search.

CAB (Change Advisory Board) meeting:


Incident
HR case
ITIL role or Knowledge

Agile Methodology:
8hrs -- 6hrs - 2hrs
30hrs ->10
300hrs
600hrs
5 req -> 1st req

50 req --> 40 req -->

Service Catalog

Request Management or Service Request: If an employee would like to avail any of the services or goods from the
organization they will use request management.

Service catalogue --> Categories --> Catalog items

1. Catalog items or Maintain items: If a user would like to order single item under one request.
2. Record producers: To create the task based records in any of the table through service catalog, we will use
record producer.
3. Order guides: If user would like to order multiple items under one request

REQ -> Request


RITM -> Requested item
SCTASK -> Service catalog task

REQ0010001 --> RITM0010001 --> SCTASK0010001


--> SCTASK0010002

REQ0010001 --> RITM0010001 --> SCTASK0010001


--> RITM0010002

Incident --> INC0010001

>> Native UI will be accessible only by ITIL and admin users.

1. Variables (Questionnaires): Questionnaires which can be input or entered by the users before submitting
the form.
2. Variable sets: Set of common variables which can be reused in multiple items without needing to
recreate them every time.
3. Client scripts: To make a field mandatory or read only or populate the field values etc. by using the
ServiceNow provided scripting.
4. UI Policies: To implement the basic functionalities of making a field mandatory or read only or hide or
display from the form based on certain conditions without needing to write script we can use UI policies.
5. Available for: To whom the form should be visible to order based on the roles, users, groups,
department, locations etc...
6. Not available for: To whom the form should not be visible to order based on the roles, users, groups,
department, locations etc...

Requirement:
Onshore travel request form:

Service catalog -> Other -> Onshore travel request form

1. Requesting for -- Reference -- Mandatory


2. Emp id -- Single line text
3. Email -- Single line text
4. Designation -- Select box
5. Location -- Reference or Select box -- Mandatory
6. Travel start date -- Date -- Mandatory
7. Travel end date -- Date -- Mandatory
8. Personal information -- Multi line text
9. Reporting Manager -- Reference
10. Additional information -- Multi line text
11. Did you already obtained the permission from your manager? -- Yes/No or True/False
12. Do you agree the terms and conditions? -- Yes/No

>> We can create two types of variable sets in ServiceNow,

1. Single row variable set


2. Multi row variable set

>> We can create the UI policies or client scripts for variable sets as well.
>> We can't write ACLs for the catalog items or variables instead we can use permissions section in the variable
forms.

You might also like