Mastering ServiceNow Administration
Complete Course Guide

Course Overview

This course covers everything a ServiceNow Administrator needs to know — from platform fundamentals to advanced scripting, ITSM modules, integrations, and automation. By the end, you will be prepared for real-world admin roles and the ServiceNow CSA (Certified System Administrator) certification.

Topics You Will Master

Why You Need a Developer Account

To practise ServiceNow, you need access to a live instance. ServiceNow provides free Personal Developer Instances (PDIs) to registered developers. Without one, you cannot practise the hands-on skills that employers require.

1. Go to developer.servicenow.com
2. Click Sign Up and fill in your personal details (name, email, location).
3. Use a personal email address — not a work or college email.
4. Verify your email address by clicking the link ServiceNow sends you.
5. Log in and click Request Instance.
6. Select the latest available release (e.g., Zurich/Xanadu).
7. Wait 10–15 minutes — your instance URL will be emailed to you.
8. Log in with username admin and your set password.

ServiceNow Career Pathways

ServiceNow has over 40 products and several career tracks. Understanding which path suits you helps you focus your learning effectively.

Recommended Learning Path for Beginners

1. Complete this administration course end-to-end.
2. Set up your PDI and practise every topic hands-on.
3. Complete the free ServiceNow Fundamentals course on nowlearning.servicenow.com.
4. Attempt the CSA exam — 60 multiple-choice questions, 90 minutes, 70% passing score.
5. After CSA, pursue CAD or a CIS specialisation based on your job role.
6. Join the ServiceNow Community at community.servicenow.com for real-world support.

Who is a User in ServiceNow?

A user is anyone who logs into your ServiceNow instance. This includes IT staff (agents/admins), end users (employees raising requests), and managers (approvers). All users are stored in the sys_user table.

Key User Fields

Step-by-Step: Create a User

1. Navigate to User Administration > Users.
2. Click New.
3. Fill in User ID, First Name, Last Name, and Email.
4. Set Department and Manager.
5. Click Submit.
6. To set a password: open the user record → click Set Password in the top right.
7. To add to a group: scroll to the Groups related list → click Edit.

Groups and Roles

Groups are stored in sys_user_group. Roles are stored in sys_user_role. Assign roles to groups, not individual users — this makes access management scalable.

The ServiceNow UI Structure

Understanding the UI terminology is essential — these terms come up constantly in admin work, documentation, and interviews.

Useful Navigation Shortcuts

The ServiceNow Product Portfolio

ServiceNow is not just an ITSM tool — it's a platform with 40+ products across multiple business domains. Understanding the product landscape helps you speak intelligently with clients and understand the full scope of admin possibilities.

How ServiceNow is Delivered

ServiceNow is a cloud-based, multi-instance SaaS platform. Each customer receives a dedicated instance — not shared infrastructure — which provides security, performance isolation, and the ability to customise without affecting other customers.

The 3-Instance Architecture (Standard)

How Data Flows: User → Group → Role → Access

1. Company purchases ServiceNow → receives instance URLs.
2. Admin creates User accounts for each employee.
3. Admin creates Groups (e.g., Network Team, Service Desk).
4. Admin assigns Roles to Groups (e.g., itil role to Service Desk group).
5. Users are added to Groups → they inherit all group roles.
6. Roles control which modules, tables, and records users can see and edit.

Key Platform Concepts

What is an Incident?

An incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service. The goal of incident management is to restore normal service operation as quickly as possible with minimal business impact.

Incident Lifecycle

Key Incident Fields

Priority Matrix (Impact × Urgency)

Step-by-Step: Create an Incident

1. Navigate to Incident > Create New.
2. Set the Caller (who reported it).
3. Enter a clear Short Description.
4. Select Category and Subcategory.
5. Set Impact and Urgency — Priority auto-calculates.
6. Assign to the correct Assignment Group.
7. Click Submit.

Incident vs Problem — The Critical Difference

Many people confuse incidents and problems. Here's the clear distinction:

Problem Lifecycle

Known Error Database (KEDB)

When the root cause of a problem is identified (even if not yet fixed), a Known Error record is created. This serves as a reference for the Service Desk — if an incident matches a Known Error, agents can apply the documented workaround immediately, reducing resolution time.

What is a Change?

A change is the addition, modification, or removal of anything that could have an effect on IT services. Change Management ensures changes are implemented in a controlled, risk-assessed manner to prevent incidents caused by poorly planned changes.

Change Types

