home

Smart CPQ

Adobe Sign ServicesAdvantage Platform AdministrationAgreementsAiMeApprovals for Advantage PlatformApprovals for SalesforceBilling for Advantage PlatformBilling for SalesforceCLM for Advantage PlatformCLM for SalesforceContracts for SalesforceCollaborateComposer for Advantage PlatformComposer for SalesforceContractsConga for Google DocsConga Upgrade ProgramContract Intelligence (Standalone)Contribution Management SystemCPQ for Advantage PlatformCPQ for SalesforceDeal MaximizerDigital Commerce for Advantage PlatformDigital Commerce for SalesforceDiscovery for Advantage PlatformDiscovery AI for SalesforceDocusign ServiceseSignature Integration with Advantage PlatformGridInvoice GenerationMix FormsOrchestrateOrder Management for Advantage PlatformOrder Management for SalesforcePartner Commerce for Advantage PlatformPartner Commerce for SalesforcePrice ManagementPrice OptimizationPricing Solution SuiteQuote GenerationReal Time Pricing EngineSign for Advantage PlatformSign for SalesforceSmart CPQSmart SearchSubscriptionsTest AuthorTurboEnginesX-Author for Contracts 1.0 (Classic)X-Author for ContractsX-Author for Contracts Advanced for Advantage PlatformX-Author for Contracts Advanced for SalesforceX-Author for Excel for Advantage PlatformX-Author for Excel for SalesforceX-Author for Migration Manager for Advantage PlatformX-Author for Migration ManagerConga Tech Pubs PlaygroundRelease NotesGeneralDocs by Release
Adobe Sign ServicesAdvantage Platform AdministrationAgreementsAiMeApprovals for Advantage PlatformApprovals for SalesforceBilling for Advantage PlatformBilling for SalesforceCLM for Advantage PlatformCLM for SalesforceContracts for SalesforceCollaborateComposer for Advantage PlatformComposer for SalesforceContractsConga for Google DocsConga Upgrade ProgramContract Intelligence (Standalone)Contribution Management SystemCPQ for Advantage PlatformCPQ for SalesforceDeal MaximizerDigital Commerce for Advantage PlatformDigital Commerce for SalesforceDiscovery for Advantage PlatformDiscovery AI for SalesforceDocusign ServiceseSignature Integration with Advantage PlatformGridInvoice GenerationMix FormsOrchestrateOrder Management for Advantage PlatformOrder Management for SalesforcePartner Commerce for Advantage PlatformPartner Commerce for SalesforcePrice ManagementPrice OptimizationPricing Solution SuiteQuote GenerationReal Time Pricing EngineSign for Advantage PlatformSign for SalesforceSmart CPQSmart SearchSubscriptionsTest AuthorTurboEnginesX-Author for Contracts 1.0 (Classic)X-Author for ContractsX-Author for Contracts Advanced for Advantage PlatformX-Author for Contracts Advanced for SalesforceX-Author for Excel for Advantage PlatformX-Author for Excel for SalesforceX-Author for Migration Manager for Advantage PlatformX-Author for Migration ManagerConga Tech Pubs PlaygroundRelease NotesGeneralDocs by Release

Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.

Show Contents

Smart CPQ

Designer - Modeling Best Practices

BRC Loading Versus Execution

When creating BRC, the most important part of these BRC concerns “when they will be executed”. Basically, the execution of the BRC is dependent of some parameters:

  • The object or attribute to which it has been attached, and its position in the model
  • The objects referenced by the CPE, and their position in the model
  • The flag “autoload” on the BRC
  • The flag “MustExist” on each CPE
  • The flag “MustBeAnswered” on each CPE

Before exploring each of these topics, let’s have a look at a general model:



The influence of the point of attachment

When the CPQ Engine starts a configuration session, it will create a session and load a certain model.

information: The term model references a completely designed root Configuration Process which represents all possible instances that can be obtained by the business rules inside the model.

