
|
-A user with the teamdev_user role on the registered
exclusion policy
|
Developers can create an _____________ to prevent pushes or pulls to particular instances in the team development
hierarchy
| ![]() |
code review
|
Team Development administrators can require that pushes
undergo ___________ before accepting pushes
| ![]() |
code review
|
When enabled, pushing a change to the parent instance
triggers the ____________ workflow
| ![]() |
Code Review Workflow
|
Notifications are sent out by the ______________ to thereviewers group when:
-A push requires code review
-A user cancels a push
| ![]() |
Code Review Workflow
|
-Starts when changes are pushed to the parent instance
-Verifies that the code review property is active on the parent instance
-Sets the stage of changes requiring approval to Awaiting Code review
-Notifies the Team Development Code Reviewers group to review the pushed changes
-Loads approved changes or set the stage to Code
Changes Rejected
| ![]() |
Update Set
|
A group of configuration changes that can be moved from
one instance to another
| ![]() |
Update Set
|
Allows administrators to group a series of changes into a named set and then move them as a unit to other systems
for testing or deployment
| ![]() |
Captured in Update Set -Customization
-Tables & Fields
-Reports

Not Captured in
Update set
|
-DFoartma,sNew Records
-Configuration Items
| ![]() |
-Schedules
| ||
-Users
| ||
-Groups
|
True
|
True//False: Update sets track customizations where the
table has an "update_synch" dictionary attribute
| ![]() |
update set
|
An ___________ is an XML file that contains:
-A set of record details that uniquely identify the update set
-A list of configuration changes
-A state that determines whether another instance can retrieve and apply configuration changes
| ![]() |
special handlers
|
Things tracked with _____________:
-Workflows
-Form sections
-Lists
-Related lists
-Choice lists
-System dictionary entries
-Field labels
| ![]() |
False
|
True//False: More than one update set can be the default
set for any application scope
| ![]() |
ServiceNow Best Practices for Update Sets
-Do not delete update sets, if an update set is deleted, any
updated record maybe overwritten in the next update



-Do not back out the Default update set, causes damage to the system
-Never change the Update Set field value in a Customer Update record
-Do not mark an update set as Complete until it is ready to
migrate. Once complete, do not change it back to "In progress".
-Do not manually merge updates into an update set, always use the Merge Update Set module
-If a committed update set has a problem in the test instance, build the fix in another update set in the development instance
-Always preview an update set before committing it
-Set completed update set on the production instance to "Ignore"
-Keep a to-do list of manual changes and data loads that need to be completed after an update set is applied
-Do not make too many changes at one time, verify that
the correct changes have been made incrementally
|



Line Column Area Spline Bar Pareto
Histogram Pie
Donuts and semi-donuts Speedometer
Dial Pivot
Multilevel pivot tables Heatmap
Map Bubble Pivot table Funnel Calendar Pyramid Box
Trend
Control Trendbox
Single score
|
Auto Map Matching Fields
|
Which utility is used to determine if field names in an Import Set match the field names on the target table when
importing data into ServiceNow?
| ![]() |
Good fit for ServiceNow
|
-Data can be modeled in a relational database
-Extensive use of forms to interact with data
-Needs reporting
-Needs workflow to manage processes
| ![]() |
Bad fit for ServiceNow
|
-Data is unstructured such as audio or video
-Requires "as-is" use of low level programmatic libraries
-Multiplayer games or apps that need a game engine
-No process flow through application
| ![]() |
False
|
True//False: ServiceNow is good for real-time data
delivery and update form external sources
| ![]() |
False
|
True//False: ServiceNow is good for media streaming
| ![]() |
Extensible
|
The option in Table configuration that allows this table to
be extended from
| ![]() |
Columns, Controls,
Application Access
|
Sections of the configuration for Table
| ![]() |
Module
|
Links available to display within application menu
| ![]() |
Link type
|
_________________field on the Module form specifies what type
of link the module opens.
| ![]() |



