Flow Designer Pack

sn-flow-001

Automated Bug Closure after Resolution

Flow Designer Priority: Critical Effort: Medium

To significantly reduce the cycle time by automating the closure of 'Resolved' bugs after a predefined waiting period. The evidence shows an average delay of 1,778 hours between the 'Resolved' and 'Closed' states, which is a major process bottleneck.

Why this pack: This automation uses a time-based trigger ('Wait for a duration of time') and state model management, which are core functionalities of Flow Designer. It orchestrates notifications and record updates over a period of time.

Trigger

Bug 'State' changes to 'Resolved'

Actions

·Send notification to the caller/reporter informing them the bug is resolved and will be auto-closed in 7 days.

·Wait for 7 business days.

·Check if the bug state is still 'Resolved'.

·If yes, change the state to 'Closed', add a work note 'Bug auto-closed after 7-day resolution period.'

Evidence used

·Transition: Resolved - Closed, Work items: 505, Avg deviation (hrs): 1778.32

·Variant: Open -> Pull Request Sent -> Resolved -> Closed, Avg Duration (hrs): 3869.24

ServiceNow implementation

Target table

·u_bug

Configuration area

·Flow Designer

Configuration trigger

·Record Updated: Trigger when a bug record is updated.

Configuration conditions

·State | changes to | Resolved

Implementation steps

·Action: Send Notification. Target: Caller. Content: 'Your Bug {trigger.record.number} has been resolved and will be automatically closed in 7 business days. If the issue persists, please reopen the bug.'

·Flow Logic: Wait for a duration of time. Duration: 7 Days (using a schedule to exclude weekends/holidays).

·Flow Logic: If. Condition: Get latest record and check if 'State' is still 'Resolved'.

·Action: Update Record. Set 'State' to 'Closed', 'close_notes' to 'Automatically closed after 7-day resolution confirmation window.'

·Action: Add Work Note. Note: 'Bug auto-closed by system after 7-day resolution period.'

Fields used

·state

·caller_id

·close_notes

·work_notes

Test cases

·Create a bug, move its state to 'Resolved'. Verify the notification is sent. Wait for the flow to complete and verify the bug is moved to 'Closed' with the correct work note.

·Create a bug, move its state to 'Resolved'. Before the timer expires, move the state to 'Reopened'. Verify the flow terminates and the bug is not closed.

Rollback notes

·Deactivate the Flow in Flow Designer to stop all new executions. In-flight executions will need to be manually cancelled.

Requirements / prerequisites

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

·A business calendar/schedule should be defined for calculating 'business days'.

sn-flow-002

QA Handoff Notification

Flow Designer Priority: High Effort: Low

To accelerate the handoff to the Quality Assurance team. Evidence shows significant delays between a bug being marked as resolved and QA beginning their work (avg 678 hours from Resolved to Ready for QA, and 366 hours from Ready for QA to QA In Progress). This flow provides immediate notification to the responsible team.

Why this pack: This is an event-driven automation that triggers a notification based on a field change, a primary use case for Flow Designer. It can be easily extended with IntegrationHub spokes (e.g., Slack, Teams) for richer notifications.

Trigger

Bug 'State' changes to 'Ready for QA'

Actions

·Identify the appropriate QA Assignment Group (e.g., based on the 'Project' field or a system property).

·Send an email notification to the QA Assignment Group.

·Post a message to a designated QA channel in Slack or MS Teams with bug details and a direct link.

Evidence used

·Transition: Resolved - Ready for QA, Avg deviation (hrs): 678.93

·Transition: Ready for QA - QA In Progress, Avg deviation (hrs): 366.98

ServiceNow implementation

Target table

·u_bug

Configuration area

·Flow Designer

Configuration trigger

·Record Updated: Trigger when a bug record is updated.

Configuration conditions

·State | changes to | Ready for QA

Implementation steps

·Flow Logic: Look Up Record. Find the 'Assignment Group' for QA based on the bug's 'Project' field from a custom lookup table or decision table.

·Action: Send Email. To: {Look Up Record.Assignment Group}. Subject: 'Bug {trigger.record.number} is Ready for QA'. Body: Include short description, priority, and a link to the record.

·Action (Optional - IntegrationHub): Post Message. Use the Slack or Teams spoke to post a message to a channel like '#qa-team'. Message: 'New Bug Ready for QA: {trigger.record.number} - {trigger.record.short_description}'.

·Action: Add Work Note. Note: 'QA team has been notified.'

Fields used

·state

·assignment_group

·project

·number

·short_description

Test cases

·Update a bug's state to 'Ready for QA'. Verify that the correct QA group receives an email and a message is posted in the correct channel (if configured).

Rollback notes

·Deactivate the Flow in Flow Designer.

Requirements / prerequisites

·A mechanism (e.g., Decision Table, custom table) to map Projects to QA Assignment Groups.

