Limited Set of Field Names appearing in the Set Field Values Pull-down menu in a Business RuleDescription<!-- div.margin { padding: 10px 40px 40px 30px; } table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } .title { color: #d1232b; font-weight: normal; font-size: 28px; } h1 { color: #d1232b; font-weight: normal; font-size: 21px; margin-bottom: 5px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: #cccccc; } h2 { color: #646464; font-weight: bold; font-size: 18px; } h3 { color: #000000; font-weight: bold; font-size: 16px; } h4 { color: #666666; font-weight: bold; font-size: 15px; } h5 { color: #000000; font-weight: bold; font-size: 13px; } h6 { color: #000000; font-weight: bold; font-size:14px; } ul, ol { margin-left: 0; list-style-position: outside; } --> Symptoms Recently after an upgrade of a ServiceNow instance, it is suddenly found that the fields that are available in the "Set field values" for Business Rules associated to the Incident table (and tables extended from the Incident table) are severely limited. Before the upgrade, the full list of fields as associated to the table that the Business Rule is intended to be triggered on would show in this list (as found in the Actions section of the Business Rule), after the upgrade on a limited set of these fields is selectable. In particular all the fields might be missing from the pull down menu except some of the system level fields as associated to that table. Release This issue has been reported on instances upgraded from a previous version (such as Jakarta) to the London or Madrid release of ServiceNow as well as instances that are newly provisioned in the London or Madrid version. Cause The cause of this issue is due to the fact that in some of the newer upgrades (i.e. London or Madrid) for the ServiceNow platform a new ACL has been introduced associated to the Incident table. This ACL has been designed to enhance the security posture of the instance, however in doing so, may have some unintended consequences, including the issue in which the Set Field Values selector may be missing most of the previously selectable values as associated to the targeted table. This new Access Control record is found at the following URL on the instance: https://<Instance_Name>.service-now.com/nav_to.do?uri=sys_security_acl.do?sys_id=e5a4c1c60a0a0bc5007f1b412ab7142c Where <Instance_Name> is the specific instance name for which the fields appear to be missing. The ACL record is of Operation type save_as_template and is enforced on the incident table. As a result of enforcement of this ACL record, only the default, system fields will show in any case which the ACL conditions are failed or the ACL returns a value of false. It will be noticed that the Script field which is part of this ACL record explicitly returns a value of false which will thus cause the business rule to always return false when it is consulted. In most cases in which this issue is encountered, the Admin overrides checkbox will be found unselected (unchecked and thus set to a value of false for the ACL record). However, in some cases it has been reported that the Admin overrides checkbox is already selected. In those cases, any user who is a member of the admin role will be able to see the full list of associated fields, however any user not in this admin group will only see the abbreviated list (system fields). Resolution The specific resolution for the issue will be directly dependent on which users should be designated access to the Incident based Business Rule list of fields. As indicated above, in the majority of cases, this ACL record will have the Admin overrides checkbox not selected (set to false). In this case, the access to the list of fields will be restricted to all users who may attempt to access the Set Field Values field in a Business Rule based on the Incident table. In other cases, in which the Admin overrides checkbox is already selected (set to the value of true), any user with the admin role will be able to view the full range of selections in the Set field values combobox. Thus, in appropriate use cases, the capability to edit these fields and properly allow editing or creation of new Business Rules based on the Incident table can be restricted to users who would normally need that capability. As a general rule, if the user can access the Business Rule form for editing or creation, they should also probably be provided the permissions to view and select the appropriate fields in that Business Rule as related to the target table. However, in many cases it may not be a feasible option to provide user who may need to work with Business Rules based on the Incident table to have full admin permission. And thus you may have developers or other users who may not be (or should not be) provided the admin role but may still need the capability to create or modify business rules based on the Incident table. There are several methods for which this can be accomplished, which would all normally require modification of the Access Control record. This might include creation of a new role and assigning it to the Business Rule, specifying certain Conditions in the Business Rule or modifying the Script field to return, in appropriate cases, a value of true. The end result is to have the ACL pass or return a value of true for the specific cases in which a developer or other approved user should be able to create or edit these Business Rules and be able to select any field from the Incident table as necessary. As mentioned, there are a number of ways that the Business Rule might be modified to return a value of true in the appropriate case, and since each instance is different, a specific method will not be recommended. To edit the Business Rule however, perform the following steps: Log into the instance with an account which is currently found in the admin and security_admin roles. Once logged into the instance with this account, click the pull down menu near your user name. Select the option from the menu labeled Elevate Roles. In the dialog box that appears, select the checkbox labeled security_admin and click the OK button. Browse to the URL of that Access Control record as found on that instance: https://<Instance_Name>.service-now.com/nav_to.do?uri=sys_security_acl.do?sys_id=e5a4c1c60a0a0bc5007f1b412ab7142c Where <Instance_Name> is the name of the instance on which you intend to update the ACL rule. Modify the rule as appropriate to ensure that the ACL passes for the necessary users. To modify the out-of-box rule such that users with the admin role can review the field list, select the Admin overrides checkbox to ensure it shows as checked. This will update the ACL rule such that users must be associated to the admin role in order to review the field list (out of the box, this ACL rule is often set to restrict all users from the list, including those with the admin role). As another example of a possible solution, we might create a special new role and would populate it with individuals who might develop Business Rules based on the Incident table or it's subtables. In that case, we could then add this role to the Role list in the Requires role section of the Business rule. After making the needed and appropriate changes to the ACL click the Update button to save the changes. After making these changes, an existing or new Business Rule based on the Incident table should then show the full list of options in the Set field values selection box to a user who fulfills the criteria in the modified ACL record.