Change Lifecycle (Normal Change)

1. New — Change request created with justification, risk, and implementation plan.
2. Assess — Risk and impact assessed.
3. Authorize — Sent to CAB for review and approval.
4. Scheduled — Change window assigned and approved.
5. Implement — Change implemented during the scheduled window.
6. Review — Post-implementation review confirming success or documenting issues.
7. Closed — Change officially closed.

Change Risk Assessment

Every Normal and Emergency change must have a Risk Assessment completed before approval. ServiceNow provides a built-in Risk Calculator that scores changes based on configurable questions.

Rollback Plan — Why It's Mandatory

Every change must document a rollback plan — what steps will be taken if the change fails and the service needs to be restored. Without a rollback plan, a failed change can turn into a P1 incident with no clear recovery path.

Conflict Detection

ServiceNow can automatically detect change conflicts — when two changes affect the same CI during overlapping windows. The Conflict Detection feature flags these before the change is approved, preventing accidental double-changes.

What is Knowledge Management?

Knowledge Management captures, stores, and shares solutions and information across the organisation. It reduces incident resolution time (agents find answers faster), enables self-service (users solve issues themselves), and preserves institutional knowledge when staff leave.

Knowledge Article Lifecycle

Step-by-Step: Create a Knowledge Article

1. Navigate to Knowledge > Create New.
2. Select the Knowledge Base to publish to.
3. Choose a Category.
4. Enter a clear, searchable Short Description (this is the article title in search results).
5. Write the article body — use clear headings, steps, and screenshots.
6. Set Valid To date to ensure outdated articles are retired.
7. Click Publish (or Submit for Review if approval workflow is configured).

What is Form Design?

The Form Designer (or Form Layout) allows admins to control which fields appear on a record's form, in what order, how many columns, and how they are grouped into sections. It's one of the most frequently used admin tools.

Accessing Form Designer

1. Open any form (e.g., an Incident record).
2. Right-click on the form header bar (the grey bar at the top of the form).
3. Select Configure > Form Layout.
4. Alternatively, navigate directly: System UI > Forms.

Form Designer Actions

What are Form Sections?

Sections divide a form into logical groupings. For example, an Incident form might have sections: Incident Details, Resolution, and Related Information. Sections can be collapsed, improving readability of complex forms.

What are Views?

A View is a named form layout that shows different fields to different users. The same table can have multiple views — the correct view is displayed based on the user's role or a URL parameter.

Step-by-Step: Create a New View

1. Open the table's Form Layout (right-click form header → Configure → Form Layout).
2. In the View field at the top, click the dropdown and select New.
3. Enter a name for the new view (e.g., 'Manager View' or 'Mobile View').
4. Arrange fields specifically for this view's audience.
5. Save.

What are View Rules?

View Rules automatically switch which form view is displayed to a user based on conditions — such as their role, the record's state, or other field values. This ensures each user sees exactly the right fields for their context.

1. Navigate to System UI > View Rules.
2. Click New.
3. Set the Table (e.g., incident).
4. Set the View to show when the condition is met.
5. Set the Conditions (e.g., Role is 'itil', or State is 'Resolved').
6. Set the Order — lower order = higher priority.
7. Save and test by logging in as a user with the relevant role.

What is the Dictionary?

The Data Dictionary defines every field on every table in ServiceNow. It controls field labels, types, lengths, default values, mandatory settings, and reference relationships. The dictionary is the source of truth for all data definitions.

Dictionary Entry Key Properties

1. Navigate to System Definition > Dictionary.
2. Filter by Table name to find fields for a specific table.
3. Click a dictionary entry to open and modify it.
4. Common changes: update the Label, set/remove Mandatory, change Max Length.
5. Always capture dictionary changes in an Update Set before making them.

Field Types Reference

Choice Lists

For fields of type Choice, the options come from the sys_choice table. You can manage choices by right-clicking a choice field on a form → Configure Choices, or navigating to System Definition > Choice Lists.

What is Process Flow?

The Process Flow formatter displays a visual progress indicator at the top of a form, showing the current stage of a record's lifecycle. It gives users an at-a-glance view of where a record is in its process.

1. Navigate to System Definition > Process Flow.
2. Click New.
3. Set the Table (e.g., incident).
4. Add stages and map them to the table's State field values.
5. Save, then add the Process Flow formatter to the form layout via Form Designer.

Table Inheritance in ServiceNow

