Flow Designer Pack

Chaotic-1

⚙ Technical Requirements

ServiceNow scoped application / admin access

Relevant ServiceNow product/plugins for the selected pack capability

Validate in sub-production before promoting through update sets or application repository

Automation Readiness: High — The process evidence clearly points to common process bottlenecks like user-wait states and high SLA breach rates, which are directly addressable with standard Flow Designer automations.

Flow Designer Pack — 4 rules

sn-flow-001

Proactive SLA Breach Warning Notification

Flow Designer Priority: Critical Effort: Low

To proactively notify assignees and their managers when an Incident's Resolution SLA is nearing breach, aiming to reduce the 60.2% SLA breach rate by prompting timely action.

Why this pack: This rule uses a time-based trigger (SLA percentage timer) and notification actions, which are core capabilities of Flow Designer and are not covered by other packs like SLA Definitions.

Trigger

SLA Task's 'taskslatable' percentage timer reaches 75%

Conditions

·Task's [SLA] > [Definition] contains 'resolution'

·Task's [State] is not one of [Resolved, Closed, Cancelled]

Actions

·Send email notification to the Incident's 'Assigned to' user.

·Send email notification to the manager of the Incident's 'Assignment group'.

Evidence used

·SLA breached?: Yes (60.2%)

·SLA breached count: 1 (42.2%), 2 (18.0%)

ServiceNow implementation

Target table

·incident

Configuration area

·Flow Designer

Configuration trigger

·SLA Task: Percentage Timer. Set Percentage to 75.

Configuration conditions

·Trigger record (SLA Task) -> Task -> State IS NOT ONE OF Resolved, Closed, Cancelled

·Trigger record (SLA Task) -> SLA Definition -> Name CONTAINS resolution

Implementation steps

·Get the Incident record from the trigger's 'Task' field.

·Action: Send Email. To: Incident Record -> Assigned to -> Email.

·Action: Send Email. To: Incident Record -> Assignment group -> Manager -> Email.

Fields used

·state

·assigned_to

·assignment_group

Test cases

·Create a P3 Incident and let the Resolution SLA pass 75%. Verify the assignee and group manager receive an email.

·Create a P3 Incident, resolve it before the SLA reaches 75%, and verify no email is sent.

Rollback notes

·Deactivate the Flow in Flow Designer to stop all future executions.

Requirements / prerequisites

·Flow Designer plugin (com.glideapp.flow_designer) must be active.

·Existing SLA Definitions on the Incident table.

sn-flow-002

Automated Follow-up and Closure for 'Awaiting User Info' Incidents

Flow Designer Priority: High Effort: Medium

To reduce incident lifecycle time by automatically chasing users for information and closing abandoned tickets. This addresses the significant volume of tickets entering 'Pending User' (43%) and 'Awaiting User Info' (21.1%) states, and the 6.6% of incidents closed due to 'No feedback from user'.

Why this pack: This automation requires timed waits and conditional logic (wait for 3 days, check status, notify, wait again), which is a primary use case for Flow Designer's ability to orchestrate processes over time.

Trigger

Incident 'State' changes to 'Awaiting User Info'

Conditions

·Incident 'State' is 'Awaiting User Info'

Actions

·Wait for 3 business days.

·Check if Incident State is still 'Awaiting User Info'.

·If yes, send a reminder email to the Caller.

·Wait for another 2 business days.

·Check if Incident State is still 'Awaiting User Info'.

·If yes, set Incident State to 'Resolved', add a work note, and set 'Close code' to 'Solved (No User Response)'.

Evidence used

·Transition: Work in Progress - Pending User (43.00%)

·Transition: Pending User - Awaiting User Info (21.10%)

·close_code: No feedback from user (6.6%)

ServiceNow implementation

Target table

·incident

Configuration area

·Flow Designer

Configuration trigger

·Updated: Record Updated. Table: Incident. Condition: State changes to Awaiting User Info.

Configuration conditions

Implementation steps

·Action: Wait for a duration of time. Duration: 3 Days. Use a schedule (e.g., 8-5 Weekdays).

·Flow Logic: If. Condition: Incident Record -> State IS Awaiting User Info.

· Action: Send Email. To: Incident Record -> Caller -> Email. Subject: Reminder: Information Required for INCXXXXX.

· Action: Wait for a duration of time. Duration: 2 Days. Use a schedule.

· Flow Logic: If. Condition: Incident Record -> State IS Awaiting User Info.

· Action: Update Record. Record: Trigger Record. Fields: State=Resolved, close_code='No feedback from user', close_notes='Incident auto-resolved after 5 business days with no response from caller.'

·End Ifs

Fields used

·state

·caller_id

·close_code

·close_notes

Test cases

·Set an Incident's state to 'Awaiting User Info'. Verify a reminder is sent after 3 days and it is auto-resolved after 5 total days.

