![]() Multiple rules may be necessary depending on the entity(s) involved and system behavior based on where/how the user initiates the action.While this rule works for us, your mileage may vary, so be sure to test thoroughly! 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. All others set visibility to none and required to false. 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.įor term reasons with sub-reasons, set visibility to both and required to true. User selects Termination Reason with no associated sub-reasons: field is hidden and not required User selects Termination Reason that has associated sub-reasons: field is required and editable SubTermination field is visible and not required Initial View (before any user selection): field is visible and non-required as configured in BCUI Rule is assigned on Termination Reason field in employmentInfo entityīusiness 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. Where Assigned: as onChange rule to the Termination Reason field. ![]() (Note: we also renamed the termination field reason labels to Termination Reason Group, Termination Reason, and SubTermination Reason) 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. ![]() We wanted to ensure that it would not be possible for users to miss making a selection when they should. 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. But not ALL sub-reasons have associated sub-sub-reasons. Therefore, sub-sub-termination reasons were created. 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.). This will make more sense with an example use case.Īt implementation, my company had the standard termination event reasons ( Voluntary Termination & Voluntary Termination) and sub-reasons configured for each of these event types. 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. What the rule logic needs to encompass will depend on the entity(s) the field is located in, and the assignment scenario.įor example, if a rule is assigned as an “on view” or “on initialize” event type, you can just set the field attributes once. The fields you want to manipulate must be enabled in BCUI the Visibility should be set to Edit in the field details.ĭepending on what makes the most sense for the scenario I may have the required (Mandatory) attribute default to Yes or No. Visibility is tricky – the valid text values to enter are: none, view, or both ![]() Required is actually a boolean, so the valid text values to enter are: true, false Screenshot of business rules showing setting of Visibility and Required attributes (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). In business rules, field visibility and required attributes are set by using a text value. 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. it is set automatically by other rules) – make sure it is view-only. Alternatively, if the field needs to be visible for functionality to work, but the user shouldn’t be editing it (i.e. If the field is not relevant to the end-user – hide it. The universal design principle focused on in this post is to minimize unnecessary complexity and cognitive load.įor Employee Central, this means that fields should be removed or hidden from the end-user’s view when possible. 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |