Skip to Content
Author's profile photo Marty McCormick

How To Customize UWL Substitution People Picker Search Results


Frequently, a SAP Portal implementation has a requirement to restrict the search results for users in the substitution component of UWL.  This screen, also known as the “people picker”, is where users can select someone to receive and act on work items on behalf of them.  The substitution rules are not only relevant for portal but also replicated to backend systems connected to the UWL.  By default, the UWL pulls all users from the portal User Management Engine (UME) even if you are using custom UWL configurations to restrict connectors by role.  Given that the UME is often hooked up to a company Corporate LDAP (i.e., Active Directory) and also likely contains non-portal users this standard configuration may not be ideal.  For example, there are often more users in LDAP than the connected backend SAP systems and a project may not want users delegating to non-portal users or even seeing them in the list of selectable substitutes.  For example, as shown below in Figure 1 a restricted list of only certain users can be shown in substitution screen.

 UWL People Pikcer

Figure 1: UWL People Picker Screen Sample Screen Shot

The people picker is a vital piece to UWL substitution functionality.  This technical white paper will outline new capabilities delivered in SAP NetWeaver 7.0 Enhancement Pack (EhP1) that allow you to restrict the people picker search results list by certain user attributes that are common to unique sets of users.

SAP Documentation

The SAP Documentation refers to this functionality as “Differentiating User Data Display in External Portals” and the scope of the functionality is much broader than simply restricting UWL substitution.  You can read more about the new functionality on using the following direct link:

Scenario Prerequisites/Restrictions

In order to implement this solution there is a prerequisite that SAP KMC must be installed on system together with UWL. This is because the UWL uses two different people pickers underneath the covers.  When KMC is installed together with UWL, the KM people picker is used. If the KMC is not present on the system, internal UWL people picker is used.    KM People picker does have the described functionality in this document and the UWL people picker which does not.   If you have installed the usage type EP then you will have the KM People Picker.  Usage type EPC has UWL people picker.  

Sample Scenario Description

There are many variations that present a unique set of requirements to restrict the users shown in the people picker ranging from portal company membership to organizational attributes stored on the user account such as department code.  In this document, we’ll outline a fictional scenario whereby the portal is using a company based concept (users are grouped into separate companies) and the UWL is hooked up to multiple backend SAP clients which are unique to each company.  In standard, the UWL people picker would show all users from UME, which means CompanyA users would see CompanyB users and vice versa.  The scenario is simple but outlines the fundamental concepts. 

The fictional requirement that needs to be met is that only users from CompanyA should be shown when substitution is performed by a CompanyA user.

Portal Companies

When using portal companies, you can configure the UME in such a way that each company is represented by a virtual group in the UME.  Therefore, all users of Company A also belong to virtual group CompanyA even though there is not an explicit assignment by a security adminsitrator.  It is this distinguishing factor that we’ll use to implement our restricted people picker scenario.  As shown in Figure 2, CompanyA has Virtual group V_CompanyA with 3 members.

 Users of Companies

Figure 2: Users of CompanyA

However, as outlined in the documentation, any UME attribute can be used to restrict the people picker display but the users company attribute is chosen in this case.  Since a user can only belong to one company, there are no tiered delegation or parent/child relationships.  The UWL user will only see users from his company.

Standard Functionality

In our scenario, we’ll look at fictional user “deleuser” who belongs to CompanyA and is assigned a standard user and sample delegated administration role (Figure 3).  If you are familiar with delegated user administration screens, you already know that deleuser can only see users from his company, such delegated Administrator and deleuser2.  However, when deleuser tries to perform substitution, he can see users from outside his company in standard configuration. 


Figure 3: Roles for fictional user deleuser

As shown in Figure 3, when searching for Administrator deleuser is shown the default Administrator user in addition to his delegated administrator user from his company.  Most likely this is not a desired behavior as deleuser should only delegate to Delegated Administrator, who also belongs to his company.  For example, s shown in Figure 6, when searching for Administrator deleuser is shown the default Administrator user in addition to his delegated administrator user from his company.  Most likely this is not a desired behavior as deleuser should only delegate to Delegated Administrator, who also belongs to his company.

Manage Substitution Menu

Figure 4: UWL Manage Substitution Menu

Manage Substitution Rules

Figure 5: Manage Substitution Rules

Search Result in Standard

