Process Flow

What It Is

Process Flow renders horizontal visual indicators on forms, showing users where they are in a multi-step process through connected dots or bars. It transforms abstract state transitions into clear visual guidance by mapping field values (typically state fields) to labeled steps with completion indicators. The feature solves the fundamental problem of users feeling lost in complex workflows where they can't see progress, next steps, or how far they've come.

Architecturally, Process Flow lives in the User Experience (UX) application as a form decoration component. It operates in the presentation layer, consuming data from the underlying record but not modifying it. Process Flow definitions (sys_process_flow table) define the steps and logic, while Form Layout sections control where the visual appears on specific forms. The component integrates with the form rendering engine and updates dynamically as users modify watched field values.

The data model centers on the Process Flow definition record, which contains step configurations, field mappings, and display rules. Each step maps to specific field values (usually choice field options) and can include conditions, labels, and visual states. The execution environment reads the current record's field values, matches them against step definitions, and renders the appropriate visual state. Process Flow also supports branching logic where different record states can show different step sequences.

You cannot function without Process Flow in scenarios involving complex approval workflows, multi-stage incident resolution, or any process where users need visual confirmation of progress. Service portals with multi-step request forms become unusable without clear progress indicators. Employee onboarding, change management, and project approval processes all depend on Process Flow to prevent user confusion and abandonment. Without it, users constantly ask "where am I in this process" and "what happens next," creating support burden and process friction.

ServiceNow administrators own Process Flow configuration, defining steps, mappings, and form placement. Developers handle advanced scenarios requiring custom conditions or dynamic step generation through script-based logic. Platform owners manage the overall user experience strategy and decide which processes warrant visual indicators. The relationship typically involves administrators implementing developer-designed flows based on platform owner requirements. Form designers and UX specialists often influence the visual presentation and step labeling.

Recent ServiceNow releases enhanced Process Flow with improved Next Experience UI compatibility and better responsive design. Vancouver introduced more flexible step condition logic, while Xanadu improved performance for forms with multiple Process Flow sections. The feature now supports dynamic step hiding/showing based on user roles or record conditions, and integrates better with Workspaces. Legacy UI Agent Workspace compatibility remains strong, but Next Experience implementations require specific configuration considerations for optimal rendering.

Where to Find and Configure It

Primary Process Flow configuration lives at User Experience (UX) > Process Flow > Process Flow where you create and manage Process Flow definitions. This module contains the sys_process_flow table list where you define steps, field mappings, and visual configurations. Access step configuration through User Experience (UX) > Process Flow > Process Flow Steps to manage individual step definitions and their associated field values.

Form Layout configuration happens at System UI > Form Layout where you add Process Flow sections to specific forms. Studio access provides form editing through Studio > Forms with drag-and-drop Process Flow section placement. App Engine Studio users find Process Flow configuration in the form designer under Experience > Forms when building scoped applications. Scoped applications require Process Flow definitions created within the application scope, while global Process Flows work across all applications.

How It Works Step by Step

Process Flow operates as a client-side form decorator that reads the current record's field values and matches them against configured step definitions. When a form loads, the Process Flow section queries the associated Process Flow definition and its related steps, evaluating conditions and field mappings to determine which steps to display and their current states. The component continuously monitors watched fields for changes, updating the visual indicator in real-time as users modify values.

The system maintains no separate state beyond the underlying record data, making Process Flow purely presentational. Step configuration defines which field values trigger "completed," "current," or "pending" visual states through exact value matching or script-based conditions. Advanced implementations can include role-based step visibility, dynamic step generation, and conditional branching where different record states show entirely different step sequences.

The Execution Order

1. Form loads and identifies Process Flow sections in the layout configuration
2. System queries the specified Process Flow definition record from sys_process_flow
3. Process Flow Steps (sys_process_flow_step) are loaded and ordered by sequence number
4. Each step's visibility conditions are evaluated against current user and record context
5. Step states are determined by comparing the watched field's current value to step trigger values
6. Visual components render with appropriate styling (completed, current, pending, or hidden states)
7. Client-side change listeners attach to watched fields for real-time updates

// Example step condition script for incident state
// Checks if current state matches step requirements
// and user has appropriate role visibility

var currentState = current.state.toString();
var requiredState = step.trigger_value.toString();
var userRole = gs.hasRole('itil');

