Tag: Attribute

Boolean Values – Getting Started with Oracle Policy Modeling

Boolean Values – Getting Started with Oracle Policy Modeling

Working with new starters to the wonderful world of Oracle Policy Modeling, I often come across interviews that have lots of Boolean attributes. Of course, deciding whether you need a Boolean or something else instead is part of the challenge for new learners : lots of “simple” ideas using Booleans turn into something more complicated and interesting later on.

The main challenges I want to focus on today are those related to the display of the Boolean attribute in the Interview : how to make it more appealing, useful and above all more efficient for the user. Let’s look at some interesting stuff :

Default Values in Oracle Policy Modeling

The simplest and often the most efficient approach is to ensure that the Boolean attributes have appropriate default values : both static and dynamic can be useful. The new input controls from the November 2016 version give us more flexibility (and less messing with CSS) to make things easier to use / view. Below for example is a Switch control, and a defaulted value.

Remember however that these are default values for the interview control, not for the attribute. As some of my colleagues this week found out, this can lead to a bit of a mix-up in trying to create dynamic display of values. Let’s investigate.

Oracle Policy Modeling - Switch Boolean and DefaultGetting Mixed Up with Boolean display

In the image above you can see the checkbox has been checked. This is because we added a default value to the control.

Oracle Policy Modeling - Setting Default

Earlier in this article I mentioned that the default value was (as you can see above) for the input control, not for the attribute. You can see this has a side-effect : when you try and set a second Boolean attribute to use the first one as a Dynamic Default, the perhaps expected behavior is not present. The second Boolean attribute does not register the value.

For example, in the following case, the image “200 Euros” is actually a Boolean Image Control. The colleague in question had changed the type of the Boolean input control to Image. The “clicked” and “unclicked” images had been added to the input as follows:

Oracle Policy Modeling - Images

The default value for the input control had been set as follows:

The Dynamic Default is based on a Boolean attribute which is true, if the customer has spent a value greater than 200 Euros. But the image will not be shown as checked, since the attribute underlying the image does not have a default value – the default value is on the input control. So the effect does not work. The attribute that should have made it work, does not have the value needed:

Oracle Policy Modeling - Boolean Not Dynamic

I have been seeing this quite a lot recently, perhaps because people have been experimenting with the Image control and the new exciting configuration options in November 2016 release. But the approach is not going to work, and the better, simpler (and working) approach is as follows:

  1. Add three images to your Screen. One blank, One for the “TRUE” and One for the “FALSE”. You might want  a third one to use in cases of uncertainty to ensure that the layout of the page does not shift too much when the “true” or “false” images are displayed.
  2. Set the display logic to use the value of the Boolean so that the blank is displayed when the value is uncertain, the “TRUE” image is displayed when the attribute is true and so on.

The Interview Screen looks something like this during the preparation. The first three bullets are three images. The final is an example of setting the display behavior.

Oracle Policy Modeling - Final Boolean Image Display

Now the overall effect is what you would expect : changing the value of the threshold (here, 201) to a value where the Boolean is true, triggers the display of the image in Oracle Policy Modeling debug.


I hope this clears up some things for some of my colleagues this week.

Back to Basics 3 – Writing a boolean in Oracle Policy Modeler

Back to Basics 3 – Writing a boolean in Oracle Policy Modeler

Back to Basics 3 – Writing a boolean in Oracle Policy Modeler

Many times whilst delivering workshops or the official Oracle University training courses on Oracle Policy Automation, the group in front of me is a wide mix of skills and backgrounds. Those who come from the business side tend to, for obvious reasons, not have had large amounts of exposure to writing with constrained natural language or indeed for that matter maybe they have never actually written rules themselves. Instead they have been delivering detailed explanations, specifications and so on and then testing them for pertinence.

With Oracle Policy Automation, or Oracle Policy Modeler to be precise, some of these team members are now actually writing the rules. Maybe not all of them, maybe not completely, but the blended team has gotten a lot closer. One of the things that comes up regularly in the early part of their learning curve, and thus a good candidate for the Back to Basics posts – is how to write and not write Boolean statements in Oracle Policy Modeler.

Basic Idea #3 Boolean statements need a verb

Yes they do, and without a verb you are pretty much assured that Oracle Policy Modeler will validate the rule but will not interpret it in the way you had hoped. Consider the following example rule. I have clicked the (bizarrely named in my humble opinion) Go To button on the Ribbon to display the details. Notice I am about to click on the Edit Attribute… button.


