• What is serviceNow

• Why ServiceNow
• Modules of Certified Application Developer
• Exam syllabus
• Module1:Designing and creating an
Application(15%)with serviceNow
• Module2:Application User Interface(20%)
• Module3:Security & Restricting Access(20%)
• Module4:Application Automation(20%)
• Module5:Working with External Data(10%)
• Module6:Managaing Application (15%)
• To post queries use serviceNow community
• To read the material use servicenow.docs
learning plan and training
• Instance Creation: goto serviceNow developer
->create a account with serviceNow
->after login goto manage and request instance
Identify the components of serviceNow
 Module1:Designing and creating an
Application(15%)with service
• Determining the application is a good fit with
serviceNow
• Design and implement a Data Model
• Create modules
• Use of Application scope
 Determining the application is a good fit with serviceNow

• Enterprise Grade
• Data
• User Interface
• Logic
• Security
• Workload
• Integration
• Reporting
• Open modules using the application navigator
• Use lists to open records for editing
• Use filters to display a subset of a tables
records
• Open and create forms to create and edit
records
 Design and Implement a Data
Model
• Most applications need both a data model and
application logic.
 Creating Modules
• Modules are the children, or the second tier
navigation options to the applications in the
application navigator.
• Modules often link to other pages or records
in the platform.
 Use Applications Scope
• Application scoping protects applications by
identifying and restricting access to
application files and data.
• Administrators can specify what parts of an
application are accessible to other
applications from
• Global scope is a special application scope
accessible to all other global applications.
 Module2:Application User Interface(20%)

• Design ,create and customize forms

• Add/remove fields from forms and tables
• Write test/debug client side scripting for
desktop/mobile
• Write test/debug server side scripting
• Use a record producer as an application UI
 ServiceNow Studio
• Studio is serviceNow IDE
• It is preferred interface for building and
modifying applications
• Offers keyboard shortcuts ,code search and
more
• Create and edit applications
• Create applications
• Link applications to a Git source code
repository
• Publish applications to the servicenow
repository
• Submit applications to the serviceNow app
store
• Applications created in studio are scoped
applications
• Scope uniquely identifies applications and its
components
• To launch Studio, open System Applications >
Studio in the Application Navigator.
• select the Create Application button in the
Load Application dialog.
• there are three options in the Create
Application dialog:
• Start from scratch: create an empty
application
• Create custom application: create an
application by starting with a table, role, and
menu
• Start from a service: use an existing Service
Creator service to create a new application
• Use Studio to edit applications and application
files.
• There are four components of the Studio user
interface:
• Header
• Application Explorer
• Content Frame
• Status Bar
• Add a File to an Application
• To add an application file to an application,
select the Create Application File button. The
Create Application file dialog opens.
•
• *Label: Friendly name of the new table.
• *Name: Name of the table in the database.
Automatically created.
• Extends table: The table to extend. When
extending a table, the new table inherits all
columns from the parent table. Leave this field
blank if you are not extending a table. Tables
that do not extend an existing table will
automatically contain seven default fields.
• Application: The Application (scope) this table
belongs to (read-only field).
• Create module: Select to add a menu option
to the Application.
• Add module to menu: Select or create an
Application menu to add the module to. The
default is to create an Application menu.
• New menu name: Appears when – Create
new – is selected in the Add module to menu.
Specifies the Application Menu to add the
module to.
• Columns Section
• A list of table columns.
• Controls Section
• Extensible: Select this option if you intend for
the table to be extended by tables in other
applications.
• Live feed: Select to enable interactions
between this table and the Live Feed
application.
• Auto-number: When selected sets the prefix,
starting number, and number of digits for the
records from the table.
• create access controls: When selected creates
delete, write, read, and create permissions for
table records. All scoped applications are
required to create Access Controls for its
tables.
• *User role: Sets the role required for a user to
access the table’s records.
 Application Access Section
