What is the difference between "sys_hub_action_instance" and "sys_hub_action_instance_v2"?

[bonsai]

After migrating flows using update sets, I visually check to make sure each flow action is updated correctly.

This is so inefficient that I'm looking into whether I can use table information instead.

Recently, I discovered that flow actions are stored in the "sys_hub_action_instance_v2" table.

It appears that flows migrated from the development instance using update sets are also recorded there.

In addition, the value field of the "sys_hub_action_instance_v2" record has a manipulated value set, so that the value between the development instance and the migration destination instance is the same.

However, the values ​​for some flows were not the same.

What's more, there were also flows that were not recorded in "sys_hub_action_instance_v2."

When I looked, I found that they were also recorded in "sys_hub_action_instance."

What is the difference between these tables?

I'm also curious about the instances where the values ​​are different.

I would like to share different values, but this is not possible because it is a corporate account.

[Ankur Bawiskar · Accepted solution]

@bonsai 

main difference between those tables is the version of the flow engine being used and the ServiceNow release.

sys_hub_action_instance: This table stores action instances for flows created using the original Flow Engine (prior to Washington DC release). It is used for flows and actions in older versions of ServiceNow and for flows that have not been migrated to the new engine

sys_hub_action_instance_v2: This table is introduced with the Flow Engine V2, starting from the Washington DC release. It stores action instances for flows created or migrated using the new engine. If you are on a newer release (Washington DC or later), flows and their actions will be stored here

Best practices

-> ensure source and target instance are on same release or target instance supports the flow engine used in source

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar · Accepted solution]

@bonsai 

main difference between those tables is the version of the flow engine being used and the ServiceNow release.

sys_hub_action_instance: This table stores action instances for flows created using the original Flow Engine (prior to Washington DC release). It is used for flows and actions in older versions of ServiceNow and for flows that have not been migrated to the new engine

sys_hub_action_instance_v2: This table is introduced with the Flow Engine V2, starting from the Washington DC release. It stores action instances for flows created or migrated using the new engine. If you are on a newer release (Washington DC or later), flows and their actions will be stored here

Best practices

-> ensure source and target instance are on same release or target instance supports the flow engine used in source

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Deepak Shaerma · Accepted solution]

Hi @bonsai 

sys_hub_action_instance: This is where Flow actions used to be stored in older versions of ServiceNow.
sys_hub_action_instance_v2: ServiceNow updated the underlying engine for Flow Designer (around the Rome/San Diego era) to make it faster and more stable. When they did that, they created this v2 table.

Why are your flows split between them?
It depends on when the Flow was created or last "touched." If you have a Flow that was built years ago and hasn't been significantly edited or republished since the engine upgrade, its actions might still be sitting in the old table. New flows, or old flows that triggered a backend migration when you edited them, will be in _v2

Please Mark this Helpful and Accepted Solution. If this Helps you to understand. This will help both the community and me..
- Keep Learning ‌‌
Thanks & Regards 
Deepak Sharma

[bonsai]

@Ankur Bawiskar 

@Deepak Shaerma 

Thank you.

The instance was newly created in YOKOHAMA.

Strangely, the number of newly created flows recorded in sys_hub_flow does not match the number of flows in sys_hub_action_instance_v2.

Is there a reason for this?

[Ankur Bawiskar]

@bonsai 

sys_hub_action_instance_v2 doesn't store actual Flow

It stores the steps associated to your flow.

The flow is stored in sys_hub_flow 

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