The Edit Attribute dialog will show me the Attribute is a Boolean. Fine I hear you say, so what. I could write it like this instead. Look, it has even underlined it like it does with the other stuff – it must be working, right?


It depends what you mean by working of course :). Let’s take it step by step.

  1. For a Boolean to be acceptable to Oracle Policy Modeler, it must be negatable. Or, it must be written in the negative, and be able to be expressed in the positive also.  For example, the following is a perfectly acceptable Boolean conclusion, being just the negative version of the initial conclusion I showed you a minute ago.

2. For a Boolean to be acceptable to Oracle Policy Modeler, it must use a verb that is in the list of verbs.

3. When you open the Edit Attribute dialog in Oracle Policy Modeler for a Boolean attribute, you should see four different phrases in total that will look like the following


They are, the positive, the interrogative, the negative and the uncertain. These are the states that your Boolean can have. If you look at an attribute and you see this instead:

Then you are not looking at a Boolean. In this case you can see the interrogative, the assertion, the uncertain and the unknown. Of course the little icon saying “Text” also shows you something is amiss.

It is absolutely critical to get in the habit of checking your attributes before you launch Word. Picking up issues early will save heartache later.

Policy Automation – Abbreviations

And so, this will be an abbreviated post in keeping with the theme. In the Policy Automation training delivered for Oracle University, we discuss the need to balance the benefits of constrained natural language (accessibility to the rules development for non-technical users, close parallelism with source material and so on) with the needs of project implementation (sometimes we need to write complex rules, and the natural language can seem to make things even more complicated).

A good example of one way that Policy Automation can help with achieving brevity is the use of the Legend. In the class we discuss and demonstrate it’s use in Microsoft Excel. For example:

OPA - Big Excel Table

You can probably identify the problem. The column widths are huge. And this table has only got 3 columns. Imagine several more conditions and conclusions. The things would be way too big.

In the class we show that using the Legend feature of the Excel Spreadsheet to create abbreviations can help dramatically reduce the size and manageability of the spreadsheet:

OPA - Declare Legend

So now the final result looks pretty neat and tidy.

OPA - Improved Excel Table

What we do not mention however in the training class is that the same technique is equally applicable to Microsoft Word. Specifically, the Table Legend markup format is also available inside Microsoft Word from the Ribbon / Toolbar.

OPA - Legend in Word

Once this becomes clear you can use the same concept to create abbreviations in Word. For example in the picture shown below, the first part of the Word Document shows how to declare an abbreviation for an existing Attribute. The second part shows how to use them, and it is pretty self evident.

OPA - Final Rulebase

This is clearly useful, not to be overused to the point where natural language ceases to be natural, but where complex calculations are used it can definitely help. Until next time, see you soon!

Policy Automation – Gender in Policy Modelling

In previous posts we looked at a variety of different traps and challenges that Policy Modelling rule writers face as they work through the exercises of their Oracle Policy Modelling training. This post aims to clarify a concept which is not mentioned in the training, but which extends the ideas discussed last time – designing for the context of the rulebase.

Perhaps the simplest form of context is one that we all learn quite early  – the notion of gender. Consider possessive pronouns (in English, his or her or its, for example) – their use can considerably enhance the delivery of a Policy Modelling web determination:

Claimant : Janet Smith

Has Janet completed her complaints form?

Claimant : Bob Jones

Has Bob completed his complaints form?

Setting up the functionality comes in four parts which we will look at in this post. It does not require us to rewrite our rules or think up some convoluted way of getting round the problem.

Part One – Create the Attribute

Creating the “gender” Attribute is quite straightforward. In the example below you will see a standard Entity called “the customer”, with the default identifying Attribute displayed as well as a manually created text Attribute called “the customer’s gender”. For the sake of good practice we have given Public Names to the Entity and the Attributes.

OPA - Customer Gender Setup

Part Two – Assigning the Gender Attribute

In the next screenshot, we have selected the identifying Attribute for our customer Entity and we have selected the “gender” Attribute in the relevant Property. So the customer has now an assigned Gender Attribute.

OPA - Identifying Attribute with Gender

Part Three – Displaying the Gender Attribute

Of course in order to make this worthwhile we need to let Web Determination users select a value for the Customer gender. When you add the gender Attribute to a Question Screen you will notice a telltale icon to reveal that Policy Modelling has understood that this is gender Attribute. In addition you will see that List of Values has automatically been added to your Question Screen for the collection of the Attribute value.