ServiceNow uses table inheritance (extension) extensively. A child table inherits all fields from its parent table, plus adds its own specific fields. This is one of the most important architectural concepts in ServiceNow.

What are Data Lookup Rules?

Data Lookup Rules automatically populate field values based on matching conditions — without any scripting. For example, automatically set the Assignment Group based on the Category and Subcategory of an Incident.

1. Navigate to System Policy > Data Lookup Rules (or search 'Data Lookup').
2. Click New.
3. Set the Table (e.g., incident).
4. Set the Field to set (e.g., assignment_group).
5. Add Match Conditions (e.g., category = 'network' AND subcategory = 'vpn').
6. Set the Value to assign (e.g., sys_id of Network Team group).
7. Set the Order — lower order = evaluated first.
8. Test by creating an incident with matching values.

What is an Update Set?

An Update Set is a container that captures configuration changes made in ServiceNow so they can be exported from one instance and imported into another (e.g., Dev → Test → Prod). Update Sets are the primary mechanism for moving customisations through environments.

What Update Sets DO and DON'T Capture

Step-by-Step: Using Update Sets

1. Navigate to System Update Sets > Local Update Sets.
2. Click New → give it a descriptive name (e.g., 'INC-123 Fix Priority Field').
3. Set it as your Current Update Set (click 'Make Current').
4. Make all your configuration changes — they are automatically captured.
5. When done, open the Update Set and click Complete.
6. Click Export to XML to download the update set file.
7. In the target instance: System Update Sets > Retrieved Update Sets → Import XML.
8. Click Preview to check for conflicts, then Commit.

Working with Tables

ServiceNow has 6,000+ tables. Understanding how to navigate, filter, and query them is a core admin skill — both through the UI and scripts.

Accessing Tables

Building List Filters

The Filter Builder (breadcrumb area above a list) lets you build complex queries visually:

1. Click the funnel icon above any list to open the Filter Builder.
2. Add conditions: Field + Operator + Value.
3. Use AND for all conditions to be true, OR for any.
4. Click Run to apply the filter.
5. Click Save to create a named filter for reuse.

GlideRecord — Querying Tables via Script

// Query all P1 Incidents assigned to the Network Team
var gr = new GlideRecord('incident');
gr.addQuery('priority', '1');
gr.addQuery('assignment_group.name', 'Network Team');
gr.query();
while (gr.next()) {
    gs.log('Incident: ' + gr.number + ' - ' + gr.short_description);
}

The Most Important Concept in ServiceNow Scripting

ServiceNow scripts run in two different environments: client-side (in the user's browser) and server-side (on ServiceNow's servers). Knowing the difference is fundamental — using the wrong type causes scripts to fail silently.

// WRONG - GlideRecord does NOT work in Client Scripts
function onChange(control, oldValue, newValue) {
    var gr = new GlideRecord('sys_user'); // ERROR: GlideRecord undefined
    gr.get(newValue);
}

// CORRECT - Use GlideAjax for server data in Client Scripts
function onChange(control, oldValue, newValue) {
    var ga = new GlideAjax('MyScriptInclude');
    ga.addParam('sysparm_name', 'getManager');
    ga.addParam('sysparm_user_id', newValue);
    ga.getXMLAnswer(function(answer) {
        g_form.setValue('manager', answer);
    });
}

What are Client Scripts?

Client Scripts run in the user's browser and control form behaviour in real-time — showing/hiding fields, validating input, auto-populating values, and preventing bad submissions. They are stored in the sys_script_client table.

Client Script Types

g_form API Reference

// Example: Show 'On Hold Reason' only when State = On Hold
function onChange(control, oldValue, newValue, isLoading) {
    if (newValue == '3') { // 3 = On Hold
        g_form.setVisible('hold_reason', true);
        g_form.setMandatory('hold_reason', true);
    } else {
        g_form.setVisible('hold_reason', false);
        g_form.setMandatory('hold_reason', false);
    }
}

What are UI Policies?

UI Policies control field visibility, mandatory state, and read-only state based on conditions — without requiring JavaScript. They're the no-code alternative to Client Scripts for simple field behaviour rules.

UI Policy vs Client Script — When to Use Each

1. Navigate to System UI > UI Policies (or right-click form → Configure → UI Policies).
2. Click New.
3. Set the Table.
4. Set Conditions (the when clause).
5. Enable Reverse if false to auto-undo when condition is no longer met.
6. Save, then open the UI Policy Actions related list.
7. Add actions: Field + Set Mandatory/Visible/Read-Only to true/false.
8. Test on the form.