Figure 6: Search Result in Standard

System Configuration for Company Group Scenario

Since we are using a company based concept, the configuration necessary is minimal and not relevant to overall document purpose but outlined here for completeness.  In fact, if you are already using a trading partner (tpd) you most likely already have this step completed.  As outlined in Figure 7 below, we have configured three fictional companies in property com.tpd.companies: CompanyA;CompanyB;CompanyC and set the ume.tpd.prefix to be “V_”.  These properties can be found in the J2EE Config Tool under Global Server–>Services–>

Properties for UME Companies

Figure 7: Properties for UME Companies

Implementing UWL People Picker Restricted Functionality

This section is really the purpose of this how to guide and addresses how you can implement the restricted search results functionality.  Note that the following configuration steps assume that your user id has at least System Administrator role in portal.

Navigate to System Administration–>System Configuration–>Knowledge Management –> Content Management.  Select Repository Managers.

Select Mode–>Advanced Mode

Under Related Areas section, select UME Object Settings.

Related Areas

Figure 10: Related Areas of KM Repository Managers

Next, Select External Facing Extension link

UME Object Settings

Figure 11: UME Object Settings

Check the checkbox to activate the Extension for user data display in external portals.

Extensions for user display

Figure 12: Extension for user data display

After saving, under UME Object settings, select the Trusted Attributes link (shown in Figure 11)

Create a new Trusted Attributes setting.  In our scenario, we only want to show users who belong to same company.  Set the active and passive attributes to Company.  This will set the people picker to show only those users to end user for substitution who belong to same company.

Trusted Attributes

Figure 13: Trusted Attributes Settings

Create Roles and Assign Appropriate Actions

In order to prevent the disabling of the search functionality as shown in Figure 15 for those users not assigned to a company or your attribute, you will need to create two roles and assign to users and contain J2EE actions.

  1. Create a role Employee_Company (this provides an Unrestricted view) and assign actions:




  1. Create a role Trusted_External  (this will provide restricted view) and assign actions:




That is all we need to do.  We should now be set to test!

Initial Scenario Revisited with Enhanced Functionality

As shown in Figure 14, when deleuser navigates back to substitution screen and searches for Administrator, only the Administrator user from his company is shown (not J2EE Administrator).

Restricted SearchRestricted Search

Figure 14: Restricted People Picker Search


Overall, the new functionality to restrict user display in KM and Collaboration screens, specifically UWL substitution is a great feature for SAP customers.  By leveraging this feature you can segregate users by UME attributes and improve the overall security, usability and design of your portal.

Troubleshooting Tips

In order to avoid the disabling of the Search button for your unrestricted users, you need to implement the roles and assign the correct UME actions outlined in the last step for configuration above.  The screen shot is shown here as a tip in case it happens to you.  Once activated, the changes are across the board for all portal users.  For example, in our scenario if we had users that didn’t belong to a portal company but used the same portal for UWL they would not be able to select any substitutes as shown in Figure 15.  This can be eliminated by assigning the actions above to users.

Unintended Consequences

Figure 15: UWL Substitution Disabled for non Company Users

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      This is an excellent, detailed blog. I have come across this requirements to restrict several times.

      Question: What happens if a user from company A manually attempts to setup user from company B as a substitute without using 'people clicker'? Would this setup stop user from Company A from doing so?

      I know one way to achieve this is to implement UWL BADI in the backend. But if this configuration/setup can achieve this without coding, its great.

      Author's profile photo Former Member
      Former Member

      We have multiple backend systems that use UWL.

      For eg , MSS , SRM users.

      When SRM users in portal try to assign a substitute , we would like to see only SRM users and same with MSS users. If he is both MSS and SRM user , he should be able to see both users.

      The description in the blog was little confusing around the Trusted attributes assignment.

      can you please explain.


      Author's profile photo Ashish Shah
      Ashish Shah


      I was able to configure UME attributes as per your suggestions.

      We have enabled company concept in Config tool.

      We have done necessary configuration in System admin for user attributes

      We hav also assigned the necessary actions to the users.

      When one of the user in Company A tries to search for substitues , user is unable to see first name and last name of the available substitues.

      In this example user "Dethe " is able to see all available three options in subsitution , however their first names and last names are not displayed properly.

      For snapshot , please see this link :

      Can you please suggest any solution to this?


      Ashish Shah