Every install resets flows to draft/inactive + stale master snapshot throws "Plan does not exist" (breaks SP catalog item)

[IhorKochetkov]

Environment: @servicenow/sdk 4.7.2, Fluent-authored flow (Flow() with trigger.application.serviceCatalog, stages, tryCatch), deployed via now-sdk install from CI on every merge.

We hit a chain of flow-lifecycle problems that make source-managed flows operationally fragile. All verified on a Yokohama/Zurich-line instance.

1. Every install deactivates the flow

The generated sys_hub_flow payload hard-codes <status>draft</status> and <active>false</active>, and there is no Fluent property to ship a flow active/published. Consequence: every app deploy — including ones that don't touch the flow — resets a production flow to draft/inactive, and someone must reactivate it in Flow Designer afterwards. For a CI pipeline that installs on every merge, that means recurring outage windows for catalog fulfillment.

2. After an update install, the master snapshot is stale — and it crashes the Service Portal

When the install updates a previously-activated flow, the flow's existing master_snapshot still points at the old compiled plan, whose definition records the install just replaced. Anything that reads the master snapshot then throws:

com.snc.process_flow.exception.ProcessAutomationException: Plan does not exist with id of :
  com.glide.flow_trigger.engine.FlowPlanRetriever.getStagesForFlowFromMasterSnapshot
  com.glide.flow_trigger.engine.FlowPlanRetriever.getStagesForFlow
  com.glideapp.servicecatalog.CatalogItem.getDeliveryTime
  com.glide.service_portal.widget.SPScriptable.getCatalogItem

In our case the SC Catalog Item widget died on this ("Item not found" for the whole item) because it computes estimated delivery time from the flow's stages. We worked around the widget crash with hideDeliveryTime: true on the item, but the underlying stale plan still affects execution.

3. Recovery requires a manual Flow Designer edit — plain reactivation is not enough

After the install, FD's Deactivate → Activate reuses the stale snapshot (latest == master, so FD sees "nothing to publish" and only re-arms the trigger). The only way to get a fresh snapshot/plan is: Edit flow → make some change → Save → Activate. So the per-deploy ritual is a manual, undocumented, easy-to-forget sequence — per flow, per environment.

Asks

1. A way to ship flows active/published (Fluent property, install option, or now-sdk post-install step that performs the equivalent of FD's publish+activate — compiling a fresh snapshot/plan from the just-installed definition).
2. Failing that: have the install invalidate/clear the stale master snapshot so consumers degrade gracefully instead of throwing Plan does not exist.
3. Document the current behavior (install resets flows to draft; plain reactivate reuses the old snapshot) — it currently surprises in production-like flows.

Related reports from the same build: #79 (domain separation), #80 (catalog_variables silent drops).

[IhorKochetkov]

Related prior art: #65 — custom action types also deploy in Draft state, and per that thread this blocks the SDK installer from activating flows that reference them. Same lifecycle gap, two artifact types; probably best triaged together. (Both currently require the same manual Flow Designer publish/activate ritual after every install.)

[bryce-godfrey]

A solution for this is being worked on to publish flows and related entities through the SDK

[mobench]

A solution for this that i came up with and I use in my workflow is to have an update set (that i call "manual repairs") this update set captures the published state of my actions, subflows and flows. That way if i do a deploy my workflow automatically "re retrieves" the published update set and commits again in dev and promotes it to test and commits it there also.
(This is done via a custom mcp).
Only caveat is if you do some change to a flow or subflow then you need to recapture that new published version of the subflow in the update set)
Not ideal but It saves me a lot of time.