OPA – Screen Order, Visibility Logic and Procedural Logic
In the previous post we discussed inference, and the kind of impact it can have on the final interview experience from the point of view of the end user. That discussion brings us neatly on to another subject – different kinds of rules and when to use them. Consider a customer in a shop asking for a refund. To obtain a refund they need to provide the product they wish to return, as well as proof of purchase (a receipt), and they must have the payment card with them, and some form of photo identification. We can call that the “refund requirements” for the sake of brevity.
Rule sets will include business goal based logic such as
But for the purposes of your CRM integration, or your internal Procedural Logic, you need to log the person’s name.
The customer's name is known
Although you need to know the person’s name for your own internal process, it has no real impact on their eligibility for a refund. Mixing and matching in this way is bad practice, and can end up perturbing the order that your Question Screens are displayed by the inference engine.
To overcome such a mix, you should include a new procedural goal
One of the key questions to ask at this point of your rule creation is – does this attribute (the name) actually have an impact, or is it for statistical, commercial or other reasons? If it has a job principally of controlling data entry or interview flow, then in should be kept separate from the business rules. In the same manner, it is bad practice to use real substantive goals as part of your visibility strategy in your Question Screens. For example if you want to control whether something is going to be displayed or not on a Summary Screen, use a separate Visibility Rule.
Until next time.