Coding Components of ServiceNow and their usage

Business rules    

    Automating record processing
    Specifying when to take action, such as before or after a database operation
    Validating data
    Inserting events into the event queue

   

    Business rules ensure record processing always occurs regardless of the input source.
    The table associated with a business rule determines the records available to the current object.
    The scope and access settings on a table determine if you can create a business rule for the table.
    You can create multiple types of business rules on the same table.
    There are many existing event business rules to use.

Script includes    

    Reusing server code
    Allowing client access to server code

   

    Functions are good candidates for script includes.
    There are many existing script includes to use.
    Editing existing script includes may break existing functionality.

Events    

    Taking action when certain database operations occur
    Communicating with other applications

   

    Events are not a good choice for schedule-driven conditions. See Scheduled Jobs instead.
    Notifications do not require creating custom events. See Email Notifications.

Script actions    

    Taking action when events occur
    Adding business logic to records that do not directly allow coding

   

    Script actions are intended for event handling.
    Notifications do not use script actions.

UI actions    

    Allowing the user to take action on records
    Actions that require a user’s decision

   

    UI actions are intended for optional actions.
    Require screen presentation in the user interface.
    UI actions can run code from the server side, client side, or both.

Client Scripts    

    Validating data before submitting it to the server
    Reducing queries to the database

   

    Client scripts should not duplicate logic in UI policies.
    Client scripts do not affect non-interactive input sources, such as web services.
    Use the GlideAjax class to improve performance of server-side calls.
    Client scripts do not run in a specific order.

UI policies    

    Enforcing data integrity by making form elements read-only, required, or hidden
    Quickly changing form elements without having to write code for each element

   

    UI policies can conflict with or overwrite client scripts logic. Avoid duplication.
    UI policies do not affect non-interactive input sources, such as web services.
    UI policies apply only to fields on the form. Be sure to add necessary fields to the form.