// Step shows as completed if state has progressed beyond this step
if (parseInt(currentState) > parseInt(requiredState)) {
    answer = 'completed';
}
// Step shows as current if state exactly matches
else if (currentState == requiredState && userRole) {
    answer = 'current';
}
// Step shows as pending if state hasn't reached this step yet
else if (parseInt(currentState) < parseInt(requiredState)) {
    answer = 'pending';
}
else {
    answer = 'hidden';
}

Real-World Scenarios

Incident Resolution Progress Tracking

Your organization needs to show users clear progress through incident states from New to Resolved, helping both agents and customers understand the resolution process. The Process Flow should reflect standard ITIL incident states with appropriate visual indicators for each stage.

Create a Process Flow definition with Table: incident [incident] and Field: State. Add Process Flow Steps for each state: New (1), In Progress (2), On Hold (3), Resolved (6), Closed (7) with corresponding Trigger Values matching the choice field values. Set step labels to user-friendly names like "Reported," "Investigating," "Waiting," "Fixed," and "Complete." Add the Process Flow section to the incident form layout above the activity stream.

Service Portal Request Approval Workflow

Service Portal users submitting requests need visual confirmation of approval progress, especially for multi-tier approvals involving manager and finance approval. The Process Flow must work in Service Portal context and handle approval state changes dynamically.

Configure a Process Flow for the sc_request table using the approval field as the trigger. Create steps for "Submitted" (requested), "Manager Review" (pending), "Finance Review" (pending), and "Approved" (approved). Use conditional logic to show/hide Finance Review step based on request cost using gs.hasRole('finance_approver') || current.total_cost > 1000 in step conditions. Add the Process Flow to Service Portal request forms through the portal page designer.

Employee Onboarding Task Completion Tracking

HR needs to track employee onboarding progress across multiple departments, showing completion of IT setup, facilities access, training completion, and manager introduction. The Process Flow should work on custom onboarding case records and reflect completion based on related task states.

Build a custom field onboarding_phase on your onboarding table with choice values for each major milestone. Create a Business Rule that updates this field based on related task completion percentages using GlideAggregate to count completed tasks by category. Configure Process Flow steps for "IT Setup," "Facility Access," "Training," and "Complete" with custom step conditions that evaluate task completion rather than simple field values. Use role-based visibility to show different step details to HR, IT, and facilities teams.

The Classic Mistake

Admins routinely create Process Flow definitions that include states the record will never actually reach, or skip states that are part of the workflow. For incident management, they'll create a flow showing New > In Progress > Resolved > Closed but the actual workflow transitions directly from In Progress to Closed based on business rules. They configure the Process Flow Formatter on the form with Process flow set to their idealized flow, and State field pointing to state. The process bar appears but behaves erratically—highlighting steps that were never reached, showing the wrong current position, or displaying completed steps as pending.

This fails because Process Flow compares the current record's state value against the Value field in each Process Flow Stage to determine position and completion status. When the record state jumps from 3 (In Progress) directly to 6 (Closed), but your Process Flow Stage has Value set to 4 (Resolved), ServiceNow marks that stage as completed even though the record was never in that state. Users see misleading progress indicators that don't match their actual process experience. The non-obvious part is that Process Flow relies purely on numeric comparison—it assumes any state value higher than the stage value means that stage was completed.

// Process Flow Definition: Incident Simplified Flow
// Record: Process Flow [sysevent_email_action]
// Name: Incident Simplified Flow
// Table: incident [incident]
// Active: true

// Process Flow Stage 1:
// Stage: New
// Value: 1
// Order: 100

// Process Flow Stage 2:
// Stage: In Progress  
// Value: 2
// Order: 200

// Process Flow Stage 3:
// Stage: Closed
// Value: 6
// Order: 300

// Skip the Resolved state (4) entirely since 
// business rules transition directly from In Progress to Closed
// Only include states that records actually reach in practice

When to Use This vs Alternatives

Process Flow is the right choice when you have a linear, state-driven workflow where users need constant visual feedback about their position in a multi-step business process. It excels for case management, request fulfillment, and approval workflows where the psychological benefit of showing progress increases user confidence and reduces status inquiries.

Use Process Flow When

Your workflow has 3-7 distinct stages that follow a predictable sequence, and users frequently ask "where is my request?" Process Flow beats custom UI pages because it requires no scripting and automatically updates based on state changes. It outperforms email notifications for status updates because it provides persistent, visual context that users can reference anytime they return to the record.

Use Workflow Activities Instead When

