Saved Triggers

Customer problem

Every flow in Flow Designer begins with a trigger: the condition that decides when it runs. Triggers were tightly coupled to their flow. If five flows needed to fire on “Incident created, priority = high”, that logic had to be typed out five separate times. There was no link between the copies, so a mistake could only ever be fixed in one place at a time.

Triggers are tightly coupled with a flow. Users have to duplicate the trigger logic across flows that have the same trigger logic. This is time consuming, repetitive… may cause inconsistencies and errors.

Original problem brief

Research across seven internal business units and five enterprise customers split that into two costs. One is the time spent re-authoring. The other is the inconsistency risk of copies that drift apart silently. State of Colorado put it most sharply: they needed a single place to fix “outdated logic that applies in multiple places.”

The brief

Personas

One quote from research did more design work than anything else. Eric Riemer described the feature before it existed:

As an admin, I see this feature as a quick way to create triggers… If I have citizen devs, I want them to use the trigger as is. Without changing trigger definition.

Eric Riemer, research interview

That is not a feature request. It is a permission model, handed over by a user. It says the trigger owner and the trigger consumer are different people with different needs.

Solution

1. Triggers become a first-class asset. They sit alongside Playbook, Flow, Subflow, Action and Decision Table, with their own nav module and their own “New” entry. Creation reuses the condition builder authors already know, so a new asset type does not also mean a new paradigm.
2. Three graduated permissions instead of one lock. View conditions, add additional conditions, view and modify advanced options. The same mechanism produces a fully locked black box for a citizen developer and an extensible template for a power user. Neither research population has to lose.
3. Publishing as a commitment gate, with friction scaled to blast radius. The first publish is light. Publishing once consumers exist shows exactly what is affected: a paginated list of every dependent flow. It footnotes how many rows the viewer’s record-level security hid, rather than faking full transparency. A capture from usability testing shows the pattern at production scale, reading This trigger is used by 80 objects… and Number of rows hidden by security constraints: 5. The prototype below runs on a smaller instance, where the same dialog reads 50 and 0.
4. Consumption that stays traceable. A saved trigger is visually tagged as such, distinct from an inline one. Any conditions the flow author adds stack visibly under the inherited base instead of merging invisibly into it. Provenance never gets lost.
5. Detach as an honest escape hatch. A named, confirmed action rather than silent drift. Its structural seam is documented instead of hidden: detaching a flow that already has local conditions produces an M×N cross product, because two independent condition builders are being reconciled into one. Resolving that quietly would have lost logic the user could not audit.
6. Guarded deletion and always-on governance. With no consumers, delete takes a plain confirmation. With dependents present, it is blocked outright until they are detached. “Associated Objects” sits in the 3-dot menu, so anyone can see what is consuming a trigger without hunting through flows.

The official feature overview

ServiceNow's own walkthrough of the shipped feature. Its chapters follow the same arc as the case study above — create a trigger, use it in a flow, edit it, detach it — which is a reasonable sign the interaction model held together end to end.

This is evidence the feature shipped, not evidence of adoption. The targets in the KPI section below are still unconfirmed.

3:51

0:00 Intro 0:30 Create trigger 1:44 Use trigger in a flow 2:21 Edit a saved trigger 3:02 Detach a trigger

Prototype walkthrough

The clickable prototype end to end — authoring a trigger as a standalone asset, the governance wrapped around publishing and deleting it, and a flow author consuming it downstream. Step through it, or let it play.

One gap worth naming: this prototype deck never expands “Show additional properties”, so the three graduated permissions aren’t visible in any frame here. They are visible in the official video above — its own thumbnail shows “Allow user to view conditions” and “Allow user to add additional conditions” as toggles on the trigger definition.

01/26

User flows

KPIs

Stated precisely: the three targets come from the PM roadmap deck. They are goals, not confirmed post-launch results. I do not have adoption data proving they were hit.

What it enabled downstream

Making a trigger a standalone asset turned out to be a platform move rather than a single feature. Once triggers existed independently of flows, other teams could build on them. The AI Agent Studio case in the personas above is one. A second, closer to home, is business calendars on schedule triggers.

Business Calendar × Schedule Triggers

A schedule trigger can repeat on a business calendar, say “US Federal Holidays,” instead of on a fixed interval. Reuse is what made that worth building. The calendar is configured once, elsewhere in the platform, then selected wherever a schedule trigger needs it.

It also inherits this project’s structural problem, one layer up. The person who selects a calendar is not the person who built it:

The trigger author who selects a business calendar is likely not the same person who initially configured these calendars in the platform.

Discovery document

So an author can pick a calendar with no visibility into what it excludes. They discover the consequence only when a trigger fires on a date they did not expect, or fails to fire on one they did. That is the same shape as a citizen developer handed a locked trigger, which is why it sits at discovery rather than in design. Three questions are open:

• What does an author need to see at selection time? A holiday count, or the dates themselves?
• Should Publish block on an empty calendar field, or fail at run time?
• Who holds authority when an author disagrees with a calendar’s holiday list?

Folded in here rather than kept as its own case study. It is a short set of open questions layered on this framework, not a separate body of work. The honest state is “framed, not yet designed.”

Still open

• Scale. Sec Ops raised tables with millions of records generating a matching volume of trigger fan-outs. Reuse solves the authoring duplication problem, not the runtime volume problem. Clearest candidate for the next iteration.
• Stale tabs. A flow tab already open when an auto-update lands needs a manual refresh. Accepted as a v1 gap rather than solved with live sync. A “trigger updated, refresh?” banner is the obvious follow-up.
• AI assistance. Usability testing asked directly (“How might AI help you in creating triggers?”) but nothing reached the shipped interaction spec. It is the same AI-versus-reliable-fallback tension that shows up independently in Unified Picker.