Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Circumstance rule examples

Updated on November 15, 2021

Assume that you have different pricing levels for your customers. You first define a base pricing rule for all customers. Then you qualify the base rule by creating circumstanced rules for customers at different buying levels. The property .CustomerType is part of the customer order and has values of "Silver" and "Gold". In this example, a customer has purchased a $100 item. Using the property and values, you create circumstanced instances of the base rules as shown here:

  • Base — if .CustomerType="none", then Price =$100
  • Circumstance 1 — if .CustomerType = “Gold”, then price = $100 - 25%
  • Circumstance 2 — if .CustomerType =“Silver”, then price = $100 - 10%

When the system processes the order, the value of that property dictates which rule is run and thereby determines the discount (if any) the customer receives.

Properties in a circumstance

The example above used the single value property.CustomerType to qualify the base pricing rule. Specifying a property value in a circumstance is only supported by certain rule types; refer to the Allow Selection based on Property Rules? check box selected on the Class form defining the rule type.

You can also specify a date property along with the time period against which the value of the date property is evaluated.

For example, an annuity is an investment vehicle providing scheduled payments for many years (or in some cases for the life of the investor). A work item supporting annuity processing needs that an expiration date (say ExpireDate), occurs between December 15, 2015 and December 31, 2015. If a few processing aspects of the work item depend on this value, they can be derived from a base rule by specifying a Date property of .ExpireDate and the start date and end date as 12/31/2015 and 12/31/2015.

A single rule can contain both a circumstance property and a date circumstance property. For the circumstance property value, an exact match is required. For the date circumstance, when a date property is specified its value must occur after the specified start date and before the end date. If a date property is not specified, the system time at the time of processing should occur after the specified start date and before the end date.

Note: If two base rules with the same Apply to key part and family name both have one or more associated property circumstanced rules, the same circumstance property must be used. For example, if activity MyClass.Alpha has an associated circumstanced rule using property .State, then another activity MyClass.Alpha cannot have a circumstance rule with any property other than .State.

Dates in a circumstance

A date circumstance defines a period of time where a version is eligible for selection during rule resolution.

For example, assume that the normal service-level agreement for a retail operation allows four days as the goal time. Management might decide (to accommodate an extraordinary volume crunch in December or January) to create a temporary rule with six days as the goal time. The Start Date of the circumstanced by date rule can be set to December 1 of a year, and the End Date to January 31. No other changes to the application are necessary; assignments created anytime during those two months have the longer intervals.

Multiple properties in a circumstance>

You can use multiple properties to circumstance a rule by more than one feature. For example, an insurance company may be required to collect, for every state, claims that exceed a specific amount and the method by which the claims were conveyed (letter, phone, email, and so on). Another example may be the need for a rule that is specialized by an age range and not an absolute value.

If you use multiple properties in a circumstance, you select the following records:

  • Circumstance Templates (Rule-Circumstance-Template rule type)
  • Circumstance Definitions (Rule-Circumstance-Definition rule type)
Note:
  • For decision tables, you can redirect one circumstanced rule to another circumstanced rule (a peer with the same base rule), to reduce the number of distinct rules that you need to maintain. Select the Redirect this rule check box on the Results tab.
  • A rule cannot be a circumstance if another rule of the same type and name exists in a different class, even if the classes are unrelated and have no inheritance relationship, even if the conflicting rules are set to withdrawn rule. This is because the Apples To class of a rule is not taken into account when looking for conflicting circumstance rule instances, only the name.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us