Advanced UI Policy Techniques

Script field in UI Policy

For conditions too complex for the condition builder, enable Use scripts on the UI Policy to write a JavaScript condition that returns true/false.

// Show 'Escalation Reason' only for P1 or P2 incidents with SLA breach
function() {
    var priority = g_form.getValue('priority');
    var slaBreached = g_form.getValue('sla_due');
    var now = new Date();
    return (priority <= 2); // Show for P1 and P2
}

Catalog UI Policies vs Regular UI Policies

What are UI Pages?

UI Pages are custom HTML/JavaScript/CSS pages hosted within ServiceNow. They allow you to create completely custom interfaces — dashboards, wizards, confirmation dialogs, and landing pages — that go beyond what standard forms and lists support.

1. Navigate to System UI > UI Pages.
2. Click New.
3. Enter a Name (used in the URL: /instance.service-now.com/name.do).
4. Write your HTML — use Jelly tags for dynamic server data.
5. Write Client Script for browser interaction.
6. Write Processing Script for server actions (form submissions).
7. Access via URL: /your_page_name.do

What are UI Macros?

UI Macros are reusable HTML/Jelly snippets that can be embedded in UI Pages, form formatters, or other ServiceNow UI elements. They're the component library of classic ServiceNow UI development.

UI Macro vs UI Page

1. Navigate to System UI > UI Macros.
2. Click New.
3. Enter a Name.
4. Write your XML/Jelly template.
5. To embed on a form: go to Form Design → add a Formatter element → select your macro.

What is a Data Policy?

A Data Policy enforces field rules (mandatory, read-only) at the database level — not just in the browser. Unlike UI Policies (browser-only), Data Policies are enforced regardless of how a record is accessed: via the UI, API, import, or scripting.

1. Navigate to System Policy > Data Policies.
2. Click New.
3. Set the Table and Conditions.
4. Add Data Policy Rules: Field + Mandatory/Read-Only.
5. Enable Apply to Import Sets if you want enforcement during imports.
6. Save and test.

What are Business Rules?

Business Rules are server-side scripts that run automatically when a record is inserted, updated, deleted, or queried. They are the most powerful automation tool in ServiceNow — running on the server with full database access regardless of how the record was modified.

Business Rule Timing

Common Business Rule Operations

// BEFORE Business Rule: Auto-set Priority from Impact & Urgency
if (current.impact == '1' && current.urgency == '1') {
    current.priority = '1'; // Critical
} else if (current.impact <= '2' || current.urgency <= '2') {
    current.priority = '2'; // High
}

// AFTER Business Rule: Create a follow-up task when Incident is resolved
if (current.state == '6' && current.state.changesTo('6')) {
    var task = new GlideRecord('sc_task');
    task.short_description = 'Follow up on resolved incident: ' + current.number;
    task.assignment_group = current.assignment_group;
    task.insert();
}

// Checking if a field changed
if (current.assignment_group.changes()) {
    // Assignment group was just changed
    gs.eventQueue('incident.reassigned', current, current.assignment_group, current.assigned_to);
}

What are Script Includes?

Script Includes are reusable JavaScript libraries stored in ServiceNow that can be called from Business Rules, Client Scripts (via GlideAjax), Scheduled Jobs, REST APIs, and other scripts. They're ServiceNow's equivalent of a shared function library.

Two Types of Script Includes

// Regular Script Include
var IncidentUtils = Class.create();
IncidentUtils.prototype = {
    initialize: function() {},
    
    getPriorityLabel: function(priority) {
        var labels = {'1':'Critical','2':'High','3':'Moderate','4':'Low','5':'Planning'};
        return labels[priority] || 'Unknown';
    },
    
    reassignToOnCallGroup: function(incidentSysId) {
        var gr = new GlideRecord('incident');
        if (gr.get(incidentSysId)) {
            gr.assignment_group.setDisplayValue('On-Call Team');
            gr.update();
        }
    },
    type: 'IncidentUtils'
};

// Call from Business Rule:
var utils = new IncidentUtils();
var label = utils.getPriorityLabel(current.priority);

What are Access Controls?

Access Control Lists (ACLs) define who can do what with which data in ServiceNow. They control read, write, create, and delete operations on tables and individual fields, evaluated against a user's roles and conditions.

ACL Components

ACL Evaluation Order

