Best practices for building coding rules

Use these guidelines to optimize your coding rule creation process.

Use a test environment

Confirm that your coding rules are working properly by verifying the expected functionality in a test environment or workspace.

An improperly configured coding rule could impede the document review process. Perform thorough testing of new coding rules before enabling them in an active production workspace. If a rule is not functioning properly, turn off the Enabled toggle. For more information, see Editing coding rules.

Check the logic for your conditions

Ensure that you don't have any conflicting conditions in your coding rule. For example, a conflict occurs if you have one condition that checks if Responsive is true, and a second condition that checks if Responsive is false.

The software checks the conditions that you set to ensure that they are logical statements. However, it cannot confirm the validity of your business rules. You can avoid interruptions to your review process by validating the business logic used in the rule before it is enabled in an active workspace. The rule immediately begins executing during the review process once its Enabled.

Use unique names for choices

It is important that all choices and sub-choices added to your workspace have unique names. If there are choices or sub-choices with identical names, validation will affect all instances sharing that name, regardless of their parent choice. For instance, if a choice field has two "Yes" sub-choices, and "Yes" is used as a value in a conditional coding rule, it will impact all "Yes" choices, irrespective of the different parent choice values.

Avoid changing field names

Do not change the names of fields referenced by a coding rule. Conditional Coding Rules does not make any changes to the field names referenced by a rule already present in a workspace. If you modify the field name, the rule that referenced the field will no longer function correctly in the workspace.

Conditional Coding Rules references the name for a layout, field, choice, or group. It does not use custom labels assigned to fields or groups.

Backslashes in field and choice names

When adding conditions, ensure that the names of choices and fields do not contain a character string containing a backslash preceded and followed by a space. For example, you do not want to use a multiple choice field in a condition that contains a choice with the following name:

• Example: Choice B \ 1

However, you can use choices and fields that contain a backslash preceded and followed by text.

• Example: Choice B\1

Wildcards in field and choice names

When adding single or multiple choice fields to a condition group, you may select fields or the choices with names that contain wildcards (asterisks, backslashes, or underscores). Ensure that fields or choices have unique names if the wildcard characters were omitted. For example, Responsiveness_Test and ResposivenessTest are not considered unique.

Another invalid scenario involves choice names. A workspace could have a multiple choice field called Choice B with the following sub-choices:

• Choice A

• Choice B
  • Choice B\1
  • Choice B \ 1
  • Choice B \\ 1

Since Conditional Coding Rules ignores the wildcard characters, it sees the same name for the three sub-choices, which causes conflicts and potentially undesired validation behavior.