Skip to main content

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

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Rule availability options

Updated on February 27, 2018


What are the choices for rule availability, and what is each used for?


As you create an application, you might want to control how other developers can copy or change those rules. For example, there may be a rule which must be used as is and cannot be changed (perhaps for legal reasons), or a rule might be out-of-date and should not be considered during rule resolution.

The Availability option on a rule allows you to prevent rules from being copied, or turn off rules that had been in use (if they are no longer applicable or a different rule was put in place), as a safeguard.

For example, you might create an activity (ShowData) to replace an existing activity (Display). As part of putting this new activity in place, you change all references to the replaced activity with the new activity, because this new activity has a different name (and presumably different functionality).

If you left the replaced Activity in the system, you could not be sure whether all instances of this functionality had been replaced, because it would be used in processing; you might not see that the wrong activity had been used until you got different results than you were expecting. However, if you changed the Availability setting to Blocked for the replaced activity, then if there were unchanged references to that Activity in other places in the system, you would see errors when they were called and know that more changes were required. The Availability option guarantees that the system will not accidentally use a decommissioned rule.

The valid values for Availability are:

  • Yes
  • No
  • Blocked
  • Final
  • Withdrawn

For more information about changing the Availability values, see How to change the Availability option on a rule.


If the Availability of a rule is marked as Yes, then that rule may be used for all processing: work, editing, saving, and so on. You may copy and save this rule into any open RuleSet.


Use the Availability value of Final to indicate that this rule cannot be changed, except in a different version of the same RuleSet. If the Final rule is in a locked RuleSet version, you can save the rule only into a later version of that RuleSet. The new version of the rule also has the Availability value of Final.

You can use the "Save As" option to copy a Final rule into any RuleSet if you change the rule name. With a different name, the rule is treated as a completely different rule under rule resolution, and does not override the original rule. For example, the Final rule “Display” can be saved as “DisplayInvoice.” When rule resolution looks for activities named “Display,” it does not find “DisplayInvoice.”

For the purposes of rule resolution, the Availability value of Final is equivalent to the value of Yes.


When a rule is marked No/Draft, the system treats it as though it does not exist; the system ignores the rule and uses other rules. The Not Available label applies to one rule only. When the system gathers all the rules to consider for a rule resolution, any rule marked Not Available is simply discarded.

This availability is sometimes referred to as the “draft” availability, because it can be used to test rules before they are put into production. You can create a copy of a rule that you want to change, make the change, and set the availability to “No/Draft” in the main system, so that the system will ignore that rule. You can then check out the rule into your personal RuleSet and change the Availability to “Yes” to test your change locally. This testing allows you to verify that the rule displays the behavior you want, before you set the Availability of the changed rule to “Yes” for all users.

In the following example, an activity called Displayis defined on classes at several levels in the database:

  • Acme-Auto-ClaimsEntry-Accident
  • Acme-Auto-ClaimsEntry.DISPLAY
  • Acme-Auto
  • Acme-.DISPLAY

In the course of normal rule resolution, if the system needs the activity Display on the class Acme-Auto-ClaimsEntry-Accident, it searches that class first, and then the other three in the order listed. It will find the Display activity that is defined on Acme-Auto-ClaimsEntry and use that one.

  • Acme-Auto-ClaimsEntry-Accident
  • Acme-Auto-ClaimsEntry.DISPLAY (chosen rule)

If the Display activity on the class Acme-Auto-ClaimsEntry is set to have availability of No/Draft , the rule resolution process will just flow around it, and the Display activity defined on Acme- will still be used.

  • Acme-Auto-ClaimsEntry-Accident
  • Acme-Auto-ClaimsEntry.DISPLAY NOT AVAILABLE
  • Acme-Auto-
  • Acme-.DISPLAY (chosen rule)


Unlike rules marked “No,” rules marked Blocked are still considered by rule resolution. If the rule resolution process completes, and the one rule that is the final result of that process is marked Blocked, the process returns “not found.”

You can think of Blocked as blocking not just the rule, but the process. Because it will give an error at the end of processing and stop the requestor, it is not an optimal solution, but a rule can be changed immediately to take care of a crisis, and then a smoother handling of the situation can be implemented later.