• Accessible: Select This application scope only
to provide complete runtime protection.
Select all application scopes to allow access to
any scope.
• Can read/create/update/delete: Select these
options to allow scripts from other application
scopes to perform these database operations
on the application’s tables. These options
never apply to the current application’s scope.
• Allow access to this table via web services:
Allow scripts from other application scopes to
make web services calls against the table. The
user performing the query must have
permissions to access the table.
• Allow configuration: Allows application
developers working in other application
scopes to write scripts for this table.
 Assignment
1.Try to create a sample application where a
table is created which inherits from another
table.
Ans)sample Leave application created
Parent table is Leavetype
Child table is employee
 2. Check what happens when you try to delete a
column in child table

Ans)Deleting column in child table deleting

column in parent table also
3.Check what happens when you list the records in the
parent table
Ans)Record is deleted in the parent table i.e in
Leave type table
4.Check how can you distinguish the record
which belongs to parent or child table.
Ans)suppose the table is extended then the
deletion done in child table reflect to parent
table and vice versa
• Client-side Scripting Objectives
• Create, test, and debug Client Scripts
• Create, test, and debug UI Policy scripts
• Use the GlideForm and GlideUser APIs in
scripts
• Determine whether to use UI Policy scripts or
Client Scripts
• Introduction to Client-side Scripting
• Scripts in ServiceNow fall into two categories:
• Client-side
• Server-side
• Client-side scripts execute within a user’s
browser and are used to manage forms and
form fields.
• A Client Script executes client-side script logic
when forms are:
• onLoad(): Runs when a form is loaded.
• onChange(): Runs when a particular
field value changes.
• onSubmit(): Runs when a form is submitted.
• onCellEdit(): Runs when a cell on a list
changes value. ( runs on list view )
• Creating Client Scripts
• The procedure for adding files to an
application in Studio is the same regardless of
file type:
• Click the Create Application File button.
• Choose the new file type, in this case, Client
Script.
• Configure the new file.
• Configuring the Client Script
• As with any script, the configuration tells the
script when to execute. The Client Script
configuration options are:
• Name: Name of Client Script. Use a standard
naming scheme to identify custom scripts.
• Table: Table to which the script applies.
• UI Type: Select whether the script executes for
Desktop and Tablet or Mobile/Service Portal
or All.
• ype: Select when the script runs: onChange,
onLoad, or onSubmit.
• Field Name: Used only if the script responds
to a field value change (onChange); name of
the field to which the script applies.
• Active: Controls whether the script is enabled.
Inactive scripts do not execute.
• Inherited: If selected, this script applies to the
specified table and all tables that inherit from
it. For example, a client script on the Task
table will also apply to the Change, Incident,
Problem and all other tables which extend
Task.
• Global: If Global is selected the script applies
to all Views. If the Global field is not selected
you must specify the View.
• View: Specifies the View to which the script
applies. The View field is visible when Global is
not selected. A script can only act on fields
that are part of the selected form View. If the
View field is blank the script applies to the
Default view.
• The GlideForm (g_form) Class
• The GlideForm client-side API provides
methods for managing form and form fields
including methods to:
• Retrieve a field value on a form
• Hide a field
• Make a field read-only
• Write a message on a form or a field
• Add options to a choice list
• Remove options from a choice list
• The GlideForm methods are accessed through
the global g_form object that is only available
in client-side scripts.
• To use methods from the GlideForm class use
the syntax:
• g_form.<method name>
• For example, the GlideForm API has a method
called getValue(). The getValue method gets
the value of a field on the form (not the value
in the database).
• alert(g_form.getValue('short_description'));
• In addition to the getValue() method, other
commonly used GlideForm methods include:
• addOption()
• clearOptions()
• addInfoMessage()
• addErrorMessage()
• showFieldMsg()
• clearMessages()
• getSections()
•
• The GlideUser (g_user) Class
• The GlideUser API provides methods and non-
method properties for finding information
about the currently logged in user and their
roles. The GlideUser API has properties and
methods to:
• Retrieve the user’s:
– First name
– Full name
– Last name
– User ID
– User name
• The GlideUser methods and non-method
properties are accessed through the global
g_user object that is only available in client-
side scripts
• g_user.<method or property name>
• For example, the GlideUser API has a property
called userName. The userName property’s
value is the currently logged in user’s user
name. This script shows the difference
between the firstName, lastName, userName,
and userID property values.
• alert("g_user.firstName = " + g_user.firstName
+ ", \n g_user.lastName = " + g_user.lastName
+ ", \n g_user.userName = " +
g_user.userName + ", \n g_user.userID = " +
g_user.userID);
• The GlideUser API also has methods for
determining if a user has a specific role. For
example
• g_user.hasRole('client_script_admin');
• g_user.hasRoleExactly('client_script_admin');
• Debugging Client Scripts
• There are several strategies for debugging
client-side scripts:
• JavaScript Log and jslog()
• Field Watcher
• try/catch
• Debugging tools built into web browsers
(browser dependent)
• UI Policies
• Like Client Scripts, UI Policies are client-side
logic which governs form and form field
behavior. Unlike Client Scripts, UI Policies do
not always require scripting.
• Creating UI Policies
• The procedure for adding files to an
application in Studio is the same regardless of
file type:
• Click the Create Application File button.
• Choose the file type, in this case, UI Policy.
• Configure the new file.
• UI Policy Configuration
• UI Policies have two views: Default and
Advanced. The fields in the UI Policy
configuration are different depending on
which View you are using. The Advanced view
displays all of the configuration fields. The
Default view displays a subset of the fields.
•
• Table: Form (table) to which the UI Policy
applies.
• Application: Identifies the scope of the UI
Policy.
• Active: Controls whether or not the UI Policy
is enabled.
• Short description: A short explanation of what
the UI Policy does.
• Order: If multiple UI Policies exist for the same
table, use the order field to set the order of
evaluation of the UI Policy Conditions.
• Condition: The condition(s) that must be met
to trigger the UI Policy logic.
• Global: If Global is selected the script applies
to all views for the table. If the Global field is
not selected you must specify the view.
• View: Specifies the view to which the script
applies. The View field is only visible when
Global is not selected. A script can only act on
fields that are part of the selected form view.
If the View field is blank the script applies to
the Default view.
• On load: When selected, the UI Policy
condition field is evaluated when a form loads
in addition to when field values change. When
not selected, the UI Policy Condition is
evaluated only when field values change.
• Reverse if false: Take the opposite action
when the Condition field evaluates to false.
• Inherit: When selected, executes the script for
forms whose table is extended from the UI
Policy’s table.
• UI Policy Actions
• UI Policy Actions are client-side logic in a UI
Policy used to set three field attributes:
• Mandatory
• Visible
• Read-only
• Server-side Scripting Objectives
• In this module you will learn to:
• Write, test, and debug Business Rules
• Write, test, and debug Script Includes
– On demand/classless
– Extend GlideAjax
– Create a new class
• Use the server-side API including:
• GlideSystem
• GlideRecord
• GlideDateTime
• Use the JavaScript Debugger to debug server-
side scripts
• Set and remove Breakpoints
• Step into, out of, over
• Examine variable values
• introduction to Server-side Scripting
• Scripts in ServiceNow fall into two categories:
• Client-side
• Server-side
• Scripts in ServiceNow can do many, many
things. Examples of things server-side scripts
can do include:
• Update record fields when a database query
runs
• Set field values on related records when a
record is saved
• Manage failed log in attempts
• Determine if a user has a specific role
• Send email
• Generate and respond to events
• Compare two dates to determine which
comes first chronologically
• Determine if today is a weekend or weekday
• Calculate the date when the next quarter
starts
• Log messages
• Business Rules
• Business Rules are server-side logic which
execute when database records are queried,
updated, inserted, or deleted.
• Business Rule Configuration
• name: Name of the Business Rule.
• Table: Specifies the database table containing
the records this logic will run against.
• Application: Name of the application the
Business Rule is part of.
• Active: Enables/disables
• Advanced: Select to display all Business Rule
configuration options.
• When to run Section
• When: Select when the Business Rule logic
executes relative to the database access.
• Order: Order of execution for Business Rules
for the same table. Execute in ascending
order. By convention, but not required, use
Order values in round values of one hundred:
100, 200, 300, etc.
• insert: Select to execute the Business Rule
logic when new records are inserted into the
database.
• Update: Select to execute the Business Rule
logic when records are modified.
• Delete: Select to execute the Business Rule
logic when records are deleted.
• Query: Select to execute the Business Rule
logic when the database table is queried.
• Filter Conditions: Add a condition to the
configuration such as State is 14. The Filter
Conditions must return true for the Business
Rule logic to execute.
• Role conditions: Select the roles that users
who are modifying records in the table must
have for this business rule to run.
• Controlling When Business Rules Run
• The When option determines when, relative
to database access, Business Rule logic
executes:
• before
• after
• async
• display
• Business Rule Actions
• Business Rule Actions are a configurable way
to:
• Set field values
• Add a message to a form
• Abort the Business Rule execution
• Business Rule Scripts
• Business Rules scripts use the server-side APIs
to take actions. Those actions could be, but
are not limited to:
• Invoking web services
• Changing field values
• Modifying date formats
• Generating events
• Writing log messages
• Dot-walking
• Dot-walking allows direct scripting access to
fields and field values on related records. For
example, the NeedIt table has a reference
field called Requested for. The Requested for
field references records from the Users
(sys_user) table. Reference fields contain the
sys_id of the record from the related table.
 Server-side APIs