1. Is the user admin? → Full access, skip all ACL checks.
2. Is security disabled for this session? → Full access.
3. Find all ACL records matching the table/field and operation.
4. Sort by specificity (field ACLs override table ACLs).
5. For each ACL: check role → check condition → check script.
6. If any matching ACL grants access → allowed.
7. If no ACL matches or grants access → denied.

// ACL Script example: User can only edit incidents they created
// In the ACL 'Script' field:
answer = (gs.getUserID() == current.opened_by.sys_id || 
          gs.hasRole('itil_admin'));

What is Reporting in ServiceNow?

ServiceNow's built-in reporting engine allows admins and users to create visual reports from any table, share them, schedule email delivery, and publish them to dashboards — without any external BI tool.

Report Types

1. Navigate to Reports > Create New (or click 'New' in Reports).
2. Give the report a Name.
3. Select the Table to report on.
4. Choose the Report Type (bar, pie, list, etc.).
5. Configure the Group By field (x-axis for bar charts, slices for pie).
6. Add Filters to limit the data (e.g., only last 30 days, only P1).
7. Set Aggregation (Count, Sum, Average).
8. Click Run to preview, then Save.
9. Click Share to publish to specific users or groups.

What are Dashboards?

Dashboards are configurable pages that display multiple reports, widgets, and data visualisations in a single view. They provide at-a-glance operational visibility for managers, teams, and executives.

1. Navigate to Reports > Dashboards or Self-Service > Dashboards.
2. Click New → enter a name.
3. Choose a Layout (1-column, 2-column, 3-column, etc.).
4. Click the + button to add widgets.
5. Select Report to add an existing report, or choose other widget types.
6. Resize and rearrange widgets by dragging.
7. Click Share to grant access to specific users or groups.
8. Use Set as Homepage to make it the default landing page for a group.

What is an SLA?

A Service Level Agreement defines the committed response and resolution times for IT services. In ServiceNow, SLAs automatically track whether incidents and requests are being handled within agreed timeframes and trigger escalations when breaches occur.

SLA Components

1. Navigate to Service Level Management > SLA > SLA Definitions.
2. Click New.
3. Set the Name, Table, and Type (Response/Resolution).
4. Set the Duration (e.g., 4 Hours).
5. Select a Schedule (e.g., 8am–6pm Mon–Fri).
6. Define Start, Pause, Stop, Reset conditions.
7. Add Workflow or Notifications for breach alerts.
8. Save and test on a real incident.

OLA vs SLA vs UC

Metric Definitions

Metric Definitions work alongside SLAs to track additional time-based measurements on any field transition. They're useful for measuring things that aren't covered by SLAs — like 'time an incident spent in On Hold state'.

1. Navigate to Metrics > Definitions.
2. Click New.
3. Set the Table and the Field to track.
4. Define the Start and End conditions.
5. The metric automatically captures elapsed time between conditions for every matching record.
6. Use the captured data in reports to identify bottlenecks.

What are Notifications?

Notifications are automated email (or SMS/push) messages sent when specific events occur in ServiceNow. They inform users about record updates, approvals, SLA breaches, and assignment changes — keeping everyone in the loop without manual communication.

Notification Components

1. Navigate to System Notification > Email > Notifications.
2. Click New.
3. Set the Name and Table.
4. Choose the trigger: Record inserted/updated or Event fired.
5. Set Send when conditions (e.g., Priority changes to 1).
6. In the Who will receive tab: add users, field references (e.g., Caller), or groups.
7. In the What it will contain tab: write the subject and body using notification variables.
8. Test using Preview Notification before activating.

Subject: [${number}] Incident Assigned to You: ${short_description}

Body:
Hello ${assigned_to.first_name},

A Priority ${priority.getDisplayValue()} incident has been assigned to you.

Incident: ${number}
Summary: ${short_description}
Category: ${category.getDisplayValue()}

Please log in to review and begin work:
${URI_REF}

Thank you,
IT Service Desk

Event-Based vs Direct Notifications

Notifications can be triggered in two ways: directly (based on record insert/update conditions) or via the Event Queue (decoupled from record saves, fired explicitly by scripts).

How to Use Event-Based Notifications

1. Create the event in the Event Registry: System Policy > Events > Registry.
2. In a Business Rule or Script, fire the event: gs.eventQueue('incident.priority_escalated', current, gs.getUserID(), current.priority);
3. Create a Notification with Send When set to 'Event is fired'.
4. Select the event name from the Event Registry.
5. The notification fires whenever the event is queued.

What are Import Sets?

