SNOW
Studio
Security
Access Controls.
Retict access
Create
Read
Write
Delete
Create Access Control
Admin can only view
elevated security
All Access Control except read
AKA security_admin
User menu -> Elevate Roles
Can be created
Records
Client callable Script Includes
Processors
REST Endpoints
UI Pages
Access Control Evaluation Order
ACL: Access Control List
Ordered List
Inheritance
Access Control Configuration Watcher
To or Not to
--None--
*
Grant access to records and all fields in the records
Grant access to all fields where there is no field-specific Access Control 
Runtime Access Tracking
Manage script access to resources from other applications
cross-scope access because the records are in different application scopes
None
Tracking
Enforcing
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.
Application Cross-Scope Access table
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
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
Status value of Requested
Status value of Allowed
Default behavior
System Applications > Application Cross-Scope Access
Ex: needit app access incident table in Global
var gr = new GlideRecord('incident');
gr.query();
Error
FIx
Open Application Cross-Scope Access . Set Status Requested to Allow
Granted for
Table: Read, Write, create, delete records
Script Include
Scriptable
Must set before application are installed on another instance
Restrict Table Choices
limits application files configuration to only tables from the current application
Workflow
sequence of activities to automate processes in applications
Triggred by
filed value on a record
UI Action
Server-side script
When to use
Approval
SLA
Task creation
Event generation
Email Notification
Workflow Editor
Create
In Studio: Creation Application File → Workflow
Context
A context loads the workflow definition at time of launch
A context is created when a workflow is launched
workflow's runtime environment
Regardless of the number of changes to a workflow definition, contexts continue to run using the workflow definition at the time of launch. In addition to loading a workflow, contexts also know which record the workflow was launched for.
Can have 3 states
Checked out
Published
Unpublished
Only one published version of a workflow exists in runtime for new contexts
Service Portal
?
A portal is a ServiceNow user interface (UI), built using the Service Portal framework, which provides an alternative user experience to the standard UI.
It is an intuitive way for users to interact with the underlying Now Platform using a minimum number of clicks from any device: desktop, tablet, or smartphone
can access any platform
Selected records from important tables, such as all tasks assigned to the user
Metrics, reports, and analytics
Service Catalog
Knowledge Base
Surveys
User profile
Approvals
Portal Anatomy
Pages
?
Each portal is made up of one or more pages. Pages are not unique to a portal and can be used in as many portals as needed. A portal applies theming, a header, a footer, and some additional metadata to a page, allowing reuse without changes to a page's definition
Containers
Portal pages are organized by containers. Containers create the page layout by organizing pages into sections. Containers are divided into rows. Containers typically contain a single row but can have multiple rows. Each row has a specified number of columns. Each row can contain a different number of columns
Widget
Widgets define the content for a portal. The default portal container shown is one row which contains three columns. Although in this example, each column contains two widgets, each column can contain any number of widgets.
Service Portal Framework
?
The Service Portal framework is a set of tools, APIs, AngularJS services and directives, and components used to create portals. The Service Portal Framework helps developers and non‑technical administrators create attractive and engaging user experiences which drive employee adoption of critical enterprise applications
Service Portal Configuration
Branding Editor
Designer
Page editor
Widget Editor
New Portal
Get Help
Reusability component which make up the functionality of a page
Widget Option ?
Fix / Fluid
Page Editor
provides a tree view of every element on a portal page. Using the tree, developers can open the record for any element on the page to examine and change element configuration
Branding Service portal
Flow Designer
A flow is a sequence of actions to automate processes on the Now Platform
Trigger
Actions
A trigger identifies what causes the flow to execute
Record creation and/or update
Schedule
Service Catalog request
MetricBase
When triggered, the flow progresses through a series of actions. ServiceNow provides a core group of actions to use in flows
Ask for Approval
Create Task
Look Up Records
Send Email
Update Record
Flow Designer roles
flow_designer: create and edit flows
flow_operator: view flow execution details, dashboards, and logs
action_designer: create and edit custom actions
Terminology
Flow tabs: Flow icon displays on flow tabs Configure flow triggers and actions
Subflow tabs: Subflow icon displays on subflow tabs Configure subflow inputs, outputs, and actions.
Action tabs: Action icon displays on action tabs Configure action inputs, outputs, and steps
Flow execution tabs: Flow execution icon displays on flow execution tabs View details captured from the execution of a flow.
three types of triggers
Record: Execute the flow when a record is created or updated on a table
Date: Execute the flow at a specific time or interval.
Application: Execute the flow from an application.
Date Triggers
Flows that run on a regular basis use Date triggers.
Daily
Weekly
Monthly
Run Once
Repeat
Actions define the work performed by a flow
Flow Exection
A flow execution is created when a flow executes.A flow execution loads the flow configuration at execution time. Regardless of changes to a flow configuration, flow executions continue to run using the flow configuration at the time of execution
States
Completed: The flow successfully ran all actions
Waiting: The flow execution paused and is waiting for an action to complete
Error: The flow execution stopped with an error
Status
Draft - the flow has saved changes that have not been activated
Modified - the flow has unsaved changes
Published - the flow is active
Ask for Approvals Action
Flow Designer can create approvals for any record in ServiceNow. Use the Ask For Approvals action to request approvals
Requires
The Record to approve
The rules to approve and reject
The due date for approval (optional)
Flow Designer automatically populates the Table field from the record to approve
must have a field to indicate approval status and a field to track the approval history.
Approval Field: Specify the approval status field from the Table for the record to approve
Journal Field: Specify the approval history field from the Table for the record to approve.
For tables that do not extend Task, create an approval field with data type Choice and a journal field with data type Journal to track approval details for a record
Configuring Approval Rules
Every Ask for Approval action needs an Approve rule and a Reject rule to ensure that the action returns the expected Approval State.
Configuring Approval Due Date
Use the Due Date section to configure a time-based approval or rejection to allow the action to complete.
Actual date: A date identified by a data pill
Relative date: Some amount of time after the date identified by a data pill
Flow Logic
Flows can contain flow logic to execute conditional or repeated actions
Decision
Decision Table
A Decision Table maps decision inputs to decisions. Decision inputs are configuration fields that specify the information needed to make a decision
Decision record
Each Decision record is the list of conditions used to reach one answer.
The Decision Table is associated with an Answer table. Decisions are mapped to records in the Answer table. Answer table records are the branches for Make a decision flow logic.
Create Decision Table
Decision Tables > Decision Tables. Click the New button
Scheduled Script Executions and Events Objectives
Scheduled Script Executions, also known as Scheduled Jobs, are automated, server-side script logic that executes at a specific time or on a recurring basis
Use Scheduled Script Executions when application processes require script logic to be executed based on a time schedule
Scheduled Script Execution scripts run server-side and therefore use the server-side API. Unless an administrator clicks the Execute Now button, Scheduled Script Executions are not triggered by user interactions. Scheduled Script Executions are not associated with records and have no access to the previous or current objects used by many other server-side script types.
Two fields
Condition
Run this script
Use a Condition script to write server-side logic to determine if the script in the Run this script field should execute
The Condition script must set the answer variable to true for the Run this script field's script to execute.
What are events
Events are an indication in ServiceNow that something notable has occurred. Events can be generated by server-side scripts, workflows, ServiceNow processes, or by user actions
Event Registry
ServiceNow can only respond to events that are registered with the Event Registry. Registering an event lets the ServiceNow processes recognize and respond to the event
Generate Events
Server-side script using the gs.eventQueue() method
Workflow Create Event activity
System Policy > Events > Event Log
Responding to Events
Email Notification
Script Action