Building Expressions in Strategy Crafter
Expressions are used in several NBA elements to determine at run-time which propositions should be allowed to flow through.
You can build expressions one of two ways:
- Formula Mode provides a text box into which you can enter any expression that the Salesforce formula engine is capable of processing.
- Builder Mode provides a point-and-click way to assemble an expression with a minimum of manual entry.
To understand expressions in NBA you need to understand the concept of context records. The context record for a particular execution of a strategy depends on where the execution request came from. If the request came from an NBA Component sitting on a Case record page, then the context record will be that particular Case. If the request comes from a self-serve Community portal page, the context record will be the User that’s logged in. When consumers of NBA recommendations send an execution request to the Strategy Engine, they provide a context record Id.
When you’re configuring an NBA strategy (sometimes referred to as “Config Mode” or “Design Time”), your design something that might get hundreds of different unique recordId’s passed into it. So you need a placeholder that will represent those different values. These placeholders are referred to as global resources and are expressed with a dollar sign. “$Record” is the placeholder representing the actual recordId that will be passed in at Run Time.
There are other global resources that you can use:
$User is the current user logged into the session that generated the execution request
$Request contains any arguments that were passed in with the execution request.
Expressing Field Values
You can span from a global resource to its fields like this:
$Record.mycustomerfield__c
Expressing Relationships
You can span across relationships up to 5 levels like this:
$Record.Contact.FirstName
Creating Expressions in Builder Mode
In Builder Mode, you can start an expression from any available global resource:
Understanding “Object Lock-In”
Consider the expression above ($Record.Contact.FirstName). This will work if the recordId passed in at run-time has a relationship to Contact, so you could use this expression in a strategy intended for generating recommendations for a Case page, because Case objects have a built-in relationship to Contact objects. The expression would resolve at runtime into Case.Contact.FirstName.
However, suppose you took that same strategy and called it from an NBA Component that had been placed on a Contact page? In that case the expression would attempt to resolve as Contact.Contact.FirstName. That doesn’t work because Contacts don’t have relationships to Contacts, so an error will be generated.
What this demonstrates is that most strategies are crafted to ‘fit’ a particular object-type. We refer to that as Object Lock-in. One of the most common sources of errors comes when someone attempts to use a Strategy from a page that isn’t a fit for that strategy’s expressions.
Using AutoComplete in Builder Mode
The Builder Mode of Strategy Crafter can provide you with a list of fields to choose from. However, Strategy Crafter can’t read your mind and doesn’t know from which record pages you intend to call this strategy. To give Strategy Crafter the necessary hint, you can use the “Autocomplete assumes incoming record…” drop-down to pick the object around which you want to design your strategy.
The value of this drop-down has no direct impact on your strategy. It only effects which fields will pop up in the expression builder when you start to create an expression.
If you change this setting on an existing strategy, it will not change any of the existing expressions.
