Field Value Usage and Configurations in Pega
In this blog article, we will see more in detail about field value rules.
What is a field value rule?
The name speaks, field value rule can be defined in 2 ways – Value for a field or caption for a field.
Field values can be used in many ways!
1. Restrict the selection of items. In other words, provides a set of values to users for selection (sourcing dropdown control)
2. Reusable labels (captions) or Reusable values.
3. Supports localization.
1. Restrict selection of items
Let me explain this with some sample (standard) rules provided by Pega
Here is my favourite quote from Will Smith about reading books.
“There is no new problem that someone hasn’t already had and written about it in a book”
It is all about how we find the right book :).
Why I am saying this is, Pega base product ‘PegaRules’ has a lot of rules which are worth taking a look at and learn how they built it.
So, now I am going to show you an already existing field value rule
Step 1: go to records -> Data model -> property. Filter the property name based on ‘pyTypeOfWork’
Step 2: Open the property ‘pyTypeOfWork’ of class ‘Work-‘
You can see the Table type – Field value & you can see the field value description referring the field value name ‘pyTypeOfWork’
Let’s check the field value rule
Step 3: Go to Records -> Data model -> Field value. Filter the field name based on ‘pyTypeOfWork’
You can see there were five field value rules created on the field name ‘pyTypeOfWork’.
It means the property ‘pyTypeOfWork’ can contain either of the 5 values (values can be restricted)
Every field value rule contains two key parts
1. Field Name – It can be a valid name to define a subset of values (eg. pyTypeOfWork, pyStatusWork)
2. Field Value – It defines the values for the field name (eg. All Unresolved Work)
A single field name can contain multiple field values.
Let’s test this.
Step 1: open any section and include the field ‘pyTypeOfWork’. Use dropdown control or ‘as defined on property’ option.
Step 2: Run the flow and check from the user portal.
Verified. It means you can restrict the selection of items or provide right set of values.
Field values are reusable components and the same field value (pyTypeOfWork) can be used as Table type in different properties 🙂
2. Reusable labels or values
Let’s see some of the standard field names before proceeding. (remember, I am talking about field names not field values)
a) pyCaption – This field name is used as labels for fields in the user work form.
Open the same section we used before and open any cell properties. You can see a field ‘Label’ used to set the label for the field customer name.
Label can accept any hardcoded value or a Field value rule.
If we want to use a field value rule, then we have a constraint like the eligible field value rules should come under the Field name pyCaption.
All the dropdown items (field value rules) belong to field name =’pycaption’
Note: There are lot of out of the box field value rules that’s comes under field name ‘pyCaption’
Let’s verify.
Open the ‘GridNoResultsOnLoad’ field value.
b) pyButtonLabel – This field name is used as a label for buttons.
Step 1: I am just including a button in my section to show you the pyButtonLabel.
Step 2: Open the button properties and elect button caption as Text and click on the down arrow, you will see all the eligible field values with field name =’pyButtonLabel’
Step 3: Open the field value =’<<Back’
Now you know the importance of field name.
So whenever you want to use field value inside cell properties or anywhere in a form, first check the dropdown list and know what are the eligible field names and then create a new field value rule accordingly.
Reusable VALUES
Till now you have seen field value rules used in the left-hand side of the form as labels or caption.
You can also use field value rule as right hand side values.
Assume you need to include some description in the UI. (maybe kind of one or more lines)
Step 1: Open any section rule form.
Step 2: Include label.
Step 3: Open the cell properties of the label and start entering the description ( actually you are hardcoding the description). Use more than 64 characters.
You can see Pega throws you a severe warning – the length exceeds 64 characters.
So here you need to create a new field value rule J instead of hardcoding
Note: Obviously you can create a new field value even though size do not exceeds 64 chars. It’s all about keeping reusability in mind
Finally, I am going to create a new field value rule.
How to create a new field value rule?
Step 1: Records -> Data model -> Field Value -> New
What should be the field name?
The key to deciding the field name
1. If you are going to use it in cell properties in user form, identify the eligible standard field name. ( eg: pyCaption, pyButtonLabel etc)
2. Else give some meaning field name, mostly the property name itself to which you will use this field value ( eg. pyStatusWork, pyTypeOfWork etc)
In our case, we are going to use it in cell properties, so identify the eligible standard field name 🙂
If you are confused about creating a new rule, remember Will Smith quotes 😉
Go the section -> Label cell properties -> Keep your focus on the field and click down arrow to view the list.
Now open any field value name, Say GridNoResultsOnLoad. We knew already it is field name ‘pyCaption’
Now it’s evident that we need to create a new field value with field name ‘pyCaption’
Note: Field name in the create form also accept property name as shown below.
In our case, specify it as pyCaption and create.
Step 2: You will see the field value rule created with 2 keys
Field name
Field value (Rule name / Identifier)
You will also see Translate from and Translate To
This opens the way for localization or language pack.
What is localization?
For example: Lets’s take Mercedes Benz. They have different branches operating in different countries. They use Pega application to service the customer.
Assume three countries – India, China and Germany. India – English; Germany – German; China – Chinese.
The employees or CSRs are mostly local people and are good in their local language.
The application functionality should be exactly the same for all 3 countries
Now how will you build an application that can be used by those different countries?
Use localization packs
Note: The generic answer for the above question is to use Implementation layers for different regions 🙂
What are the rule types that support localization?
- Field value
- Message
You can build your application in the English language and use the language packs.
Language packs are nothing but an overriding ruleset where you can override the field value rules or message rules with localized (translated values). At run time, this language ruleset will come in the top of ruleset hierarchy and get picked by rule resolution.
In our example, we don’t use any translation or language pack, so I just used the English text in To field.
If you want to use an chinese version, save the rule in some dedicated language ruleset (higher in the ruleset hierarchy) and override the To value
Note: The translation pack rulesets always ends with _<language code> For dutch it will be AmazonSa_NL
Credits: google translation
There are some other standard rules that support localization based on field values
They can be used to get the translated version of field value rule.
a) Activity – GetLocalizedTextForString
b) Functions
getLocalizedValue() – in pegaRules string library.
getLocalizedText() – in pegaRules utilities library.
c) Control rule – GetLocalizedValue
How to use parameters in Field value?
Field value rules support parameters.
You can specify more than one parameter.
Parameter values can be dynamically referenced in the Translated To field.
How to test parameters in field value rule?
Step 1: Add a new parameter – NoOfChar
Step 2: Place the parameter order (in our case 1) within the field value To message.
Step 3: Include the field value inside the section label and specify the parameter value.
Step 4: save and create a new case to check from the user portal.
You can see the parameters are passed dynamically.
The field value message also supports dynamic property references.
For example, we can dynamically refer to the case ID within the field value.
We know ‘pyID’ stores the case ID value.
Update the field value as shown below. Refer .pyID dynamically within the curly braces.
Now again go to user portal and create a new case.
You will see the case ID is passed dynamically.
We are at the end of the field value article