For example, a tornado could not only temporarily shut down an airport, but could render it unusable for unknown period of time. The airlines would need to stop selling tickets or printing boarding passes immediately to and from that destination.

If the airlines were using a Process Commander application, they could just block the appropriate rules; many errors would be thrown, but the processes would stop, and no tickets would be sold in error. After the situation became clearer, and the airlines knew when the airport would be back in service, the rules of the application could be rewritten to gracefully handle not selling tickets during the out-of-service period (instead of throwing an error and stopping the process), and then process normally any requests for after the out-of-service period.

Using the example from the previous section, the rule resolution would function as follows:

  • Acme-Auto-ClaimsEntry-Accident
  • Acme-Auto-ClaimsEntry.DISPLAY BLOCKED
  • Acme-Auto
  • Acme-.DISPLAY

Because Acme-Auto-ClaimsEntry.DISPLAY is the most accurate rule for the purpose, it will be chosen; but because it is marked BLOCKED, the process stops and returns “not found.” The system does not continue to look at additional rules and does not find the DISPLAY that is defined on the Acme- class.

It is possible to block a circumstance-qualified rule. For example, suppose a rule was circumstanced by the CustomerStatus property, with values of Gold, Silver, and “Bronze.” A problem arose with the Gold rule (the discount was specified at 100% instead of 10%!), so processing of the Gold customers needed to stop immediately. The company could simply change the rule, but would not know how many incorrectly discounted orders were already in the system, so they wanted to highlight them quickly. The Gold circumstanced rule was changed to have the availability of Blocked.

In this case, processing for the Gold customers only would display the “not found” message. Other users, who would not use that particular qualified rule (CustomerStatus = “Bronze”), or the default with no Customer Status value, are not affected.

For more information, see How to block a rule

Blocked versus No

When the system is determining which rule to use, the Availability values of BLOCKED versus NO will change what rule is chosen.

If there were two versions of the activity DISPLAY:

  • Acme-.DISPLAY AcmeCo:05-02
  • Acme-.DISPLAY AcmeCo:05-01

if the 05-02 version of the rule were set to NO, the system would use the 05-01 version. If the 05-02 version of the rule were set to BLOCKED, the system would not use the 05-01 version, but would return the message “not found.”


Occasionally, you need to delete a rule from an application. If the incorrect rule is stored in an unlocked RuleSet version, you can easily delete it. However, if the application has been moved to other systems or the rule is in a locked RuleSet version, it is no longer possible to change or delete that rule. Instead, you can withdraw the rule.

The following are the most common situations in which a withdrawn rule is useful:

  • You created a rule in a more specific RuleSet that overrode a rule in a base RuleSet, because the rule in the base RuleSet did not have the functionality that you wanted. (Example: You saved a rule from the Pega-RULES RuleSet into your AcmeBank RuleSet.) However, a later release of the base RuleSet has the functionality that you want, making the rule in your specific RuleSet no longer necessary. (The next release of Process Commander had the functionality that AcmeBank wanted, so you no longer need to override it in the AcmeBank RuleSet.)
  • You created a rule in an incorrect RuleSet, and must define it in a less specific (“lower”) RuleSet. (Example: You created a rule in the RuleSet AcmeBankMortgage, which is built on top of the RuleSet AcmeBank. You realize that the rule should have been created in the AcmeBank RuleSet, so that rule can be used by both the AcmeBankMortgage application and the AcmeBank CreditCard application.)
  • You created a rule in an incorrect class, and must define it in a less specific (“higher” in the hierarchy) class. Example: You created a rule in PegaSample-Task, and you now realize that it should be created in PegaSample (so that other classes under PegaSample – besides Task - may use it.)
  • You must remove one circumstanced rule. Example: You created a rule that includes a circumstanced version for states. Not all the states have specific versions, but you have at least 20 circumstanced versions of this rule. The “NY” version of the rule should be removed; in order to do this prior to the withdrawn functionality, the rule would have to be copied to a higher RuleSet, and all of the circumstanced versions except “NY” would also have to be moved.

If the Availability of a rule is set to Withdrawn, those rules are removed from consideration during rule resolution.

For information about creating a Withdrawn rule, see How to delete or move a rule by creating a Withdrawn rule.

Related topics

How to block a rule

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. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us