Circumstance specialization in Pega LSA mission

Example cited for circumstance is as below.

"For instance, consider a loan approval application that offers different interest rates based on the customer’s credit score. Instead of creating separate Rules for each credit score range, you can use circumstance specialization to create variations of the base Rule.

Create a base Rule that calculates the interest rate for a loan. Circumstance the base rule by using the property CreditScore. Create specialized Rules for different credit score ranges, such as:

  • Circumstance 1: If ‘CreditScore’ is between 300 and 579, set the interest rate to 10%.
  • Circumstance 2: If ‘CreditScore’ is between 580 and 669, set the interest rate to 8%.
  • Circumstance 3: If CreditScore is between 670 and 739, set the interest rate to 6%. "

Is this a valid example for circumstance ? Above requirement can be easily implement using decision table, right?

Please advise.

@Denny Varghese

Define conditional rule variants—such as flows, decision tables, or UI sections (UI sections are not supported in Constellation)—based on property values, dates, or combined criteria, instead of relying on complex if-else logic. For example, cases created before 2025 use the path in the base flow rule, while cases created after 2025 follow the new workflow path.

Another example: For loan applications, if ApplicationDate is before 2026-01-01, use the legacy credit scoring decision table (base version) and the base underwriting flow. If ApplicationDate is on or after 2026-01-01—or Applicant.Region = “EU”—use the updated decision table (circumstanced version).

@RameshSangili My question was specifically on the LSA mission example which i sited above. Is it possible to create circumstance based on number range ?

Hello @Denny_Varghese

From constellation perspective, there are multiple things to be considered before you create circumstancing.

  1. Usage on UI or for Business Logic execution
  2. Maintenance overhead
  3. PROD Delegation
  4. ..

If you are circumstancing only for business logic execution, then for the above scenario you mentioned you can always go for Decision Table / Decision Tree as you know already.

For Constellation UI, circumstancing is not applicable.

Alternatively, you can create a Circumstance Template and create Circumstance Definition for each of the condition you have and use them on the rules where circumstancing is applicable.

Lately, i have seen few issues while maintaining the circumstance rules. So its kind of maintenance overhead (My personal opinion).

So, if you really want to have a configuration mentioned as above and also ensure that you have delegation so that you can change the conditions directly in production by business users without needing a code change, you can go for Configuration Sets as well.

With Pega, you will always have multiple options. It’s wise to choose which one suits our application ecosystem better.

Hope this helps

Regards

JC