OPA - Question Screen with Gender Attribute Collected

Part Four – Collecting the Gender

Now that our gender Attribute is in place, we can see the result when we implement a rulebase. The rule below will serve as a simple demonstration.

OPA - Example Rule for Gender Post

The key statement is “the customer has completed the customer’s complaints form if”. The second “the customer” will be affected by our new functionality.

Remember that to ensure you are able to enter your Customer instances and supply their gender, you will have to create an Entity Instance Collection Screen.

OPA - Entity Instance Collection Question Screen

OPA - Customer Collection Screen

Finally make sure you add the global goal (“the interview is complete”) to your Assessment Summary Screen before you Build and Run a Web Determination.

OPA - Assessment Summary Screen

Alternatively you can run a Build and Debug session instead. In both cases you should see a result similar to that shown below.

OPA - Debug Gender


OPA - Bob and His Complaints Form


If you do not provide a mechanism whereby the gender can systematically be collected, what will happen? The side-effect of forgetting to add your gender Attribute to the relevant Question Screen will be something like the text shown below. Of course you would prefer it to look something like this, so make sure you collect the gender!

OPA - His Her Its


Finally, now that you have set up this feature in your rulebase, you can use substitution to display the correct gender pronoun using the following documented syntax.

%custid% and %custid:his/her/its% complaints form 

Until next time, have fun!

Policy Automation – Substitution and the Second Person

Writing rulebases requires not just an awareness of the source material, it requires an awareness in many cases of the context of the delivery. For example, if a rulebase is intended to be used for an interview that will be undertaken by a human being, then there are several things the rulewriter needs to think about.

Substitution and Identifying Attributes

Would the customer like to receive further information?

Policy Automation - Tick the Box

In the above example of a boolean Attribute, clearly the phrase is simple to understand. magine you are interviewing someone and you are asking them the question. It would make more sense to ask (probably)

Would Richard like to receive further information?

The use of the name of the interviewee is both friendly and advantageous. It can be implemented by using Substitution on the Attribute that we are referring to. In the example below it might be the “the customer” Attribute.

Policy Automation - Substitution

Policy Automation will automatically substitute the actual value of the Attribute if it is defined using the above option and it is defined as the identifying Attribute for an Entity as shown in the next image.

Policy Automation - Identifying Attribute


This means that in the Debug window for instance you get to see the Identifying Attribute instead of “the customer 1”, like in the example below

Policy Automation - Debug Automatic Substitution Entity

Rule writers who are building Screens for their interview can also use substitution for other Attributes by referencing the public name, such as

Thank you, %firstname%, here is your receipt: %receiptnumber% .

This can also be used in Translation files as well.

Now however imagine you are the customer. Wouldn’t it make more sense to see

Do you require a receipt?

But suppose you have gone to the trouble of writing your rules already, with the syntax above using “the customer”. There is absolutely no need to rewrite the rules, you just need to take advantage of the feature in the Project Properties as shown below. In order for this to work, normal substitution needs to be activated first, then you can select the Attribute to be generated in the 2nd person as well.

Policy Automation - Project Properties


As a result, whether it is in the debugger or elsewhere, you will see the relevant Attribute as in the example below. For clarity, the two images first show the Attribute Text as it was written, and then the generated second person text.

Until next time!


Policy Automation – Formulating Phrases – 3 Traps for Beginners

There is a great deal of detail regarding the formulation of phrases that we touch on during the OPA training courses. Unfortunately for time reasons a lot of it is tucked away in a very dense sort of appendix which means it does not have as much impact or value as it might have, from a training perspective.

This post aims to highlight for apprentice rulewriters some of the most obvious traps that come up in the early stages of learning.

Firstly and probably most importantly, the notion of how to write about Attributes. Variables (for that is what an Attribute is) can be, fundamentally, boolean or non-boolean. And the manner in which one writes them is equally black or white.

Booleans will always have a verb (and only one operative verb). Consider

the customer’s order is accepted if
the customer’s order status = “Completed”

the first line, otherwise referred to as the conclusion, is a boolean Attribute. The order can either be accepted or not accepted, (yes, or potentially can be unknown or uncertain but let us think simply for a moment). One way to ensure you have correctly phrased a boolean is to check the Parsing dialog visible in the Attribute Editor.

