Update set movement

[AyushKumarM]

I am moving my update set from Xanadu to Yokohama. I am getting multiple errors of the same type. The description is - Could not find a record in sys_security_attribute for column security_attribute referenced in this update

[Dr Atul G- LNG]

Hi @AyushKumarM 

Did you make any changes to the ACLs?
It’s possible that those changes weren’t captured or migrated properly.

[AndersBGS]

Hi @AyushKumarM ,

moving from Xanadu to Yokohama? This doesn’t make sense as it is not best practice.

[Bert_c1]

I ignore those, I have no idea why those records are captured in my update sets. I delete those before promoting. I see no negative effect in the target instance when I preview and commit. My feature changes work the same as in the instance I developed them in.  Also, I have at least one update set developed in Fuji, and still works as designed in Yokohama.

[tiagomacul]

That error usually means the update set you're moving references a security attribute record that doesn't exist in the target instance (Yokohama).

Sample: UserIsAuthenticated

ServiceNow, the sys_security_attribute table holds custom security attributes used in Access Control rules or other security configurations.

sys_security_attribute .list

https://<Your instance>.service-now.com/now/nav/ui/classic/params/target/sys_security_attribute_list.do%3Fsysparm_nostack%3Dtrue

1.Check the Source Instance (Xanadu): Identify the specific sys_security_attribute records referenced in your update set. You can do this by opening the update set and reviewing the individual updates or using the XML export.

2. try to build a new update set OR...

2. (Yes, Another two, alternativally)

Manually Export the Missing Records: If those records weren’t included in the update set, you’ll need to manually export them—either by adding them to a new update set or using an XML export/import.

3. Import to Target Instance (Yokohama): Bring those missing records into Yokohama before previewing or committing the original update set again.

4. Preview Again: Once the dependencies are in place, re-preview the update set. The errors should clear up.

var updateSetId = 'PUT_YOUR_UPDATE_SET_SYS_ID_HERE';
var missingAttrs = [];

var gr = new GlideRecord('sys_update_xml');
gr.addQuery('update_set', updateSetId);
gr.addQuery('name', 'CONTAINS', 'sys_security_attribute');
gr.query();

while (gr.next()) {
    var payload = gr.payload.toString();
    var match = payload.match(/<security_attribute>([a-f0-9]{32})<\/security_attribute>/);
    if (match && match[1]) {
        var attrId = match[1];
        var attrGR = new GlideRecord('sys_security_attribute');
        if (!attrGR.get(attrId)) {
            missingAttrs.push(attrId);
        }
    }
}

if (missingAttrs.length > 0) {
    gs.print('Missing sys_security_attribute records:');
    for (var i = 0; i < missingAttrs.length; i++) {
        gs.print(missingAttrs[i]);
    }
} else {
    gs.print('No missing sys_security_attribute records found.');
}

https://www.servicenow.com/docs/bundle/washingtondc-application-development/page/build/system-update...
Retrieving and committing update sets between different versions or patch levels
"You can always load an update set created on an older family version into an instance running a newer family version. Loading an update set created on a newer family version into an instance running an older family version requires additional testing to determine compatibility. Updates from newer family versions may not produce the same functionality when moved to older family versions. In extreme cases, updates from newer family versions may cause outages or data loss in an instance on an older family version. Whenever possible, avoid moving updates from newer family versions to older family versions."