• GlideSystem
• GlideRecord
• GlideDateTime
• GlideSystem
• Use the GlideSystem API to, for example:
• Find information about the currently logged in
user
• Log messages (debug, error, warning, info)
• Add messages to pages
• Generate events
• Execute scheduled jobs
• And more…
• GlideRecord
• The GlideRecord class is the way to interact with the
ServiceNow database from a script. See
the GlideRecord API reference for a complete list of
methods.
• GlideRecord interactions start with a database query.
The generalized strategy is:
• Create a GlideRecord object for the table of interest.
• Build the query condition(s).
• Execute the query.
• Apply script logic to records in the GlideRecord
object.
• GlideDateTime
• The scoped GlideDateTime class provides
methods for performing operations on
GlideDateTime objects, such as instantiating
GlideDateTime objects or working with
glide_date_time fields.
• Debugging Business Rules
• So far in this module, debugging has primarily
been:
• Using the Script Editor to find JavaScript
syntax errors
• Examining scripts to look for errors
• Verifying the trigger is configured correctly
• Additional debugging strategies are:
• System Logs
• Debug Business Rule (Details)
• JavaScript Debugger
• ystem Logs
• The scoped GlideSystem API has logging
methods:
• gs.info()
• gs.warn()
• gs.error()
• gs.debug() (must be enabled)
 Securing Applications Against
Access from Other Applications

• Application Access is set at the table level and

allows developers to:
• Grant read, create, update, and delete
privileges
• Grant access to the table through web
services
• Allow application files from other application
scopes to add new fields to the table
• Permit other application scopes to create
application files for the table:UI actions
• Client Scripts
• Use Runtime Access Tracking to manage
script access to resources from other
applications.
• This is known as cross-scope access because
the records are in different application scopes
• None: No authorization required for application scripts to
access resources from other applications as long as the other
application allows it. No record is created in the Application
Cross-Scope Access table.
• Tracking: Allows application scripts to access resources from
other applications. A record for the access is automatically
inserted in the Application Cross-Scope Access table with
a Status value of Allowed. This is the default setting.
• Enforcing: Allows application scripts to access resources from
other applications only after an admin authorizes the access.
A record is automatically added to the Application Cross-
Scope Access table with a Status value of Requested