Difference between non-floated flows recorded in "sys_hub_action_instance_v2"

[bonsai]

Some flows are not being recorded in "sys_hub_action_instance_v2".
All flows contain actions and flow logic, and the instance version was YOKOHAMA from the beginning.

Additionally, flows that should have existed in "sys_hub_action_instance_v2" on the test and development instances did not exist on the production instance.

The flows were migrated from the development instance to the test instance using an update set, and then migrated to the production environment using the same update set.

Are there any conditions that need to be met for these flows to be recorded in "sys_hub_action_instance_v2"?

[Sreeram Nair]

If records are missing from sys_hub_action_instance_v2 In production after a migration, I think its a breakdown in the Update Set capture of the Flow's Snapshot (metadata), rather than a version defect in Yokohama.

Here are the conditions and checks required for these records to appear:

1. Verify Component Type (Action vs. Logic). Ensure you aren't looking for Flow Logic records in this table.

• sys_hub_action_instance_v2 stores specific Actions (e.g., Create Task, Look up Record).

• sys_hub_flow_logic stores logic elements (e.g., If, For Each, Do Until). If the missing steps are "If" statements, they simply won't exist in the action instance table.

2. Dependency Integrity (Missing Action Definitions): This table links a Flow to an Action Type Definition (sys_hub_action_type_definition). If the flow uses a Custom Action, and that Custom Action definition was not present in Production (or was in a different, uncommitted Update Set) when the Flow was committed, the system will skip creating the instance record to avoid a broken reference. Check your Update Set Preview logs for "Missing Reference" errors.

3. Snapshotting (Draft vs. Published) Flow Designer separates "Draft" XML from "Published" (Snapshot) XML.

• sys_hub_action_instance_v2 records are tightly coupled to the Published Snapshot.

• If the flow was modified in Dev but not fully Activated/Published before the Update Set was completed, you may have migrated a wrapper with incomplete child metadata.

Try to force a metadata refresh from your source environment. In your Development instance, create a new Update Set, open the problematic Flow, and make a trivial update (such as modifying the description). Crucially, you must Save and Publish (Activate) the flow; clicking Publish forces the system to regenerate the internal Snapshot records, which explicitly writes the sys_hub_action_instance_v2 entries.

Then, migrate this new Update Set to your Test and Production environments, which will overwrite the incomplete definition and populate the missing action instances.

[bonsai]

@Sreeram Nair 

I'm not looking for flow logic in this table.
Also, I'm recording them in the update set as active.
There have been no reports of abnormalities in the flows running in the production instance, and they are working normally.

I also found that the active custom flows I created in the development environment are not recorded in "sys_hub_action_instance_v2".
There's no relationship between the actions recorded in the update set and being recorded in "sys_hub_action_instance_v2", right?