Troubleshooting the “Your flow cannot be found. Flow sys_id:An” Error in ServiceNow Flow Designer

Encountering the “Your flow cannot be found. Flow sys_id:An” error in ServiceNow Flow Designer can be perplexing and frustrating. This message indicates that the platform cannot locate the specified flow (or its content) by the given sys_id, effectively blocking you from opening, editing, or running that flow. Since ServiceNow Flow Designer is central to automating approvals, tasks, and data updates across the platform, resolving this error quickly is vital to prevent business process disruptions. In this ServiceNow Flow Designer troubleshooting guide, we’ll explain what this error means, why it occurs, and how to fix the “flow sys_id not found” error to restore a corrupted ServiceNow flow.

Why Does This Error Occur? (Common Causes)

Several scenarios can lead to the “Your flow cannot be found. Flow sys_id:An” error. Understanding these common causes will help pinpoint the root of the problem:

Missing or Corrupted Flow Snapshot Records: Each flow has one or more snapshot records (in the sys_hub_flow_snapshot table) that store the flow’s definition at publish time. If the snapshot referenced by the flow is missing, corrupted, or never properly created, the platform can’t retrieve the flow by its sys_id. For instance, if someone manually altered or deleted the flow’s Latest Snapshot or Main Snapshot reference on the flow record, it can break the link to the actual flow content. In such cases, opening the flow yields this error because the system literally cannot find the flow’s design data in the database.
Incomplete Migrations Between Instances: This error frequently appears after moving or promoting flows from one instance to another (e.g. from dev to prod) via update sets or the App Repository. A common mistake is not migrating subflows or related artifacts along with the main flow. If a flow references a subflow (or a custom action) that wasn’t moved to the target instance, the flow’s snapshot will contain a reference to a non-existent subflow, causing the “cannot be found” error. In fact, the sys_id mentioned in the error often corresponds to a missing sys_hub_flow_snapshot record – for example, a subflow’s snapshot that the main flow depends on. Similarly, if the flow uses custom actions or specific catalog items/variables that didn’t migrate, those broken references can trigger this issue.
Out-of-Sync “Main Snapshot” or “Latest Snapshot” Fields: Every flow record (in sys_hub_flow) has fields linking to its current design definition: Main Snapshot (the primary design) and Latest Snapshot (the most recently published version). If these pointers are tampered with or become out-of-sync, the Flow Designer may not find the right content. For example, a user reported this error after manually modifying the Latest Snapshot field of a flow record. A mismatched snapshot ID – say, if Main Snapshot points to a snapshot that no longer exists or isn’t actually the latest – can result in the flow not loading. In other words, the flow’s record is present, but its associated design data is lost or not referenced correctly.
Saving an Incomplete Flow Mid-Design: It’s important to save and publish flows in a proper sequence. Partially saving a flow while building it can sometimes corrupt the flow’s snapshot. A known quirk (or bug) in some ServiceNow versions is that saving a flow “as you go” – for example, saving after adding some inputs or steps but before configuring the trigger or outputs – can produce an incomplete snapshot. This inconsistent snapshot can’t be loaded later, leading to the error. Essentially, if you save a partially built flow or modify critical attributes in between saves, you might create a snapshot record that doesn’t fully represent a valid flow, causing the platform to throw the sys_id not found error when reopening it.
Known Flow Designer Bugs: ServiceNow has identified specific bugs in the Flow Designer that can cause this error. One particularly tricky scenario involves using the “Get Catalog Variables” action followed by an “Assign Output” action in a subflow. In certain versions, if you add a Get Catalog Variables step and save the subflow, then later add an Assign Output step and save again, it can corrupt the subflow’s snapshot. The next time you try to open that subflow (or any flow that calls it), you’ll see the “flow cannot be found” message. ServiceNow has acknowledged this issue (e.g. known problem PRB1689243) where Flow Designer fails to capture complex objects in the snapshot under specific conditions, resulting in this error. Always check ServiceNow’s release notes for your version; a fix might already exist in a patch if this is due to a platform bug.

Step-by-Step Troubleshooting Guide

