Got feedback or spotted a mistake?

Leave a comment at the end of this page or email contact@krishagni.com

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

While writing data validation rules in the ‘editChecks’ section of the workflow, these three form the basic skeleton of the check.

More information on Data Validation over here.

A common thought: Multiple records, forms and rules can be included in “records”, “ forms” and “rules”. So, won’t it be easier for the user to write a block including all the 3 records, all the forms on which edit checks are to be performed, and define all the rules one below the other?

It will be easier to write, but a very inefficient code. The reason is, checks are performed as per the ‘when’ part of the ‘rules’. This identifies the situations when the edit check needs to be applied.

If there are 3 edit checks involving ‘cpr’ and ‘visit’ and 1 edit check involving ‘cpr’ and ‘specimen’, including all of them together would be an easier but highly inefficient option. The dependencies on specimen will be checked too every time only the ‘cpr’ and ‘visit’ records are accessed.

So, it will be appropriate to include the 3 ‘cpr’ and ‘visit’ checks together and ‘cpr’, ‘specimen’ check in a different records-forms-rules block.

This works like the Highest Common Factor rule of mathematics!

Identify the rules that have checks applied on the records that match.

Group the common checks under one records-forms-rules block. If there are no matches, add a separate records-forms-rules block.

This will ensure an efficient check of dependencies and only for the respective records involved in the check.

  • No labels