Using Business Rules to Set Field Visibility & Required Attributes

Overview

Using business rules and role-based permissions to modify the visibility and required attributes of a field in Employee Central is a useful way for system admins and implementation partners to greatly improve the end user’s experience.  The universal design principle focused on in this post is to minimize unnecessary complexity and cognitive load.

For Employee Central, this means that fields should be removed or hidden from the end-user’s view when possible.  If the field is not relevant to the end-user – hide it.  Alternatively, if the field needs to be visible for functionality to work, but the user shouldn’t be editing it (i.e. it is set automatically by other rules) – make sure it is view-only.

In this article, I will present some examples of the use of business rules to set field visibility & required attributes to give users a simplified, easy to use experience, and the feeling of responsive interface by using progressive disclosure as fields only appear when relevant.

How

In business rules, field visibility and required attributes are set by using a text value.  (I’m not sure why SF doesn’t automatically restrict business rules attribute settings by only providing valid options to select from, but this is how it functions today).

screenshot of business rules showing setting of Visibility and Required attributes

Required is actually a boolean, so the valid text values to enter are: true, false

Visibility is tricky – the valid text values to enter are: none, view, or both

none = hidden

view = view-only

both = visible and editable

The fields you want to manipulate must be enabled in BCUI the Visibility should be set to Edit in the field details.

Depending on what makes the most sense for the scenario I may have the required (Mandatory) attribute default to Yes or No.

bcui enabled and required setting

bcui field details Visibility settings

Rule Logic

What the rule logic needs to encompass will depend on the entity(s) the field is located in, and the assignment scenario.

For example, if a rule is assigned as an “on view”  or “on initialize” event type, you can just set the field attributes once.

However, if the rule is assigned as on “on change” event type and the logic varies with the selections made by the user, you must make sure that your rule logic encompasses the reverting of the attributes back and forth as necessary.  This will make more sense with an example use case.

Example Use Case

At implementation, my company had the standard termination event reasons (Voluntary Termination & Voluntary Termination)  and sub-reasons configured for each of these event types.

However, after being live on Employee Central for about a year, the business wished to capture more specific reasons for some of these sub-reasons (Resignation with Notice, Termination with Cause, etc.).

Therefore, sub-sub-termination reasons were created.  But not ALL sub-reasons have associated sub-sub-reasons.  We wanted to make it required for the user to make a selection if the event had a sub-sub-reason and to hide and make non-required the field if the event did not have any associated sub-sub reasons.

We wanted to ensure that it would not be possible for users to miss making a selection when they should.  We also wanted to ensure we would not confuse and/or frustrate users by presenting a field with no options available when they didn’t need to make a selection.

(Note: we also renamed the termination field reason labels to Termination Reason Group, Termination Reason, and SubTermination Reason)

Entity:  employmentInfo

Where Assigned: as onChange rule to the Termination Reason field.

rule is assigned on Termination Reason field in employmentInfo entity

onChange rule assignment

Business Rule: when Termination Event Reason is changed, the rule makes the SubTermination field required and editable or non-required and hidden, based on event reason selection.

Initial View (before any user selection):  field is visible and non-required as configured in BCUI

SubTermination field is visible and not required

User selects Termination Reason that has associated sub-reasons:  field is required and editable

SubTermination field is Required

User selects Termination Reason with no associated sub-reasons: field is hidden and not required

SubTermination field is hidden

Use-case design consideration:  because users may select multiple reasons before deciding on one, it is important that the rule be able to successfully update the Visibility & Required attribute, regardless of the field’s previous setting.

For term reasons with sub-reasons, set visibility to both and required to true. All others set visibility to none and required to false.

Please note that SAP support will recommend that you write two separate rules and to not have one rule change both Visibility and Required attributes.  While this rule works for us, your mileage may vary, so be sure to test thoroughly!

Additional Considerations

• Multiple rules may be necessary depending on the entity(s) involved and system behavior based on where/how the user initiates the action.  For example, rules to set CompInfo fields based on Pay Component Type will need to be created for CompInfo, Recurring Pay Component, and JobInfo entities.  These additional rules need to be created using the corresponding base entity model.

• Modify field visibility in the permission role as best practice before modifying with a business rule.  Most use-cases of making fields view-only or hidden are best handled with RBP before resorting to business rules.

• RBP settings that apply to view/change on employee data do not apply to the Hire Wizard.  Use a onInit rule saved to the entity to make enabled fields hidden or view-only.

• When a rule doesn’t appear to work – use a rule trace to confirm that the rule is actually being triggered.  If it isn’t being triggered, you will need to get creative on how to apply an alternative.  Not all rule assignment types are supported in all locations in bcui.  Sometimes it is triggered only when a transaction is entered in one way, but not another.

RBP Field Permissions Example

Before:  Users saw all fields as editable, even though we have position management.  This resulted in the interface being unnecessarily complex for users, and data integrity issues as the system allowed them to over-write data that the employee should be inheriting from the position in our configuration. (If you are an implementation partner for a customer using position management – it should be standard practice to modify the visibility of these fields to view-only!).

Old View of Job Info – all fields are wide open for users to edit

After:  Users are not able to over-write any job info fields that inherit position data.  They are only able to change the position number, and the other fields will update.  Users can confirm they made the correct choice as the fields are set to view.  This forces users to go to the Position Org Chart or Manage Positions to update organizational & job code data before initiating an employee transaction. (We do not have position to jobInfo sync enabled).  Some fields are completely hidden.

New View of Job Info – all fields inheriting position data are view-only or hidden

Business Rule for Hire Wizard Example

Likewise, all the fields in Job Info that are view-only in change transactions are also set to view-only in the Hire Wizard using an onInit business rule assigned on the jobInfo entity.

onInit rule that sets multiple fields to view in the Hire Wizard

Conclusion

Take a moment to think about your Employee Central users experience.  Is there anything that you can do to help make it more intuitive and easier to use?  Are there data integrity issues due to user errors that you could eliminate by simply making fields view-only or hidden?

I hope this article has been helpful!  Please let me know in the comments if there is a topic you’d like more information on and I will try to cover in a future post.