Now that we know why the error can occur, let’s walk through how to fix the “Your flow cannot be found” error. Use the following steps to diagnose and resolve the issue:

Step 1: Inspect the Flow Record and Snapshots

The first step is to verify that the flow’s record and its snapshot references are intact. This can reveal if something is missing or misconfigured.

Open the Flow table: In your ServiceNow instance, navigate to Flow [sys_hub_flow] list. (You can do this quickly by typing sys_hub_flow.list in the Application Navigator and hitting Enter.) This table lists all flows and subflows on the instance.
Locate your flow: Find the flow in question, either by searching for its name or by filtering by the sys_id (the portion after “Flow sys_id:” in the error message). Open the flow’s record or at least identify it in the list.
Check snapshot fields: Look at the flow record’s fields, especially Main Snapshot and Latest Snapshot. These should contain references (sys_ids) pointing to records in the Flow Snapshot [sys_hub_flow_snapshot] table. If, for example, the Main Snapshot field is blank, or points to a sys_id that doesn’t exist in the snapshot table, that’s a red flag explaining why the flow cannot be found.
Verify the error’s sys_id: Confirm if the sys_id mentioned in the error message matches either the flow’s own sys_id or one of its snapshot record sys_ids. Often, it’s the snapshot sys_id. This tells you which record the platform failed to find. For instance, if the error shows Flow sys_id: abcd1234, and you see that Latest Snapshot on the flow record is abcd1234 (which perhaps no longer exists in the snapshot table), you’ve identified the cause: the flow’s snapshot is missing or broken.

Tip: You can personalize the list layout to assist in troubleshooting. Add the Main Snapshot column to the Flow [sys_hub_flow] list view. Once visible, copy the sys_id from the Main Snapshot field for your flow and try to load it directly in Flow Designer by using a URL hack: https://<your_instance>.service-now.com/flow_designer.do?sysparm_flow_sys_id=<Main_Snapshot_sys_id> This forces Flow Designer to open the specific snapshot. If the snapshot loads (even if the flow record wouldn’t), it means the snapshot itself exists and might be okay. If it doesn’t load or shows an error, the snapshot record is likely gone or corrupted. (This trick sometimes allows you to view the flow canvas behind the error, but note that you may still need to repair the snapshot to fully fix the issue.)

Step 2: Revert to a Previous Version

ServiceNow maintains a version history for flows, which you can leverage to restore the flow to a last known good state. If the current snapshot is corrupted, reverting to a prior version often fixes the issue quickly.

Open Update Versions: Navigate to sys_update_version.list (the “Update Versions” table, which stores update set records for changes). This will list all updates on the instance.
Find flow versions: In the Update Versions list, search for records where the Name or Payload contains your flow’s name or sys_id. An easy way is to paste the flow’s sys_id into the global search or filter on the Name field. You should see a list of version entries corresponding to each time the flow was modified and saved.
Identify a working version: Review the version records’ timestamps or descriptions to find one from before the error started occurring (for example, the version before your last changes, or a version that you know was working). Open that version record to view details.
Revert the flow: Using the form context menu (the Additional Actions menu, usually a … or menu icon on the record), choose “Revert to this version”. Confirm the revert action when prompted. This will restore the flow’s snapshot/design to the state captured in that version record. Essentially, you are rolling back the flow to a point in time before the corruption happened.
Test the flow: After reverting, go back to Flow Designer and try opening the flow again. In many cases, the flow will now load properly, because you’ve replaced the bad snapshot with a valid older snapshot. Verify that the flow opens without the error and that the logic appears as expected for that version. You can then re-publish or adjust as needed.

Note: If you don’t see a “Revert to this version” option, ensure that you have the proper roles (you might need admin or flow_admin roles). Also, check if the flow is currently checked out or locked by another user; if so, have them publish or discard changes, or impersonate them to revert. In some instances you might need to Deactivate the flow first before reverting (especially if it’s active in the runtime). Reverting via update versions is generally safe and it uses the platform’s built-in version control, so it’s a preferred first approach before attempting riskier manual fixes.

Step 3: Verify and Restore Missing Dependencies

If reverting didn’t resolve the problem (or if it wasn’t possible due to no good prior version), the next likely cause is a missing dependency. You should ensure that all pieces the flow relies on are present in the instance.

