As Paul mentioned, someone on your team likely added a sys_ table to this list to be able to report on it. One that stands out to me is sys_email; this is not set by default in my PDI.
My PDI, which is on Washington Patch 4 Hotfix 1, and has never been customized, contains the following for your reference:
sys_db_object,sys_user,sys_audit,sys_user_group,sys_user_grmember,sys_dictionary,sysapproval_approver,sys_user_has_role,sys_group_has_role,sys_user_delegate,sys_report_page_hdrftr,sysapproval_group,sys_api_stats,sys_api_stats_requestor,sys_api_stats_requestor_monthly,v_api_stats_requestor,sys_portal_page,sys_report,sys_alias,sys_complex_object_output_strategy,sys_upgrade_history_log,sys_hub_flow,sys_hub_action_type_definition,sys_aw_master_config,sys_ux_app_config,sys_ui_page,sys_ux_page_registry,sys_user_has_license,sys_di_task
I also cross-checked another instance that's on Washington Patch 7a and it also did not contain sys_email.
With all that said, these are the options you have:
- Revert: ServiceNow will overwrite your permitted tables list with what it typically does OOTB. This will contain a lot of the same tables you have now, but any that you've added yourself will need to be re-added. If, for example, you are reporting on sys_email, those reports will probably be broken until you update the permitted sys_ table list again.
- Retain: Keep the customizations you have made to the system properties (e.g. keep sys_email and anything else). Nothing will change for you, but if ServiceNow added more tables to this list during the upgrade, you'll miss out on those being auto-added.