·IntegrationHub and relevant spokes (e.g., Slack, MS Teams) for advanced notifications.

sn-flow-003

Stale Bug in 'New' State Reminder

Flow Designer Priority: Medium Effort: Low

To prevent new bugs from being neglected. The evidence shows a common self-loop from 'New' to 'New' with a very long average duration of 527 hours, indicating that bugs are sitting in the initial queue state for extended periods without progressing.

Why this pack: This flow uses a duration-based wait ('Wait for a duration of time') after a record is created, which is a perfect use case for Flow Designer to manage task lifecycle and escalations over time.

Trigger

Bug 'State' is 'New' upon creation

Actions

·Wait for 3 business days.

·Check if the state is still 'New'.

·If yes, send a reminder notification to the 'Assignment group' manager.

·Add a work note indicating a reminder was sent.

Evidence used

·Transition: New - New, Work items: 131, Avg deviation (hrs): 527.34

·Variant: New -> New -> Open -> Pull Request Sent -> ..., Is Rework: true

ServiceNow implementation

Target table

·u_bug

Configuration area

·Flow Designer

Configuration trigger

·Record Created: Trigger when a bug record is created.

Configuration conditions

·State | is | New

Implementation steps

·Flow Logic: Wait for a duration of time. Duration: 3 Days (using a business schedule).

·Action: Look Up Record. Get the current version of the trigger record.

·Flow Logic: If. Condition: Check if the looked up record's 'State' is still 'New' and 'Assignment group' is not empty.

·Action: Send Notification. Target: {Look Up Record.Assignment group.Manager}. Content: 'Reminder: Bug {record.number} has been in the New state for over 3 days.'

·Action: Add Work Note. Note: 'Automated reminder sent to assignment group manager for stale bug.'

Fields used

·state

·assignment_group

·sys_created_on

Test cases

·Create a new bug with state 'New' and an assignment group. Verify that after 3 days, the group manager receives a notification and a work note is added.

·Create a new bug, but move it out of 'New' state within 3 days. Verify that no notification is sent.

Rollback notes

·Deactivate the Flow in Flow Designer.

Requirements / prerequisites

·Assignment groups must have the 'Manager' field populated.

·A business calendar/schedule should be defined for calculating 'business days'.

sn-flow-004

Standardized Bug Reopening Subflow

Flow Designer Priority: Medium Effort: Medium

To standardize the process of reopening a closed bug and ensure it is routed back to the correct team for re-evaluation. The 'Closed -> Reopened' transition indicates rework (3% of tasks), and a standard process can improve data quality and resolution time for these cases.

Why this pack: A reusable subflow is a key feature of Flow Designer. It encapsulates a business process that can be triggered from multiple sources (e.g., a UI Action, an inbound email action), ensuring consistency and maintainability.

Trigger

Subflow triggered by a UI Action named 'Reopen Bug'

Conditions

·Current state is 'Closed'

Actions

·Prompt the user for a reason for reopening.

·Clear resolution fields (e.g., resolved_by, resolved_at, close_code, close_notes).

·Set the state to 'Reopened'.

·Assign the bug back to the group that last resolved it.

·Add a work note with the reopening reason.

Evidence used

·Transition: Closed - Reopened, Work items: 65, Avg deviation (hrs): 404.30

ServiceNow implementation

Target table

·u_bug

Configuration area

·Flow Designer

Configuration trigger

·Subflow: This flow is designed as a subflow and does not have a record-based trigger.

Configuration conditions

Implementation steps

·Subflow Inputs: Bug Record (GlideRecord), Reopen Reason (String), Reopened By (User Reference).

·Action: Update Record. Target: {Input.Bug Record}. Fields: Set 'resolved_by' to empty, 'resolved_at' to empty, 'close_code' to empty, 'close_notes' to empty, 'State' to 'Reopened', 'Assigned to' to empty.

·Action: Add Work Note. Note: 'Bug reopened by {Input.Reopened By}. Reason: {Input.Reopen Reason}'.

·Action: Send Notification. To: {Input.Bug Record.resolved_by}. Content: 'Bug {Input.Bug Record.number} which you resolved has been reopened.'

·Subflow Outputs: None.

Fields used

·state

·resolved_by

·resolved_at

·close_code

·close_notes

·assignment_group

·work_notes

Test cases

·From a 'Closed' bug, use the 'Reopen Bug' UI Action. Provide a reason. Verify the state changes to 'Reopened', resolution fields are cleared, and a work note is added.

·Verify that the user who originally resolved the bug receives a notification.

Rollback notes

·Deactivate the Subflow in Flow Designer and disable the UI Action that calls it.

Requirements / prerequisites

·A server-side UI Action must be created on the bug table to call this subflow.

·The UI Action should be visible only when the bug state is 'Closed'.