1. Before Business Rules should not update() or insert() records on other tables
Coding Standards : To ensure data integrity, change this business rule to run "after".
2. Business Rules should not be defined on the Global [global] table (Global Business Rule)
Coding Standards : Use a script include instead of a global business rule.
3. Avoid Global UI Scripts
Performance : Make the UI Script non-global, and include the UI Script on the appropriate page by referencing the script as needed
4. Client-side code should not contain the console.log() debugging method
Coding Standards : Replace console.log() calls with jslog. The benefits of jslog are that you have to open the JavaScript Debugger Window to view the output, it is compatible with all browsers, and can be left in production since only administrators can open the window.
5. Client-side code should not use DOM manipulation technique
Upgradeability : Avoid Document Object Model (DOM) manipulation if possible. It can cause a maintainability issue when the instance is updated. The only exception is when you are in charge of the DOM: in UI Pages, and the Service Portal. Instead, use the GlideForm API or consider a different approach for the solution. In general, when using DOM manipulation methods, you have to reference an element in the DOM by id or using a CSS selector. When referencing out-of-box DOM elements, there is a risk that the element ID or placement within the DOM could change thus causing the code to stop working and/or generate errors. While we are not saying this should never be done, it needs to be done with forethought, caution, and a full understanding of the risk you are incurring. It is recommended to review these objects and reduce the use of DOM manipulation methods as much as possible.
6. Client-side code should not use GlideRecord
Performance : Use client data as much as possible to eliminate the need for time-consuming server lookups. The top ways to get information from the server are g_scratchpad, and asynchronous GlideAjax lookup.
7. Client-side code should not use synchronous AJAX methods
Performance : For data that can change during the user experience, replace g_form.getReference with GlideAjax, a callback function, and a custom function in a Script Include that returns only the needed information. For data that remains the same after the form loads and can be determined before the form loads, replace g_form.getReference with a Display Business Rule and g_scratchpad. If using getXMLWait, replace with getXML and a callback function.
8. Complex Workflows, with more than 30 steps
Manageability : Using sub-flows can drastically reduce complexity and allow you to create more modular workflows
9. Convert after Business Rule to async
Performance : OnAfter Business rules are blocking, and so cause a pause while they are executed. Verify if the business process can run with an async execution of the logic, which results in an immediate return to the user.
10. Differs from baseline: Business Rules
Upgradeability : Review the changes to these Business Rules and revert to the baseline version if appropriate. Otherwise, thoroughly test after an upgrade.
11. Differs from baseline: Client Scripts (and UI Scripts)
Upgradeability : Review the changes to these client side scripts and revert to the baseline version if appropriate. Otherwise, thoroughly test after an upgrade.
12. Differs from baseline: Script Includes
Upgradeability : Review the changes to these scripts and revert to the baseline version if appropriate. Otherwise, thoroughly test after an upgrade.
13. Disable Help the Deskdesk
Useability : This is a service offered but usually not used by customers and therefore could potentially be disabled.
14. Don't use a variable called gr in scripts
Coding Standards : Change code like "var gr = new GlideRecord('incident')", to be something like "var grInc = new GlideRecord('incident')"
15. Excessive Client Scripts
Performance : Check if the functionality is necessary. Often client side scripts can typically be remade as server side scripts, which will often perform much faster.
16. Generally reports should not be made public
Security : Instead of publishing a report and making it public for every user, irrespective of login, share reports using Groups, Users and Roles. To make a report available only to logged in users, set its Sharing setting to Everyone, but do not publish it.
17. Lots of active tasks more than a month old
Manageability : Check your processes to ensure that tasks (Incidents, Problems, Changes, Requests) are being closed as expected, and the active flag is set to false.
18. Minimize logging in production
Coding Standards : Remove the logging functions entirely, or control their use with a property. At the minimum, switch to using gs.info and gs.debug
19. Read ACLs / Security rules have GlideRecord/GlideAggregate in script
Performance : ACLs will be evaluated on frequently, so it is important for them to be as efficent as possible. Try to avoid lots of database lookups, as this can significantly impact performance.
20. Read only in dictionary
Manageability : Use access control rules instead of the read only option
21. Reports not run for 3 months
Manageability : In order to keep a manageable number of reports, old reports should be removed.
22. Scripts do not directly call Java packages
Upgradeability : Run the Package Call Removal Tool, and replace all Java package calls with the Glide alternative
23. Scripts should not contain hard-coded IDs
Manageability : Create a system property to store the name of the record (not the sys_id) for easier manageability. The script can use gs.getProperty() to retrieve the record and use the sys_id. If the named record was not found, an error can be displayed appropriately.
24. Scripts should not use the eval() method
Security : Use 'var evaluator = new GlideEvaluator();' or 'GlideEvaluator.evaluateString("gs.log('Hello World');");' This evaluates the script in a secured context and won't do harm to system variables.
25. Server-side code should not use GlideRecord and getRowCount() to count records
Performance : Replace GlideRecord with GlideAggregate and a 'COUNT' aggregate to improve performance. This could make a large impact when working on tables with a high record count
26. Slow loading forms
Performance : Slow loading forms may occur if there are a lot of fields, scripts, database lookups, etc. Optimize client side logic and form behaviour.
27. Table Transform Maps generally do not need "Run business rules" enabled
Performance : Unless you need business rules to run during the transform, un-check the 'Run business rules' checkbox on the Table Transform Map when transforming large amounts of data (or high volume data). Unless you need business rules.
28. Too many fields on a form
Useability : Too many fields on forms could impact the service expierence and leave the user/agent frustrated. Work on reducing complexity of the given form.
29. Too many options in a choice field
Useability : Check if all the options are really required. Consolidate the options down, or pick another field type.
30. Use Notification Categories
Manageability : Associate a notification category with every email notification
31. Use the condition field in Business Rules
Coding Standards : Using the condition field makes it easier to spot when scripts are being evaluated in the session debugger. Also, it is more efficent, since the script does not need to be parsed unless it is going to be executed.
32. Workflow validation issue
Data & configuration integrity : Try to address all the workflow validation findings.
33. Workflow(s) checked out for an extended time
Manageability : Follow up with owner of the checked out version and ensure the changes were made appropriate and/or remove the checked out version.