Those findings are coming from the built in Instance Scan checks, so they do not necessarily mean the widget is broken. They are mainly highlighting code quality, security, performance, and maintainability issues that ServiceNow recommends reviewing before moving the Update Set.
The one I would focus on first is sn_SE10567 because it is marked as Act. This usually means the Client Controller is using browser objects such as window, document, or similar calls directly. In a Service Portal widget it is better to use AngularJS services such as $window or $location instead. For example, if you are using window.location, inject $window into the Client Controller and use $window.location instead.
See screenshot:
sn_SE10612 is only a suggestion. It means there are services injected into the Client Controller that are not actually being used. You can review the function parameters and remove anything that is not referenced in the script. This is mostly cleanup and should not affect functionality if done carefully.
sn_SE10547 is related to hardcoded text in the widget HTML. If the widget contains visible labels, messages, or button text directly in the template, Instance Scan may flag them because they are not internationalized. If your instance supports multiple languages, it is better to use translated messages rather than hardcoded strings. Wrap any visible text inside the translation syntax wrapper, such as ${Your Text Here}, or use the server-side helper function gs.getMessage("Your Text Here")
sn_SE10026 is also worth reviewing because it normally points to alert, confirm, or prompt calls in the client script. These browser popups are not recommended in Service Portal. Replacing them with spModal.alert or spModal.confirm is usually the better option and gives a more consistent user experience.
So I would treat the Act finding as something that should be fixed before promotion, then review the Suggest findings and clean them up where possible. If the widget is already working correctly, the scan findings are not automatically proof of a functional issue, but they are useful indicators of code that may cause problems later, especially during upgrades.
