Organizing and Naming Rules
To make your system as efficient as possible, it's important to organize your rules in each table. When your rules are organized and clearly named, it makes it easier for other admin users to work with them and troubleshoot potential issues. If you don't organize your rules, they can unnecessarily grow in number and be cumbersome to maintain.
Broadly speaking, the best organization method involves creating a limited number of standardized, clearly named rules in each table. Placing your actions into fewer rules helps control their priority order and makes them easier to maintain and understand. You can do this by using If-Then-Else actions in each rule that have multiple conditions and actions to accomplish your desired automation.
Organizing Rules
Any table that uses automation can usually group all required actions into a few standard rule types:
| Rule Description | Included Actions |
|---|---|
Rule 1: New Record Actions | Include actions that run when a new record is created. This also refers to conditional actions that only run when the new record meets some specified criteria. Make sure to also include Validate actions that run when a user attempts to create a new record. |
Rule 2: Edit Validations | Include Validate actions that run when a user edits a record. In most cases, tables have multiple Validate actions of this sort, but if the table only has a single edit validation, place it in one of the next two rules. |
Rule 3: Power User Edits | Include actions that run when a power user edits a record. |
Rule 4: End User Edits | Include actions that run when an end user edits a record. Updates made by end users and power users might require different triggers. This is why it's usually a good idea to group them into separate rules. |
Rule 5: Parent and Child Actions | Include actions that relate to parent-child relationships. These are cases where two or more records have a relationship to one another such that the child is subsidiary to the parent. For example, a Change Request record might be the parent of several other Change Request records that are its children. When the parent Change Request is approved, the system automatically approves all its child Change Requests. However, the reverse is not true, so approving a child Change Request does not also approve its parent. If a parent-child relationship is relatively simple, the relevant actions can sometimes fit into another rule. If the relationship is complex, place them in their own rule. |
Rule 6: Actions that Rely on Changes from other Actions | Include actions that rely on changes made by other actions. Updates made by actions aren't saved to the database until a rule is completely finished running, so actions that rely on changes made by other actions must be placed in a separate rule. For instance, if one action sets a contract's end date, and a second action uses the end date to set the contract's renewal notification date, the second action must be in a separate rule. |
| Rule 7–8: Actions with and without API Triggers | Include actions that should be triggered by API changes, provided the rule that would otherwise contain them is not triggered by API changes. An API change is any change made by an action or rule, rather than by a user or an email update. Conversely, if a rule that would otherwise contain an action is triggered by API changes, but the action should not be triggered by API changes, it must be included in a separate rule. For example, if a rule is triggered by a customer update, it shouldn't also be triggered by an API change. This is because rules make modifications to records in the name of the last user to update the record. If additional rules are also triggered after the customer update, the system thinks each of those rules is an update from the customer. So, if the initial rule is also triggered by API changes, it will be re-triggered for every additional rule that runs. You can also clear the Run Rules checkbox on the Condition tab of the Rule wizard to prevent a rule from triggering other rules. However, this prevents all rules from being triggered by the current rule, which isn't always what you want. Clearing the Run Rules option is often better suited for time-based rules, which you typically don't want to trigger other rules.
|
Rule 9 and Greater: Time-based Rules | Include any actions in time-based rules that run at pre-defined intervals. Whenever possible, consider combining time-based rules using If-Then-Else actions. However, if you only need to run a few time-based rules, keeping them separate is acceptable and creates a clean-looking interface. |
Naming Rules
When you create rules, it's important to name them clearly and descriptively so that other admin users can easily understand the rule's purpose. It's also important to follow a few naming conventions so that your rules are organized in your system and standardized across tables.
- Describe the Rule's Trigger: Add a prefix to the beginning of the rule's description that indicates how the rule is triggered. For event-specific rules, use prefixes like "Create," "Edit," or "Create/Edit." For time-based rules and summary condition rules, add "TB" and "SC," respectively.
- Describe the Rule's Trigger Type: For event-specific rules, include the rule's trigger type in parentheses at the end of the rule's name. For instance, you might enter "(API)," "(Web)," or "(Email, Web)."
- Indicate When the Rule is Disabled: Add a "DISABLED" prefix to a rule that's not active. This lets admin users know that the rule is disabled without having to edit the rule.
These are some example rule names that follow the previous conventions:
- Edit: Validate that end date is after start date (Web)
- TB: (DISABLED) Notify of upcoming expirations
- Create/Edit: If Transitional Contract Files field has value, convert to Attachment (Email, Web, API)
- Edit: Assigned team or person changed (Web, API)
- SC: Email Sales team when sales goal is reached