Skip to main content

Rule Best Practices

The following are guidelines with regard to writing rules based on keeping them simple and easy to understand or maintain.

General​

  • Create multiple rules with slight differences vs one more complex rule with options
  • Name rules in a logical format, starting with a general category (e.g. "Overtime, ..")
  • Use filters when attaching rules to Pay Groups vs rule parameters (e.g. filter by department or position in the Pay Group vs having the rule inspect parameters)

Parameters​

  • Only parameterize things which would be used in the rule, but may vary from user to user (e.g. a Rounding rule needs to know the number of minutes to round to, but that amount can be decided when applying the rule)
  • Don't parameterize things which can be handled by a filter in the Pay Group (e.g. a Rounding rule should not care about the underlying Punch Action, as that can be filtered)
  • Use descriptive names for parameters, including upper and lower case letters and "_" for spaces. This helps to differentiate rule parameters from function parameters (all lower case) or data fields
  • Don't parameterize temporary variables or storage values which are calculated during the rule (temporary variables are created on-the-fly as a result of performing calculations)

Workflow​

  • The goal of the workflow is to test all conditions which fail the rule early, then get out (e.g. if you're exempt, get out; if its Saturday, get out..)
  • Use comments to provide commentary through the decision making process
  • The final target is to assign the outcome of the rule in the main branch of the workflow at its end. The following diagram outlines a typical decision process with exits processed early, then a final SET as the last step:

Workflow