Update set sys_id is different in every instance

[tushar_ghadage]

Hi All , 

I am facing some weird issue here  I have created the update set and captured platform analytics updates in it.

But when I try moving it to sanity test instance and then to test instance... 

they have different sys_id everywhere in dev , s-test and in test instance.

how come this is possible and when ?

anything would help 

thanks !!

[Vasantharajan N]

@tushar_ghadage - If you have the customer update sys_id is same then it will not create new sys_id in the target system for same file. 

Is it possible to provide screenshot from the different instance for the below given scenario?

1. Customer Update sys_id in the payload of dev

2. Retrieved update set - sys_id in the payload in the target system

3. Once after committed the sys_id in the payload from the local update set of the target system. 

4. Actual record created/updates sys_id in the target system (which you mentioned it's different from dev instance though it has same sys_id in the customer update)

[Ankur Bawiskar]

@tushar_ghadage 

sorry I got confused.

Update set sysId different is fine and it will be different. you need not worry on that.

The customers updates within those update set will have same sysId across DEV, TEST and PROD.

Example: if you capture client script then sysId of this will be same in TEST and PROD when update set is committed.

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

[Ankur Bawiskar]

@tushar_ghadage 

Thank you for marking my response as helpful.

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

[Ankur Bawiskar]

@tushar_ghadage 

Hope you are doing good.

Did my reply answer your question?

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

[Dr Atul G- LNG]

Technically, it should happen. Try to capture a HAR file, run cache.do, and check again.