Skip to Content
Technical Articles
Author's profile photo Angela Pullano

Using Business Rules to Set Field Visibility & Required Attributes


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.



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



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.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ashmita Jaiswal
      Ashmita Jaiswal

      Hi Angella,

      I have a doubt.

      I want to write on view rule for notice period end date in employment details. When i ma writing it with If condition of Legal Entity, the rule is not bringing value in Notice period end date. but whne I am removing Legal Entity from if condition, it does bring value.

      Is it like for on view rules, we cannot put or restrict based on Legal entities? Any idea


      Appreciate your revert


      Author's profile photo Angela Pullano
      Angela Pullano

      Hi Ashmita,

      I have not had any issues with using Legal Entity as a condition.  Since your rule is triggering and returning a value without it, I would try a different navigation path/selection for where it is pulling the legal entity value from.  Looking at a rule trace should help you troubleshoot this issue.

      Best regards,


      Author's profile photo Adrian Miners
      Adrian Miners

      Terrific blog. Thank you.

      Author's profile photo Mauro Borghesi
      Mauro Borghesi

      Hi Angela,

      thank you very much for this blog post, very interesting and well written!

      I have a question: is it possible to design the experience through more rules? Let me explain my example: I want to keep a field (field A) hidden unless another one (field B) is filled in (quite similar to the one about SubTermination Reasons). Thus I created two rules to hide/unhide field A depending on field B content, one for the entire section (which is Compensation Information Model) with trigger "onView"; the other on field B, with trigger "onChange" so that field A appears and disappears as there is or there is no content on field B. Although, these two rules seem to cancel each other: when I turn down the former, the latter is working correctly; yet, as long as I don't change field B content, field A is shown all along. I tried to understand this weird behavior using Business Rule Log, but it says appearance is working correctly (although I can ensure you it is not 🙂 ).

      Do you think there can be misconfigurations already from my description?

      Thanks a lot,


      Author's profile photo Miruna-Maria Gheorghiu-Auratei
      Miruna-Maria Gheorghiu-Auratei

      Hi ,

      I am having the same issue and found this KBA, it seems OnView cancels OnChange rules. If anybody has found a work around that would be very helpful.

      KBA found: 2507511 - Field visibility using an onView rule does not switch immediately - SAP ONE Support Launchpad


      Author's profile photo Mauro Borghesi
      Mauro Borghesi

      Hi Miruna,

      thank you for looking into this case!

      I actually opened a case to SAP directly (20692 / 2023) and I got that it's actually not allowed: KBA actually leave little room for doubt 🙂 OnView rules do not switch automatically in the same transaction when there is a change...

      Author's profile photo Tanya Monteiro
      Tanya Monteiro

      Hi - Thanks for the above. This is helpful. Do we know why SAP does not recommend required & visibility SET clauses to be put in the same rule? Having a separate rule for each of these functions is a burden from a maintenance perspective - particularly for some of our clients who have very complex setups & many rules in the system which change these attributes. With the latest release we are finding that in some cases rules where we set both no longer work at all, but in other cases we do the same thing & it works fine.