Legal hold Solution

[Alekhya Azmeera]

The HR agents who have the 'sn_hr_ef.legal_hold_writer' role the ability to apply a legal hold to a employee without giving them a the sn_hr_core.profile_writer role. if it is possible to provide users who have the 'sn_hr_ef.legal_hold_writer' role the ability to add or remove a legal hold to a HR Profile without allowing them to edit HR Profile Data e.g. DOB, Salary or create new HR Profiles.
for the above solution i implemented ACLs since oob script include is validating the create and write access on the hr profile, by adding sn_hr_ef.legal_hold_writer role.
I want to confirm there will be any impact of creating ACLS to solve the issue

[KPNow · Accepted solution]

Hi @Alekhya Azmeera :

Customizing or adding ACLs to grant the sn_hr_ef.legal_hold_writer role access to sn_hr_core_profile will carry a few specific operational and platform impacts. While using table-level write ACLs paired with field-level security effectively isolates access to sensitive PII like DOB or salary, custom ACLs cause ServiceNow family upgrades to mark those modified Security Attribute/ACL records as "Skipped." You will need to manually review and reconcile these records in the Upgrade Center during future family releases to prevent security drifts or conflicts with new (OOB) features.

From a ServiceNow best practices perspective, bypassing OOB Script Include validations through custom record-level write ACLs can also introduce maintenance overhead and unexpected behavioral edge cases. If standard Script Includes explicitly enforce sn_hr_core.profile_writer for profile operations, modifying underlying ACLs may cause discrepancies in client-side UI Actions, Workspace components, or background APIs that check object-level rights via canWrite() or dedicated Script Include methods rather than pure field-level ACLs. To keep the instance scalable, I would suggest to thoroughly document these custom security rules, incorporate the legal hold workflow into your upgrade regression test plans, and consider implementing an automated server-side action (such as a restricted, privileged UI Action or Flow) rather than granting blanket write access to the table.

[Alekhya Azmeera]

Hi @KPNow 
Can you please provide the solution , if the user has legal hold writer he need to apply the legal hold without profile writer role and should not get anu edit or create access in the hr profile
In the function included in script include

_canAddOrRemoveHold: function(gr, addNewHold) {

        //Whether the operation is valid for the record's current legal hold state

        var notEligible = addNewHold && gr.legal_hold || !addNewHold && !gr.legal_hold;

        //Check record access

        if (notEligible || !gr.canCreate() || !gr.canWrite())

           return false;

        //Check legal hold access

        if (!new GlideRecord('sn_hr_ef_legal_hold').canWrite())

            return false;

        return true;
the above function is the main reason, for without create and write access through ACLs it is not working with legal hold functionality
is there any solution to validate the create and write without ACLs