Set Conditions for an Extension Rule

You determine when a rule is applied by defining a condition. For example, you might create a rule that is applied only when the user is in the Canada and has the Manager role.

There are two ways to define the rule's conditions. The first way is to use the basic condition builder to create conditions by selecting criteria and values. This way should be enough to define most conditions. However, if you need to create more complex conditions, and you are comfortable working with expressions, you can click Use Advanced Expression to open the visual expression editor. For more about using the expression editor, see Build Advanced Expressions.

Rules define overrides that are applied to properties only when the rule's conditions are satisfied at runtime. For conditions that use criteria in the User context, like User Authenticated ($user.isAuthenticated) or Roles ($user.roles), the condition is met if the logged-in user satisfies the condition.

Note:

When using $user.role in a condition, the Value drop-down lists the available Oracle Applications Cloud job and abstract roles. (The drop-down will not list any duty roles. If you want to specify a duty role, you can manually type the duty role name in the Value field.)

You must be granted the ASE_REST_SERVICE_ACCESS_IDENTITY_INTEGRATION_PRIV privilege to see the user roles in the drop-down list. Contact your instance administrator if you require this user privilege.

To create conditions for a rule:

1. Select the extension rule, then click Edit to open the condition builder.
   
   

   
   Description of the illustration metadata-rule-conditionbuilder-adv.png

   
   
2. In the condition builder, define one or more conditions.

   When possible, Visual Builder starts you off by pre-populating the conditions with criteria used in the page, but you can use different criteria in your condition. The criteria, and their available values, depend on what has been set for the page.

   To define a condition:

   1. Select a criterion from the dropdown menu.

      You can choose any of the listed criterion in your conditions, but you cannot change the list of available criteria to add your own.

      Some fields in the list of criteria might be grouped under Object Context or Component Context. These are fields the extension developer has explicitly selected as useful when creating conditions.

      If you know what criteria and values you're looking for, you can try typing in the field to filter the list:

      
      

      
      Description of the illustration metadata-rule-selectcriterion-adv.png

      
      
   2. Select an operator.

      The options available in the operator dropdown menu are pre-defined based upon the criterion's type. So for a criterion like User Authenticated, the operator menu only has equals, and the only available values in the value menu are yes and no:

      
      

      
      Description of the illustration metadata-rule-setoperator-adv.png

      
      
   3. Specify the values.

      Select a value from the dropdown list, or type a value in the field. Depending on the criterion, you might be able to choose multiple values.
3. To add another condition, click + Condition, and then define the new condition. To remove a condition, click .
   When you have more than one condition, the rule is applied only when ALL the conditions are true (by default). However, you can change this to ANY, which means only one of the conditions has to be true in order for the rule's overrides to be applied.
4. To create a group, click the arrow next to + Condition, and then select Add Group in the dropdown menu. Grouping conditions lets you create more complex conditions for the business rule.

   When you click Add Group, your existing conditions and groups are combined into one group, and a new group containing a condition is added.

   
   

   
   Description of the illustration metadata-rule-groups-adv.png

   
   

   Each group has a menu with options for managing the group:

   • Add Condition. Adds a new empty condition to the group.
   • Add Group. Creates a new group within the group.
   • Unwrap Conditions. Ungroups the conditions, and the empty group is deleted.
   • Delete. Deletes the group and all the conditions in the group.

   After creating a group, you can add and define conditions in the group, and set the logic (any, all) for the groups.

5. Click Done to close the condition builder.

   Conditions are always saved automatically, so you don't need to worry about explicitly saving your changes when editing a condition.

   Note:

   Keep in mind that different Oracle Cloud Applications actions (or pages) can interpret conditions differently, which is outside of the realm of VB Studio's knowledge or control. For example, suppose the Country condition is used for a given page in Human Capital Management (HCM). The Hire an Employee action may interpret this as the person who is being hired, while another action might interpret this as the person viewing the page. To understand how conditions are interpreted for a given Oracle Cloud App, consult that App's documentation.

To change the conditions for an existing rule (not a new one), click the rule under Extension Rules, then click Edit above the Conditions pane.

If you’re creating a new extension rule, the next step is to set properties for the fields in the given regions.

Create Condition Using a Field's Initial Value

When choosing a field in the condition builder, you might see fields listed under both Field Values and under Initial Field Values.

When creating a condition, you might want to use the value retrieved from the data source when the page loads—that is, the Initial Field Value. Once the page loads, the Initial Field Value doesn't change. The Field Value, on the other hand, is the value displayed or cached in a page, which may already have been modified by a rule or user. For example, say the value for the Head Count field retrieved from the data source (the Initial Field Value) is 50. There might be some rule that sets the field's value (the Field Value) to 60. The Field Value is displayed in the Head Count field in the form. The user may then change the Head Count field to 70 in the form, so the Field Value for Head Count is now 70. The Head Count Initial Field Value, however, is unaffected by changes made by rules or users, so it is still 50.

Let's look at how to add a rule so that users cannot edit the Head Count value in a form if the field's initial value is greater than 100.

1. Open the page in the Designer.
2. Create an extension rule to set the field's Read-Only property:
   1. In the Properties pane, click Configure Fields and Regions in the Business Rules pane, and then create a new extension rule.
   2. Create a condition where the initial value of Head Count is greater than 100.

      In the criterion dropdown list, be sure to select Head Count under Initial Field Values (as opposed to under Field Values):

      
      

      
      Description of the illustration metadata-initialvalue-set.png

      
      
   3. Set the Read Only property of the Head Count field to Read Only.

      To help you locate where the Head Count field is used, you can type 'head' in the filter field to filter the list of fields:

      
      

      
      Description of the illustration metadata-initialvalue-rule.png

      
      

In this example, the Head Count field in the form might display a value greater than 100 and still be editable, because a rule is modifying the Head Count value. If you wish, you could create a validation rule that displays a message when the Head Count is over 100, telling the user the Head Count field value must be 100 or less. In the condition for the validation rule, make sure the rule is evaluating the Field Value (not the Initial Field Value) for the Head Count field.