Your process involves parallel tasks, conditional branching, or human approvals that don't map to simple state progression. Workflow activities provide detailed activity logs and can handle complex routing that Process Flow cannot represent. Choose Flow Designer over Process Flow when you need to orchestrate actions across multiple tables or integrate with external systems during the process.

Use Both Together When

You have complex backend orchestration that needs simple frontend visualization. Run Flow Designer or Workflow for the business logic and state management, then use Process Flow purely for the visual progress indicator on forms. This combination gives users the progress visibility they want while maintaining sophisticated process automation behind the scenes.

Platform Interactions & Side Effects

• Process Flow definitions are stored in wf_workflow table with template=process_flow, while stages use wf_stage records with ola field pointing to the workflow
• UI Policy and Client Scripts can interfere with Process Flow rendering—policies that hide/show the state field will cause the progress bar to disappear or display incorrectly
• ACLs on the state field affect Process Flow visibility—users without read access to the state field cannot see the progress bar, even if they can view the form
• Business Rules that modify state values trigger recalculation of Process Flow position, but changes made through GlideRecord.setValue() in background scripts don't refresh the UI automatically
• Update Sets capture Process Flow definitions and stages, but changes to choice lists for state fields require separate update set inclusion
• Process Flow calculations happen client-side through the ProcessFlow UI Script, which can cause delays on slow connections or when forms have many formatters
• Mobile applications render Process Flow differently—the UI16 mobile interface shows simplified progress indicators that may not match desktop appearance
• Process Flow formatters inherit form view restrictions—flows configured on default view won't appear on mobile or custom views unless explicitly added
• Domain separation affects Process Flow visibility—flows created in one domain are not visible to records in other domains, even for the same table
• Performance impact increases with the number of active Process Flow formatters on a form—each formatter makes additional database calls to retrieve stage configuration during form load

Debugging and Troubleshooting

The most common failure is Process Flow appearing as an empty gray bar or not showing at all. Users report seeing "the progress bar is broken" while admins see no obvious configuration errors. This typically manifests when the Process Flow Formatter is correctly configured but the underlying Process Flow definition has inactive stages, mismatched state values, or the state field contains values not defined in any stage. Check System Log > All for JavaScript errors related to ProcessFlow.js and look for messages like "Cannot read property of undefined" or "Stage configuration not found."

Another frequent issue is stages displaying in wrong sequence or showing incorrect completion status. This happens when the Order field values in Process Flow Stages don't follow logical progression, or when state field values don't align with business process reality. The browser's developer console will show REST API calls to /api/now/ui/process_flow that return unexpected stage arrays. Enable debug logging for com.glide.ui.process_flow to see server-side stage resolution.

Process Flow performance problems manifest as slow form loading or progress bars that appear several seconds after the rest of the form. This occurs when multiple Process Flow formatters exist on the same form, or when the referenced state field has complex business rules that delay value calculation. Monitor Stats > Slow Queries for excessive queries against wf_workflow and wf_stage tables.

Diagnostic Checklist:

• Verify Process Flow definition is Active and has Table field matching your form's table
• Check all Process Flow Stages are Active with sequential Order values (100, 200, 300, etc.)
• Confirm stage Value fields contain actual choice list values from your state field
• Test Process Flow Formatter configuration: correct Process flow and State field references
• Validate user has read access to the state field via Access Controls (ACLs)
• Review Browser Developer Console for JavaScript errors during form load
• Check for conflicting UI Policies or Client Scripts affecting state field visibility

Quick Reference

• Maximum 10 stages per Process Flow definition—additional stages cause client-side performance degradation and layout issues
• Process Flow calculations use string comparison, not numeric—stage with Value='10' appears before Value='2' alphabetically
• Mobile UI truncates stage names after 12 characters—design stage labels for mobile-first display
• Process Flow formatters only work on form views—they don't render in lists, related lists, or portal pages
• Each form can have multiple Process Flow formatters, but only the first one loads correctly—additional formatters cause JavaScript conflicts
• Process Flow definitions with identical Table values create ambiguous resolution—ServiceNow picks the first Active definition alphabetically by Name
• Stage Value field supports variables—use ${gs.getProperty()} for environment-specific state mappings
• Cloning records preserves current Process Flow position based on cloned state value, not resetting to first stage
• Process Flow requires exact state field name match in formatter—using u_state instead of state breaks functionality silently
• Scoped applications can access global Process Flow definitions, but global apps cannot reference scoped Process Flows due to namespace isolation