OPA - Parsing Errors

Check that the different phrases actually make sense and that the Parser has not got confused, which can happen if you have two verbs in the sentence. Something like

the taxpayer completes a tax return

can confuse the parser since there are two potential verbs in there (maybe even three – complete, tax, return). So looking in the parser to see things like the taxpayer completes a tax might return can certainly help identify issues!

The second kind of attribute , the non-boolean, also requires careful handling. The phrase

the order status = “Completed”

will only function correctly if the order status is declared as a Text Attribute, because in that case the = “Completed” is referring to the value of the Attribute correctly. Non-boolean Attributes should never have a verb in them. They are just “things” not “statements”.

OPA - Text Attribute

New rulewriters often get mixed up and write things like

the customer’s order is completed

and then wonder why they have gotten a boolean Attribute (“is” is an acceptable operative verb, and the phrase parses correctly and reads correctly). Checking the markup text can be a telltale sign that things are not going right. Below you can see both Attributes are marked as “b” for boolean.

OPA - Customer Order Happy

Then when building an interview Screen, things go wrong since we are not able to add a custom List Of Values unless it is defined as a Text Attribute. Looking at the Screen File in both cases we can begin to become familiar with the icons, which can serve as a hint that all is not as it should be.

Thirdly and perhaps confusingly, in most cases you do not need to explicitly declare a Boolean Attribute. Coming back to our phrase

the customer’s order is accepted if
the customer’s order status = “Completed”

The parser will proceed as follows

  • the customer’s order status must have been declared as a Text Attribute in either the Word Document or the Project Properties File, otherwise an Error will occur.
  • the customer’s order is accepted will automatically declared as a Boolean Attribute in this case, without the rulewriter doing anything.

There are several other common pitfalls, and these are revealed in the coming posts. Until next time!

Policy Automation – Translations, HTML and Substitutions Ideas

Policy Automation offers rule designers several ways to personalize a Web Determination session, the goal being to make the interview more streamlined and friendly.  This post is a continuation of a discussion during a recent training.

Settings on the Attribute to handle minimum and maximum and regular expression validation.

OPA - Attributes

Settings on the Screens used to collect information:

OPA -Screen

Screen Order and Screen Flows to Control Logic:

OPA - Screen Flow and Subflow

Obviously as these grow more complex and your interview becomes more involved, the need to manage any translations of your rulebase becomes ever more important. Policy Automation provides the easy Translation File system to let you manage the translations of your rulebase questions and texts.

OPA - Translation

The warning message let’s us know that there are some strings used in the Excel Translation File that have not been translated. This can be quite confusing. Obviously most translations are obvious in the file, for example:

OPA - Excel File Translation Example

But even after going through all the texts, you might still get the warning message and wonder why. That is because even if something is not really translatable, then you need to either translate it anyway or mark it to be ignored. Consider the following example:

OPA - Ignore Translation Example

The car manufacturers included in the dropdown list are not required to be translated – they are to stand as-is. Then you should mark them to be ignored using the relevant button as shown in the example, and the text will change color as demonstrated.

As you add more Question Screens to your interview, the output in the Assessment Summary will become progressively less readable, especially in the case of an interview involving multiple records for multiple entities, as shown below.

OPA - Assessment Summary

By judiciously adding Labels and Folders to your Summary Screen, as well as substitution to your Translations and a little bit of HTML you can quickly come up with something more readable.

OPA - Assessment Summary Edited

This gives the following output:

OPA - Assessment Summary Improved

Further addition of substitution can improve it even further with  minimal effort.

OPA - Substitutions Galore

This in turn will improve the output of the Decision Report as well as our Assessment Summary of course. For instance clicking on the “Why?” next to “The mechanic does not have more than 3 cars waiting” in Janet’s section gives the following display.

OPA - Decision Report First Try

But we should be mindful of the performance impact of large amounts of information in the Decision Report, since it might be destined to be integrated with Siebel CRM or saved as a file. So we can return to our Attributes and change the Decision Report settings to either Invisible (it disappears) or Silent (it hides the providing Attributes). The options for Relationships and Attributes are slightly different:

Which gives us the slimmed down version below:

OPA - Decision Report FinalWorking to reduce the amount of static text through substitution, maintaining an uupdated Translation file and managing your Decision Report output can improve the user experience, reduce overhead and clarify your interview. Until next time!


Logo by Southpaw Projects LLC