Welcome to the OPA Hub!

Category Archives: Visibility

OPA – Screen Order and Procedural Logic

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

What you want to avoid is mixing the two kinds of logic
OPA - Customer Business Rule The customer’s name is known and the customer satisfies the refund requirements

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

OPA - Customer Procedural and Business Example

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.

OPA - Visibility Rule

Until next time.


OPA – Dynamic Visibility

Dynamic Visibility

In certain situations, it is necessary to display or hide elements of the Policy Automation Interview. The easiest way to obtain this OPA – dynamic visibility is to create rules, whose conclusion can act as a basis for the Visibility. For example, if the color is red, then show the size question. And inversely – If the color is not red, then do not show the size question.

Such a method is simple and the result is attractive to the End User. It can be implemented with the Question displayed during the Interview, referencing the rule you have created. In the following screenshot you can see an example with the relevant Boolean Attribute referenced in the Attribute Input Control properties.


Mandatory and Read-Only

A similar approach can be taken to render a Question mandatory, or when a Question should have it’s Value displayed as read-only. The existence of a Boolean Attribute to reflect your business logic is once again a pre-requisite, but the process of aligning it with an Input Control is the same.



List of Values – Dynamic Values

A further area where such dynamic visibility can be useful to make the end user experience more enjoyable, is in the area of Lists of Values. If a Attribute has a List of values, some Values may need to be hidden in certain circumstances. The same dynamic effect can be achieved by associating each Value with a Boolean Attribute in much the same way as the previous examples.



Better for the End User

Simple logic such as this can increase the engagement of an End User – after all, the easier it is to complete something with the minimum of irrelevant questions or data the more likely you are to see happy End Users. Until next time, see you soon.