List the flow’s components: Think about what your flow includes. Does it call any Subflows? Does it use any Scoped Actions (from an Integration Hub or custom spokes)? Does it reference specific Catalog Items or Variables? Make a list of subflows and reusable actions that the flow might be dependent on, as well as any important variables passed into it.
Check subflows and actions: For each subflow or action the flow calls, verify it exists on this instance. You can search the Flow table (sys_hub_flow) for the subflow name, or try to open that subflow in Flow Designer. If any referenced subflow is missing (for example, it wasn’t migrated from another environment), that is likely the culprit. The error message’s sys_id could belong to the missing subflow’s snapshot. Similarly, ensure any custom action definitions used by the flow are present and installed.
Inspect catalog items or variables: If your flow is triggered by a Catalog Item or expects certain variables (like from a Record Producer or Catalog Item), make sure those exist and are published in this instance. Sometimes the flow might be looking for a variable or field that was removed or renamed, causing part of the flow to break. For example, if an earlier version of the flow had an input variable that got deleted or a data pill that no longer resolves, the snapshot might be referencing something that’s not there.
Restore missing pieces: For any dependency that is missing, take steps to bring it in. This could mean committing an update set that contains the missing subflow or action, retrieving the item from your source control/app repository, or re-creating the subflow/action manually in this instance. If a variable was missing, re-add a placeholder for it or adjust the flow to remove that reference.
Publish or update dependencies: If you had to import a subflow or action, publish it so it’s active. Ensure the sys_ids match what the main flow expects (if you imported via update set, they should).
Retry the main flow: Once all referenced components are in place, try opening the main flow in Flow Designer again. If the error was due to a missing sub-component, the flow should now load successfully since the broken reference is repaired. You may need to publish the main flow again to capture the now-resolved references.

Tip: A quick way to determine if a subflow is missing is to look at the error’s sys_id and search for it in the Flow Snapshot [sys_hub_flow_snapshot] table. If you find a snapshot record with that sys_id, check its Parent Flow or Flow reference – it could be pointing to the subflow or action that’s not on the instance. This can clue you in on what needs to be brought over.

Step 4: Update Your Platform (Patches and Versions)

If the flow and its pieces all seem to be in place, consider that you might be hitting a platform bug. ServiceNow periodically releases patches that fix known issues in Flow Designer. It’s important to ensure your instance is up-to-date, especially if you suspect a bug is at play.

Check your ServiceNow release: Determine what Release and Patch level your instance is on (for example, “Quebec Patch 10” or “San Diego”, “Utah”, “Vancouver”, etc.). You can find this in the System Diagnostics or by searching for “System Properties -> System” where the version is listed.
Review known issues: Look at the Release Notes or Known Error documentation for your version regarding Flow Designer. In particular, search for keywords like “flow cannot be found” or known problem IDs like the aforementioned PRB1689243. ServiceNow’s PRB (Problem) records in release notes will indicate if a patch has resolved a specific bug. For example, the Washington DC release notes (hypothetically) mention a fix for flows throwing this error due to update-set migration issues with complex objects.
Apply patches or upgrade: If your instance is on a version where this bug is present, the simplest fix might be to upgrade to a patch where it’s resolved. For instance, if you’re on an early Utah patch that has the Flow Designer bug, upgrading to the latest Utah patch or to Vancouver might eliminate the issue automatically. Likewise, ensure the Flow Designer plugin (if you’re on an older release where Flow Designer was a separate plugin) is updated to the latest version available for your build.
Test after updates: After applying a patch or upgrade, test opening the flow again. If a platform fix was applied, the flow should ideally open without error (assuming the bug was the root cause). Even if you applied other fixes in steps 1-3, staying up-to-date will prevent encountering a known bug again.
Monitor ServiceNow communications: Keep an eye on the ServiceNow Community and Product documentation for any announcements about Flow Designer issues. As of late 2024, for example, ServiceNow acknowledged the “save as you go” issue and indicated plans to introduce a safer incremental save feature by early 2025. By staying current with updates, you’ll benefit from these improvements in flow stability.