When the session is created, the Configurator (or another) user interface will call the CPQ Engine in order to load one or another part of the model.

information: The term loading refers to the process of reading a static part of the model in the Designer repository or cache, and creating an instance for that part of the model in memory for the currently started session.

Example:

Let’s suppose the following model:



A user interface starts a configuration for rootCP_A and loads the first level Configuration Processes, which allows the user to start browsing in the model. In this case, the part of the model loaded in the session can be represented as follows:



You can see that the loaded forms and Configuration Processes immediately influence the loaded BRC: all BRC attached to objects which are loaded will be loaded also; all BRC attached to unloaded objects will not be loaded.

Warning: In order to execute a BRC, it first has to be loaded.
information: Loading will be triggered by multiple mechanisms, and this will be done recursively:

The user interface will load objects when the user starts a configuration

The user interface will load objects when the user clicks on a certain Configuration Process or form in the configuration

The engine will generally automatically load objects by browsing all CPE inside the BRC attached to an object which is being loaded

Once an object has been loaded, it remains in memory and will not be loaded again.

The influence of the loading

By default, when a BRC is loaded, the CPQ Engine will automatically browse the CPE which are a part of that BRC. In order to give the most flexible behavior possible to the end user, it will automatically load any objects in the model which are referenced by the BRC (and which are not loaded yet).

If in the previous example, BRC_CP1 contains a CPE that references FO1, FO1 will be loaded automatically and the result in session will look like this:



Warning: In normal circumstances, a BRC will automatically load all objects references by its CPE. Please beware that in important models, this could load the complete model immediately because the loading is a recursive process.

The influence of the autoload flag

The previous paragraph mentioned that the loading of BRC will automatically load other parts of the model. In some important (meaning: big) models, this can have an impact on performances. Indeed, if a model has multiple levels, and many BRC, the loading mechanism can make that every object as well as every BRC is immediately loaded. For the end-user, this has an immediate and potentially visible impact: starting a configuration slows down. Therefore, an “autoload” flag has been added to BRC, which allows changing that behavior.

If the “autoload” flag is set to false, and if at least one of the CPE corresponds to an object which is not loaded, the BRC will be put in “standby”. Each time another object is loaded, either by the user interface or indirectly by another BRC, the CPQ Engine will check the BRC in “standby” and “activate” it again once all CPE in that BRC correspond to loaded objects.



Warning: In the case of very large and complex models, the recursive loading process could end up loading the complete model when the user starts the configuration. The end-user could perceive this as “waiting” for the configuration to initialize.

In order to shorten that initial configuration start time, it could be interesting to set the “autoload” flag to “FALSE” for certain BRC. This way, the loading mechanism will mainly be driven by the user interface instead of by the engine, and the “cumulative load time” will be spread over multiple clicks.

Warning: The “autoload” flag has to be set to “TRUE” for all BRC which involve at least one CPE including the nearest keyword.
Warning: As a BRC is put in stand-by, it will execute once it “wakes up” again. When this BRC executes, it could be that seemingly “valid” form properties become invalid merely because of the fact that not all BRC were executable at the time the user answered the associated question.

The influence of the “MustExist” flag

Once a BRC has been loaded and providing that it is active (meaning: not in standby), it can be executed. The execution of a BRC however will depend on the MustExist flag for each BRC.

In order to understand the notion of a “MustExist” flag, you first need to understand the difference between a loaded object and an object which exists.

An object is loaded if an instance of its static representation (meaning: model) has been created in memory.

The existence of an object is somewhat different. Remember, for objects such as Configuration Processes, forms and form properties, different “states” have been defined, such as “exist”, “visible”, “required”, “updateable” and “computed”. Each of these states is associated to a Boolean domain (TRUE or FALSE).

From a functional stand-point, an object exists if it is considered as being valid in the context of the current execution. From a theoretical stand-point, it exists if the domain of its “exist state” has been reduced to only one value: “TRUE”.

Let’s have a look at the following model:



In this model, BRC_FP22 will define the domain of form property FP22. The domain of form property FP22 depends on 3 form properties FP11, FP12 and FP21. As seen in the previous paragraphs, BRC_FP22 will not be executed before all necessary CPE have been loaded. However, as form

properties FP11, FP12 and FP21 are necessary to define the domain of FP22, it will also wait until all of these properties exist. This of course can be problematic, especially if the existence rule of one of these form properties indicates that it does not exist. At that point in time, BRC_FP22 would wait indefinitely, and this is of course not an acceptable solution.

The MustExist flag brings a solution to this: it enables you to indicate if the BRC has to keep on waiting until the associated object exists, or if it should ignore the associated column.

The execution of the BRC will thus be triggered when it is active (again: when every necessary object is loaded) and if for all CPE having the MustExist flag set to “TRUE”, the associated objects exist.

Warning: Carefully review the MustExist flag for all CPE in the BRC pointing to objects which have existence rules (meaning: these objects potentially don’t exist).

The influence of the “MustBeAnswered” flag

If all objects necessary for the BRC execution have been loaded in memory, the BRC is active. Moreover, if the MustExist flag has been correctly set up, it will be executable even though some objects do not exist in the current execution. However, what if a certain BRC needs exact input, for instance in order to do a calculation? In this case, the MustExist flag is not sufficient. Therefore, the MustBeAnswered flag has been added.

Before going into the MustBeAnswered flag, you first need to understand the different types of CPE. We have already explained the different possible expressions from a syntactical point of view (remember: absolute CPE, relative CPE, searching CPE). However, CPE can also be classified based on the source of the object or attribute they are referencing; we can distinguish user references, internal references and static references.

information: User references refer to the objects and/or attributes that allow a user to select or calculate a value related to a form property, or to input a value for a session variable. The associated CPE will typically be of the following form:
  • CPE…FP/aFormProperty.value
  • CPE…FP/aFormProperty.value.default
  • CPE…FP/aFormProperty.value.qty
  • CPE…FP/aFormProperty.value.comment
  • CPE.Settings.Session.aSessionVariable
    information: Internal references refer to the attributes that indicate if one or another object is usable in the context of the current execution and to which extend it is usable. The associated CPE will typically be of the following form:
  • CPE…object.state.exists
  • CPE…object.state.visible
  • CPE…object.state.mandatory
  • CPE…object.state.updateable
  • CPE…object.state.computed
    information: Static references refer to the objects and/or attributes that always have the same value in the context of the model execution (or for which the value is set only once and never changed during the model execution). A typical example is the value of a business property for a standard item:
  • CPE…SI/aStandardItem.BPS/aBPS.BP/aBusProperty.value

Now that you better understand this classification of CPE, we can go further into the MustBeAnswered flag: the CPQ Engine will only take into account this flag for user interaction CPE, and will allow to delay the execution of the BRC until the value of the corresponding attribute is considered as answered.

From a technical standpoint, being answered means that the associated domain has been reduced to only one value.

Warning: Carefully review the MustBeAnswered flag for all CPE in the BRC pointing to form properties which are optional (meaning: the user doesn’t necessarily have to give an answer to the associated questions).

Detailed overview of BRC execution

Now that you have seen all parameters that influence the BRC execution, the following table shows how the CPQ Engine puts things together:

CPE \ BRC AUTOLOAD BRC NON AUTOLOAD BRC
MustExist = TRUE MustExist = FALSE MustExist = TRUE | MustExist = FALSE
Loaded 1) Execute when exist 1) Execute if exists or execute partially if not exists 1) Execute when exists | Execute if exists or execute partially if not exists
Not loaded Autoload the CPE object Execute when exist Autoload the CPE object Execute if exists or execute partially if not exists Standby Wake up when CPE loaded Execute when exist | Standby Wake up when CPE loaded Execute if exists or execute partially if not exists
Not in the model Detection of model error BRC skipped Execute partially Standby forever | 1) Standby forever
User Guide

September 29, 2026