Before writing your custom code, prepare the following information:

• A description of the system design with all object definitions, their custom fields, blocks, object views, and so on.
• A complete list of user groups and their rights.
• A complete list of business rules that need to be implemented.

For each rule in the rule specification documents, a minimum of the following requirements must be specified:

• Object definition for which the rule must be created and defined.
• Rule description/title that will be used when defining the rule.
• Rule type (for a complete list, see the Rule Types table).
• Trigger (for a complete list, see the Rule Triggers table).
• Qualifier/condition:
  • Whether it is done through the user interface or API.
  • If through the API, are you choosing Java or JavaScript?
  • Whether it has parameters or not. If, yes, which ones?
• Action:
  • Whether it denies, approves, or performs a custom action.
  • If the action is to deny, the message that appears to the user.
  • If the action is custom, the use of Java or JavaScript.
  • Whether it has parameters or not. If, yes, the parameters needed.
• List of fields used in the rule, with their names (not labels), full tree positions (for custom fields), full lookup item tree positions (for custom fields of type List), full category tree positions under which custom fields are created.

Consider the following when reviewing rule specifications:

• The rule does not duplicate or replace rights set in the user or group accounts (functional level security).
  
  For example, if a rule is to prevent a user from creating, deleting, or updating records of a specific object definition, determine whether this may be done through the rights set at the user or group account level. You may also use record-level security to assign rights to users.
   
• Whether the indicated rule type and action match.
  
  For example, if the action is to deny and display a message, use a validation rule instead.
   
• Whether the trigger is identified properly.
  
  This is important because the exact appropriate behavior must be identified. For example, in rules, there is no such trigger as Save. Instead, there are Create and Update triggers that are associated with the Save button in the user interface. The list of triggers is provided in the Rule Triggers table.
   
• Whether the specified trigger is available for the indicated rule type.
  
  This needs to be taken into consideration for the rule types other than custom or scheduled actions. For example, you cannot create approval rules for the Update trigger or the Check-In trigger in documents.
   
• Whether the rule may be created through the user interface.
  
  For example, just because a rule is of type custom action, it does not necessarily mean that its qualifier must be automated as well. Simple qualifiers, such as checking a value in a field or a user's group membership, may often be created through the user interface.
   
• Whether any automated actions and qualifiers may be reused. Indicate which ones and for which rules.
  
  For example, several rules may have to perform the same action but under different conditions, or vice versa, perform different actions under the same condition. Always keep in mind the concept of separating qualifiers and actions in a rule that allows you to mix-and-match files to minimize duplication of effort and to maximize the flexibility of the rule development process.
   
• Whether there are any complementary rules, rules with the same qualifier and action but a different trigger. Indicate which ones.
  
  For example, two rules may need to be created to enforce the workflow process when the Save button is clicked--one rule with the Create trigger and the other with the Update trigger.
   
• Whether any additional or complementary rules are needed to enforce the workflow process. Indicate which ones.
  
  For example, you may need to break a more complicated rule into several rules, or a rule with the Update trigger may be required to complement the specified rule with the Create trigger.
   
• Whether there is any missing design information that you would need in the rule.
  
  For example, categories' full tree positions may not be provided for custom fields, or lookup items' full tree positions for List fields or sub-objects, and so on.