Note: Always test patches in a sub-production environment first. While rare, it’s possible that changes in Flow Designer behavior in new releases could affect your flows. Also, if your organization has strict change control, document that a platform issue was identified and a patch is needed to fix the “flow cannot be found” error.

Step 5: Manually Repair the Flow (Last Resort – Advanced)

If all else fails and you still can’t open the flow, you may need to perform a manual repair on the flow’s records. These steps are advanced and should be done with caution, ideally on a sub-prod instance or with a backup of the flow, since direct record manipulation can be risky.

⚠️ Warning: Proceed with manual fixes only if you’re comfortable with ServiceNow’s data structure and have exhausted safer options. Always back up the flow (e.g., XML export) before making direct changes. It’s wise to test these steps on a development instance first, as improper changes could further corrupt the flow.

Here are a few approaches to manually troubleshoot and fix the flow:

Inspect snapshot records via scripts: Use a background script or the Script Console to query the sys_hub_flow_snapshot table for records related to your flow. For example, you can run a GlideRecord query filtering flow = <your_flow_sys_id> to list all snapshot entries for that flow. This might show you multiple snapshots (versions). Look for any anomalies – e.g., a snapshot record that should be the “latest” but is incomplete or has missing data. If you identify a clearly corrupted snapshot (perhaps one with a certain name or lacking expected content), you can consider deleting that snapshot record. Deleting a bad snapshot may force the platform to fall back to another snapshot or at least remove the broken reference. Note: Only delete a snapshot if you’re sure it’s broken, and always have a backup. Deleting the current snapshot will make the flow appear as if it has no design (which in this case it effectively doesn’t).
Bypass the error UI to debug: One trick to see what’s going on is to bypass the Flow Designer error modal that blocks the screen. When the error popup appears saying “Content cannot be found” (the UI message accompanying the sys_id error), it often prevents you from seeing anything on the canvas. However, some or all of the flow’s components might have actually loaded behind the modal. Using your web browser’s developer tools, you can remove that blocking overlay:
1. In your browser, right-click the page and choose “Inspect” or open the Developer Console.
2. In the Elements/DOM explorer, find the <div> element with a class name like ReactModalPortal (this is the overlay for the error dialog).
3. Delete that element from the DOM. The error message box should disappear.
4. Now you can interact with whatever loaded on the flow canvas. You might see partial flow steps or some structure of the flow.
5. Examine the flow contents for anything suspicious: for example, an empty or broken action step, or a step that says “Get Catalog Variables” without a corresponding output, etc.
This hack doesn’t fix the issue by itself, but it allows you to inspect the flow’s state. If you can identify a problematic step (perhaps the flow was halfway through adding an action when it got corrupted), you can try to remove that step.
Remove and re-add problematic steps: If the issue was caused by a known bug scenario (like the Get Catalog Variables + Assign Output bug), you should remove those steps entirely. Delete any “Get Catalog Variables” step and any “Assign Output” step from the flow (using the Flow Designer UI after removing the error overlay). Don’t save in between; just remove them. Once removed, add the steps back cleanly: for instance, first add a new Assign Output (if needed) and configure it, then add the Get Catalog Variables step again. After re-adding the steps properly, click Save (or Publish) once to save the flow in its now hopefully fixed state. This one-go save will create a new snapshot. If the operation is successful, you should no longer get the error upon re-opening the flow. Essentially, you’ve rebuilt the broken part of the flow to remove the corruption.
Do NOT manually edit snapshot fields on the flow record: It might be tempting to quickly set the Main Snapshot field on the flow record to a different value (or blank it out) to see if that helps. Avoid doing this via direct record edits in the UI or scripts. The relationship between flows and snapshots can be delicate, and manually tinkering with those fields could make matters worse. It’s better to let the system update those when you publish a flow. Focus instead on removing bad data (like a corrupted snapshot or step) and then let the act of saving/publishing set the correct snapshot references.
Export and re-import as XML (ultimate fallback): If despite all efforts the flow is still not opening, you can opt to retrieve the flow’s definition via an XML export and then re-import it as a new flow. To do this, right-click the flow record in the sys_hub_flow list and choose Export > XML. Save the XML file. Open the XML in a text editor and inspect it — you may notice references to sys_ids that don’t exist on your instance (e.g., a subflow’s sys_id that is missing). You can try cleaning the XML by removing or fixing those references. For example, if there’s an obvious section for a step that calls a missing subflow, you might remove that entire <subflow> node or replace the sys_id with the correct one from the subflow now present. Once edited, save the XML and then import it back into ServiceNow (you can do Import XML in an admin context). The flow will import as a new record (with a new sys_id). Open this new flow in Flow Designer – with any luck, it will open without errors (since you removed the broken pieces). You’ll then need to re-publish this flow and perhaps redirect any references (like wherever the old flow was used, point to the new one). This approach essentially recreates the flow from scratch using the definition you salvaged, minus the corrupted parts.

