Hi Tianying,

It looks like the customized record already exists but was maybe altered in the destination tenant in the past so no longer syncs with the package.

In some cases it helps to create the extra ExternalToken_c field by hand. But I suggest you look for the two Customization0 metadata files in the package (i.e. the ZIP) and see if it highlights exactly which conflict it could be?

Regards, 

Ben

Hi Ben,

thanks, that's exact the case. The destination system already has a record with the same name, and the unique key is ExternalToken_c. However the record in the package has a different unique key ExternalId_c, I opened the package and found it in the metadata folder, Customization0.data file. I tried to change it to ExternalToken_c like in the destination system, and zip the whole folder, but this must be not allowed so I got error when simulating it . 

In the past neither the record in studio, nor the unique key of this record can be deleted. So is there any chance to get the record on the destination system? I think even manual creation will not work, because the name of the unique key is different. 

Thanks,

Tianying 

Hi Tianying,

I'm sure that editing the PKB isn't really supported, but in any case you will find that there are more places that have that other name, including some file-names (resourceBundles etc.).

So you would have to unzip everything, alter everything consistently (content & file-names), rezip, and try.

Not sure if it wouldn't be better to restart with a clean tenant copy and apply the required changes.

Regards,

Ben

Editing the package is not a sustainable solution. Even if you think you found the relevant field and you flagged the differences, you will have to repeat this task every time you perform a Dev2Prod operation. Additionally, it is a very risky one, if you don't quite get the change right, you can compromise your entire production tenant.

This is a topic discussed on other threads, it is critical to follow the best practices and do not perform configuration changes in production. Always implement then in the Dev tenant and use a dedicated Dev tenant as your primary source for promoting the changes, even if you test a subset of changes on other tenants.

There could be rare situations where a configuration needs to be tweaked in the Production tenant, but this should only take place in very low-risk areas, never when adding items to a List or when creating fields

Best regards,

Brindusa

Hi Ben,

yes I saw this kind of files, just haven't found the ExternalToken/ID_c one, maybe because it's defined as unique key during the app creation, so it's not displayed as a custom field in studio.

The destination tenant is a sandbox for many people to play around. I use it to test the import of my studio app from dev, as preparation for production. According to our document:

https://docs.microfocus.com/itom/SMAX:2021.05/dev2Prod#Inconsistency_handling

A lot of factors, such as enforce uniqueness, reference etc. will cause import process to fail, and my app does contain this kind of user-defined fields, I only want to verify the import, and don't need the app there. The sandbox has experimental developments of other people, so I can't ask the customer to overwrite it, unfortunately. Not sure if it's oversized to request a blueshift only for this small test. 

But you clarified my questions and help me found the reason for import failure, I'm happy to know it, many thanks!

Regards,

Tianying