Human Capital Management Blog Posts by Members
Explore blogs from customers or SAP partners to gain best practices and fresh insights to succeed.
cancel
Showing results for 
Search instead for 
Did you mean: 
StephanieBM01
Participant
1,029

(or Restricting MDF Values in Drop-down Based on Target Population)

Ouf! What a complicated title for my first blog of the year. Don’t worry though, the functionality itself is much simpler than the name of this post and understanding it helps solve a requirement that is quite common.

Common use case: Can you hide the “Check” payment method value in the payment information portlet for population X?

Yes, it is possible! Again, I’ll use my favorite portlet (Payment Information 😄!) for illustrating the solution, but keep in mind that this solution is not limited to Payment Information. It applies to any Generic Object (GO) field on an MDF object, as long as the MDF object is secured via RBP.

Default Behavior

But, before I tell you the solution (it is really a quick fix!), let’s understand the usual default behavior:

 

Let’s look at the Payment Method field in the Payment Information portlet. It is a Generic Object field type.

As shown, no explicit permission is required on the Payment Method object for its values to appear in the field drop-down, they are visible by default. However, if you click on the object Quick Card, you’ll receive an error indicating that you are not authorized to view the Payment Method details.

StephanieBM01_0-1768055866730.png

Once you grant View permission on the Payment Method object, users can click the Quick Card and view the related Payment Method information.

StephanieBM01_1-1768055866742.png

Finally, if you restrict the Payment Method object using target criteria in the permission role assignment (after granting View permission), users will still see all the values possible in the drop-down but only be able to access the Quick Card for the Payment Methods that match the defined criteria.

 

StephanieBM01_3-1768055866759.png

So, what’s the solution?

It actually comes down to flipping a single switch in Provisioning, one that isn’t widely known (hence this blog). The setting is called “Enable RBP Target Criteria for Value Help (Only with data type: Generic Object)”. Once enabled, it unlocks the ability to filter Generic Object in drop-down fields.

 

If you turn on the switch in provisioning: Enable RBP Target Criteria for Value Help (Only with data type: Generic Object)

By default, if you do not have View permission on the object, the field will display “No Data.”

StephanieBM01_6-1768055889455.png

Granting View permission to Payment Method object provides access to all available drop-down values. Users can also click the Quick Card to view the related Payment Method details.

StephanieBM01_7-1768055889466.png

Finally, if you restrict the Payment Method object using target criteria in the permission role assignment (after granting View permission), users will only see the values defined in the restrict criteria!

Solving our requirements!

 

StephanieBM01_9-1768055889479.png

 

Implication

The considerations outlined mainly apply to already‑live systems. In those environments, historical RBP configurations may have been built around the previous behavior—where values appeared in drop‑down lists even without explicit View permission on the target object. So, if you are already Live, enabling this setting does come with implications. If you’re considering turning this on in an existing environment, you’ll need to revisit and validate your current Role-Based Permission (RBP) configuration. In particular, make sure that any secured MDF objects used as fields in your active MDF objects are explicitly set to View. As shown earlier, when the switch is disabled, users can still see values in the drop-down even without View permission on the target object. However, once you enable “Enable RBP Target Criteria for Value Help”, the system starts enforcing RBP strictly and the drop-down will display No Data.

Second, enabling this switch requires granting View access at the object level. This has an additional side effect: users will now be able to click the Quick Card and view the details of the related object. If you do not want users to see all fields displayed in the Quick Card, you must further restrict access by configuring Field-Level Overrides. This allows you to expose only the necessary fields while keeping sensitive information hidden—even though object-level View permission is enabled. Here is how you come to hide the fields in Manage Permission Roles:

StephanieBM01_10-1768055889480.png

For a net-new (greenfield) implementation, enabling “Enable RBP Target Criteria for Value Help” from the outset generally poses no issue. However, it’s important to be aware that this approach may require more Field-Level Overrides than usual, which can translate into additional configuration effort. In greenfield projects, RBP is designed as an integral part of the implementation, making it easier to align permissions with the desired data visibility from day one. Because the permission model is built upfront, enabling this setting provides greater long-term flexibility - particularly the ability to control whether dropdown values are hidden or displayed for Generic field types on MDF objects as requirements evolve.

Conclusion

Small setting—big impact 😛

So, there is a simple way to hide Generic Object values in MDF drop-downs, and yes, it really does come down to a single switch in Provisioning called “Enable RBP Target Criteria for Value Help”.

For net-new projects, turning it on from the start is a solid and flexible approach for requirements (like the payment method one!). For existing systems, it may require some RBP alignment, but nothing unexpected now, you know what you need to do!

And if this blog saved you some troubleshooting time, don’t forget to leave a Kudo at the top — it’s always appreciated 😊

Stéphanie

1 Comment