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

bonsai
Mega Sage

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.

2 ACCEPTED SOLUTIONS

Ankur Bawiskar
Tera Patron
Tera Patron

@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! 🙏

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

View solution in original post

Deepak Shaerma
Mega Sage
Mega Sage

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

 

 

View solution in original post

8 REPLIES 8

@Ankur Bawiskar 

I want to check the implemented actions and flow logic settings, but sys_hub_flow only seems to have information such as the flow name.

@bonsai 

yes that's correct.

there are lot of inter linked flow tables and info is scattered in those.

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

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

Hi @bonsai 

Happy to help! If this resolved your issue, kindly mark it as the correct answer and close the thread 🔒 so others can benefit too.
Warm Regards,
Deepak Sharma
Community Rising Star 2025

VarunRajpoot
Giga Contributor

helpful