Import Sets allow you to load data from external sources (CSV, Excel, XML, JDBC, REST) into ServiceNow tables. They are the primary mechanism for bulk data loading — migrating legacy data, syncing HR records, or ingesting monitoring alerts.

Import Set Process

1. Prepare your data file (CSV is most common).
2. Navigate to System Import Sets > Load Data.
3. Select Create table or choose an existing import set table.
4. Upload your file — ServiceNow creates a staging table with your columns.
5. The data is now in the staging table — not yet in the target table.
6. Create a Transform Map to map staging columns to target fields.
7. Run the transform: System Import Sets > Run Transform.
8. Review the Transform Log for errors, skipped records, and successes.

Coalesce Fields — Finding Existing Records

The Coalesce setting on a Transform Map field tells ServiceNow to use that field as a unique key for matching existing records. If a record with the same coalesce value exists, it's updated; if not, a new record is inserted.

// Example: Import Set Transform Map with coalesce
// Field: email (coalesce = true) maps to sys_user.email
// If sys_user with this email exists → UPDATE
// If not → INSERT

Data Source Configuration (Scheduled Imports)

For recurring imports (e.g., nightly HR sync), configure a Data Source:

1. Navigate to System Import Sets > Data Sources.
2. Click New and configure the source type (File, JDBC, REST, etc.).
3. Link it to your Import Set Table and Transform Map.
4. Create a Scheduled Import to run automatically (e.g., every night at 1 AM).

Transform Map Deep Dive

Transform Maps are the intelligence layer of Import Sets — they define exactly how data flows from the staging table to the target table, including field mapping, data transformation, and conditional logic.

Transform Map Script Options

// Field Script Example: Map legacy status codes to ServiceNow states
// Source field 'legacy_status' maps to target 'state'
// In the Transform Map field script:
if (source.legacy_status == 'OPEN') {
    answer = '1';  // ServiceNow state: New
} else if (source.legacy_status == 'WIP') {
    answer = '2';  // Work in Progress
} else if (source.legacy_status == 'CLOSED') {
    answer = '3';  // Closed Complete
} else {
    answer = '1';  // Default to New
}

Quick Reference: Catalog Architecture

This lesson consolidates catalog knowledge from an admin perspective, focusing on maintenance and governance rather than initial setup.

Catalog Item Governance Best Practices

• Set Availability restrictions — don't show hardware items to contractors who can't order them.
• Use Delivery Time fields to set user expectations and reduce 'Where is my request?' tickets.
• Review and retire catalog items annually — stale items confuse users and inflate the catalog.
• Link every item to a workflow or flow — orphan items with no automation create manual work for Service Desk.
• Enable No Quantity for one-time requests to prevent users from ordering 10 laptops by accident.
• Use Variable Sets for common fields — this ensures consistent data collection across items.

Workflow Quick Reference for Admins

This lesson consolidates workflow knowledge with a focus on production management and troubleshooting.

Workflow Administration Tasks

Workflow Versioning

ServiceNow keeps all previous versions of a workflow. Running contexts use the version that was published when they started — updating a workflow doesn't break in-flight contexts. New contexts use the latest published version.

// Workflow script to access catalog item variables
// In a 'Run Script' workflow activity:
var ritm = current; // current = the RITM record
var laptop_model = ritm.variables.laptop_model + '';
var justification = ritm.variables.business_justification + '';

// Send an email with variable data
gs.eventQueue('send.custom.notification', ritm, laptop_model, justification);

Flow Designer — Admin Best Practices

As you transition from Workflows to Flow Designer, here are the admin-level considerations for managing flows in production.

Flow vs Workflow — Migration Guidance

Flow Designer Administration

1. Manage all flows: Process Automation > Flow Designer.
2. Check execution history: open a flow → Executions tab → click any execution for full log.
3. Deactivate a flow: open it → toggle Active to Off.
4. Flow versions: similar to workflows, flows maintain version history.
5. Error handling: add Error Handler steps to flows that call external APIs — API calls can fail.
6. Flow variables: use Flow Variables tab to define reusable data within a flow.

// Run Script action in Flow Designer
// 'inputs' holds values passed to the step
// 'outputs' is what you return

(function execute(inputs, outputs) {
    var incidentNum = inputs.incident_number;
    var gr = new GlideRecord('incident');
    gr.addQuery('number', incidentNum);
    gr.query();
    if (gr.next()) {
        outputs.caller_email = gr.caller_id.email + '';
        outputs.priority = gr.priority + '';
    }
})(inputs, outputs);