After performing a manual repair, test the flow thoroughly. Open it in Flow Designer, ensure it loads, then examine each step to confirm it’s configured correctly. If you deleted or changed anything, you may need to adjust logic or reconfigure some steps. Once it looks good, publish the flow so that a fresh snapshot is stored. This should update the flow’s Main Snapshot and Latest Snapshot to point to a valid, working snapshot record.

Summary & Best Practices

The “Your flow cannot be found. Flow sys_id:An” error is certainly troublesome, but as we’ve shown, it is resolvable with careful troubleshooting. Here’s a quick checklist and some best practices to keep in mind:

Troubleshooting Checklist:
1. Verify the Flow Record: Check the Flow (sys_hub_flow) record exists. Inspect its Main Snapshot and Latest Snapshot fields for missing or incorrect references. (Use sys_hub_flow.list and look for the flow by name/sys_id.)
2. Revert if Possible: If a recent change broke the flow, go to sys_update_version.list and revert the flow to a prior working version. This often restores a valid snapshot and resolves the error.
3. Check Dependencies: Ensure all subflows, actions, and other dependencies the flow needs are present on the instance. Import or recreate any missing subflow or object so the flow’s references are intact.
4. Apply Updates/Patches: Determine if you’re encountering a known ServiceNow bug. If so, update the Flow Designer plugin or upgrade your instance to a version with the fix. This can save you from manual fixes and prevent recurrence.
5. Manual Fix (Last Resort): If none of the above works, consider advanced repairs: deleting a corrupted snapshot record, using a browser console hack to remove the error modal and fix broken steps, or exporting the flow to XML and re-importing it as a clean copy.
Best Practices to Prevent Future Issues:
- Always migrate dependent objects: When moving flows between instances, include all subflows and related artifacts in your update sets or application. A flow and its subflows should be moved together to avoid broken references.
- Avoid mid-design saves: Try not to hit “Save” in Flow Designer until you have added and configured a logical chunk of the flow (especially when dealing with complex steps like script actions, catalog variable mappings, etc.). Saving only once the flow logic is complete will reduce the chance of getting an incomplete snapshot.
- Don’t manually edit snapshot fields: Let ServiceNow manage the Main Snapshot and Latest Snapshot relationships. Manually editing these via the dictionary or script is not recommended, as it can easily cause mismatches.
- Maintain backups of critical flows: For important business-critical flows, consider regular exports or use Source Control (if developing in a scoped app) so you have a backup. This can be a lifesaver if a flow becomes corrupted — you can quickly re-import the last good version.
- Stay up-to-date: Keep your instance on a supported release and apply patches. Many Flow Designer issues (like the one discussed) have been fixed in later patches of Rome, San Diego, Tokyo, Utah, etc. Upgrading ensures you get those fixes and improvements (for example, the upcoming improved “save as you go” feature in 2025 releases).

By following the above steps, you should be able to fix the “Your flow cannot be found” error and get your Flow Designer content back on track. The key is to methodically identify whether the issue is missing data, a process mistake, or a platform bug. In any case, with some patience and the techniques outlined, you can restore your flow and resume automating processes in ServiceNow without losing progress. Remember to implement the best practices to minimize the chance of encountering this error again, and you’ll leverage Flow Designer to its fullest potential without the headache of flows suddenly disappearing or becoming uneditable.

Experiencing challenges with ServiceNow support?