·Set an Incident to 'Awaiting User Info' and then update it to 'Work in Progress' within 3 days. Verify the flow terminates and does not send a reminder or resolve the incident.

Rollback notes

·Deactivate the Flow in Flow Designer. Manually review and progress any incidents currently being processed by the flow.

Requirements / prerequisites

·Flow Designer plugin (com.glideapp.flow_designer) must be active.

sn-flow-003

Automated Incident Resolution Confirmation and Closure

Flow Designer Priority: Medium Effort: Medium

To standardize the closure process by notifying the user upon resolution and automatically closing the incident after a confirmation period. This addresses the 'Resolved -> Closed' transition (7.25% of tasks) and prevents incidents from staying in a 'Resolved' state indefinitely.

Why this pack: This rule orchestrates a multi-day process involving user notification, a waiting period, and a final record update. This orchestration over time is a key strength of Flow Designer.

Trigger

Incident 'State' changes to 'Resolved'

Conditions

·Incident 'State' is 'Resolved'

Actions

·Send an email to the caller confirming resolution and stating the ticket will auto-close in 3 business days.

·Wait for 3 business days.

·Check if the Incident State is still 'Resolved'.

·If yes, change the Incident State to 'Closed'.

Evidence used

·Transition: Awaiting User Info - Resolved (8.95%)

·Transition: Resolved - Closed (7.25%)

ServiceNow implementation

Target table

·incident

Configuration area

·Flow Designer

Configuration trigger

·Updated: Record Updated. Table: Incident. Condition: State changes to Resolved.

Configuration conditions

Implementation steps

·Action: Send Email to Caller. Body should include a message like: 'Your incident has been resolved. If you feel the issue is not resolved, please reply to this email to reopen it. Otherwise, it will automatically close in 3 business days.'

·Action: Wait for a duration of time. Duration: 3 Days. Use a business day schedule.

·Flow Logic: If. Condition: Incident Record -> State IS Resolved.

· Action: Update Record. Record: Trigger Record. Fields: State=Closed.

·End If

Fields used

·state

·caller_id

Test cases

·Set an Incident's state to 'Resolved'. Verify the user receives an email and the incident state changes to 'Closed' after 3 business days.

·Set an Incident's state to 'Resolved', then change it back to 'Work in Progress' within 3 days. Verify the incident is not auto-closed.

Rollback notes

·Deactivate the Flow in Flow Designer. This will stop incidents from being auto-closed.

Requirements / prerequisites

·An inbound email action should be configured to reopen resolved incidents if a user replies to the resolution email.

sn-flow-004

Rework Monitoring for 'Assigned -> Active' State Reversal

Flow Designer Priority: Medium Effort: Medium

To alert team managers about potential assignment issues by sending a notification when an incident is sent back from 'Assigned' to 'Active'. This rework happens in 35.6% of all incidents and is a major source of process inefficiency, as seen in variants like 'New -> Active -> Assigned -> Active -> ...'

Why this pack: Flow Designer can easily handle state-change triggers and access previous record values to detect this specific rework pattern, then use notifications to drive process awareness and improvement. This is a monitoring and alerting flow, not a routing rule.

Trigger

Incident 'State' changes from 'Assigned'

Conditions

·Incident 'State' is now 'Active'

·Incident 'State' was previously 'Assigned'

Actions

·Get the previous assignment group for the incident.

·Send an email notification to the manager of the previous assignment group, highlighting the incident that was 'bounced'.

Evidence used

·Transition: Assigned - Active (35.60%, Is rework?=true)

·Variant: New -> Active -> Assigned -> Active -> Assigned -> Closed (7.80% of tasks)

ServiceNow implementation

Target table

·incident

Configuration area

·Flow Designer

Configuration trigger

·Updated: Record Updated. Table: Incident. Condition: State changes to Active.

Configuration conditions

·Trigger Record -> State -> was -> Assigned

Implementation steps

·Action: Look Up Record. Table: Audit [sys_audit]. Conditions: Document key is Trigger Record -> Sys ID AND Field name is assignment_group. Sort by Created Descending.

·Action: Look Up User. Get the manager from the previous assignment_group found in the audit record.

·Action: Send Email. To: Manager's Email. Body: 'Incident [Number] was returned to the Active queue after being assigned to your group [Previous Group]. Please review for potential assignment process improvements.'

Fields used

·state

·assignment_group

Test cases

·Assign an Incident to a group, then change its state from 'Assigned' to 'Active'. Verify the manager of the original group receives a notification.

·Change an Incident's state from 'Work in Progress' to 'Active'. Verify no notification is sent.

Rollback notes

·Deactivate the Flow in Flow Designer to stop all notifications.

Requirements / prerequisites

·Flow Designer plugin (com.glideapp.flow_designer) must be active.

·Auditing must be enabled for the 'assignment_group' field on the Incident table.