-Content Page
-Documentation Link
-Homepage
-HTML
-List Filter
-List of Records
-Map Page
-New Record
-Run a Report
-Script
-Search Screen
-Separator
-Single Record
-Survey
-Timeline
-URL
|
$m.do
|
How to get to the mobile version of the application
| ![]() |
Form Header
|
Form element: Provides navigation tools and actions
related to the record
| ![]() |
Sections
|
Form element: Stores specific data about the record
| ![]() |
Related links
|
Form element: Provides access to additional functions based on record type and system setup. Administrators
can add related links to form using UI actions.
| ![]() |
Related lists
|
Form element: Displays records in other tables that have
relationships to the current record.
| ![]() |
Embedded lists
|
Form element: Allows for editing related lists without having to navigate away from the form. Changes are saved
when the form is saved.
| ![]() |
Response time indicator
|
Form element: Appears at the bottom of some forms to
indicate the processing time required to display the form.
| ![]() |
Form Designer
|
Drag and drop interface used to:
-Create form layouts
-Create form views
-Create and delete form sections
-Add fields to tables
| ![]() |
Fields, Field Types
|
Components of the Field Navigator
| ![]() |
Fields
|
A list of all fields from the selected table that are not
already part of the form layout
| ![]() |
Field Types
|
A list of data types that can be used to create new table fields. The Form Layout is used to create and edit fields,
sections, and annotations
| ![]() |
onLoad, onChange, onSubmit, onCellEdit
|
The Client Script Types:
| ![]() |
Active
|
Option in the configuration that controls whether the script
is enabled. Inactive scripts do not execute.
| ![]() |
control, oldValue, newValue, isLoading,
isTemplate
|
The parameters for the onChange function
| ![]() |
GlideForm (g_form) Class
|
______________ 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 fields to a choice list
| ![]() |
GlideUser (g_user) Class
|
_________________ API provides methods and non-method properties for finding information about the currently
logged in user and their roles
| ![]() |
Yes
|
g_user.hasRole('x_foo_app_user'), does this return true for
the admin role?
| ![]() |
Client-side debugging
|
-JavaScript Log and jslog()
| ![]() |
& UI Policies debugging
|
-Field Watcher
| |
-Try/catch
| ||
-Debugging tools built into web browsers (browser
| ||
dependent)
|
Field Watcher
|
Tracks and displays information about actions ServiceNow
performs on a form field
| ![]() |
UI Policies
|
Client-side logic which governs form and form field behavior. Unlike Client Scripts, UI Policies do not always
require scripting
| ![]() |



attributes:
-Mandatory
-Visible
-Read-Only
|
UI Policy Scripts
|
Client-side API to execute script logic based on whether
the UI Policy conditions tests true or false
| ![]() |
-Business Rules
-Script Includes
|
Two types of server-side scripts:
| ![]() |
Business Rules
|
Server-logic which execute when database records are
queried, updated, inserted, or deleted
| ![]() |
Before, After, Async,
Display
|
The "When" options for Business Rules:
| ![]() |
Before
|
Business Rules execute their logic before a database
operation occurs
| ![]() |
After
|
Business Rules execute their logic immediately after a database operation occurs and before the resulting form is
rendered for the user
| ![]() |
Async
|
Business Rules execute asynchronously
| ![]() |
Display
|
-Business Rules execute their logic when a form loads and a record is loaded from the database
-Processed when a user requests a record form
-Primary objective is to use a shared scratchpad object, g_scratchpad, which is also sent to the client as part of the form.
| ![]() |
Condition Field
|
Used to specify when the Business Rule script should
execute
| ![]() |
Business Rules
|
_____________ often use the current and previous objects in
their script logic
| ![]() |
current
|
____________object
• Automatically instantiated from GlideRecord class
• Properties are all fields for a record and all the GlideRecord methods
• Property values are values as they exist in the runtime
environment
| ![]() |
No comments:
Post a comment