Using rules in SAP Service Cloud – some practical examples

One of the nice features of SAP Cloud for Customer is that you can finetune the presentation of fields in the user interface by using rules or layouts. You can control whether a field is visible, mandatory and/or editable. When you have only a few business roles, layouts are usually the way to go. The strength of using rules shows when more complex requirements or exceptions need to be covered as well. In this blog I demonstrate a few examples I encountered which maybe save you some time while building your own rules for your project.

For a quick refresher on the usage of rules, see e.g. this earlier blog.

Case 1: Combining AND and OR

You can build complex requirements by combining functions and operators. General rule is to keep them as simple as possible, however this is not always feasible. A project example is where we wanted to make a (key user field) Closure Reason mandatory for a certain ticket type (Z001) and incident category (C_DLV) combination. Since the closure reason was only relevant at the moment of closure, we set up below rule, checking the ticket status Completed or Closed, and the mentioned other fields. If the user tries to change the ticket status to Completed (status =5) or Closed (status=6), the field is mandatory and must be filled before the ticket can be saved.
Resulting rule:

AND(
OR(Root.ServiceRequestUserLifeCycleStatusCode==”5″, Root.ServiceRequestUserLifeCycleStatusCode==”6″),
Root.ProcessingTypeCode==”Z001″,Root.ServiceIssueCategoryID==”C_DLV”
)

Case 2: Show/hide fields based on business roles using MYUSERROLES()

A field should only be visible for user(s) who have business role ZSALESREP assigned. Using the function MYUSERROLES() you can validate the user’s business role:
Rule: MYUSERROLES()==”ZSALESREP” results the value True, so field visible.
This works well as long as the user has a single business role assigned.
When a user has 2 roles assigned (e.g. role ZSALESREP and Z_SERVICE_AGENT), the function MYUSERROLES() returns the string “ZSALESREP,Z_SERVICE_AGENT” (sequence can vary), so the rule will fail and the field will remain hidden.
Solution here is to combine this with a CONTAINS() function:

Rule: CONTAINS(“ZSALESREP”, MYUSERROLES()).

This will result True, so the field will be visible as expected

You can combine this with other requirements in the same rule, e.g.

OR(Root.Conclusion_KUTfield==”231″,AND(Root.IncidentCategoryID==”C_CAT1″,OR(CONTAINS(“ZSALESREP”,MYUSERROLES()))

Case 3: Checking the value of indicator buttons

The value of an indicator button on the UI is No or Yes . Attempting to create a rule testing for Yes or No will always fail…. You need to test the field for the value 0 or 1 (or alternative False or True)

for example, test whether the  indicator has value “No”:

Root.ServiceExecutionRelevanceIndicator==0
Root.ServiceExecutionRelevanceIndicator==False
or even
NOT(Root.ServiceExecutionRelevanceIndicator)

Case 4: Make a field Read-only after first save of ticket

There are situations when you want to have a field filled in manually, however prevent it to be changed afterwards. In our example, the user needs to manually select the ticket service category (mandatory field). Since the subsequent processing is dependant on this field, we do want to prevent the user to change this afterwards. The field is therefore mandatory (done via the layouts), and (via  this rule) read-only after the first saving of the ticket – in our example only for ticket type Z001. We check the first save via the standard ticket field CreatedOn, which is empty until the first save of the ticket:

AND((Root.ProcessingTypeCode == “Z001”),NOT(ISBLANK(Root.CreatedOn)))

 

Case 5: Make a field visible only for a number of specific values

There are situations where you can use several ways to set up a rule, e.g. in our example where a field or section should be visible only when the IncidentCategory contains one of four specific values: IN-TP, IN-TR, OUT-TR, INCW-TP.

We could not use a more generic rule like Contains(“TR”) or alike since there were more categories with T, TR etc. So alternatives here are to use IF/OR/CASE statements:

For CASE, the logic is CASE(comparison 1, True or False, comparison 2, True or False, etc)
For IF, the logic is IF(logical_expression, value_if_true, value_if_false)
For OR, the logic OR(logical_expression1, logical_expression2, …))

A quick solution is

OR(Root.IncidentCategoryID==”IN-TP”,Root.IncidentCategoryID==”INCW-TP”,Root.IncidentCategoryID==”IN-TR”,Root.IncidentCategoryID==”OUT-TR”)

A more readable solution is to use the case statemen (remember: True/False is same as values 1/0):

CASE (Root.IncidentCategoryID==”IN-TP”,TRUE,
Root.IncidentCategoryID==”INCW-TP”,TRUE,
Root.IncidentCategoryID==”IN-TR”,1,
Root.IncidentCategoryID==”OUT-TR”,1)