Problem
In SAP Solution Manager, the start page can be customized to display different widgets, known as the „My Messages“ widgets.
In the setting, different filter, such as status or message type filter, can be configured. But one filter often behaves not as expected. Let’s talk about the Service Team filter.

The service team filter searches for messages, in which the service team, your business partner is assigned to, contributes. The problem is, how you define the „contribute“ part. For example, take a look into service requests. In service requests, usually a checklist is maintained. In this checklist, several steps can be assigned to responsible business partner, or even service teams.
Due to this, all messages are found as „assigned to my team“, in which the service team has a step in the checklist. This is independent of the step status, so you see messages where your step is not relevant. This behavior is often unwanted, but cannot be changed via customizing.
The desired outcome would be a list of messages (service request), where the support team is directly assigned (on the header level).
I will present a solution with only a few extensions to the coding. No SAP standard coding needs to be changed.
Background: BOL-Queries
To understand the search better, we can perform the search manually, similar to the automatic search by the widget.
In transaction GENIL_BOL_BROWSER, the search can be reproduced. Enter the component BT and select the query object BTQAICSearch. In the example here, a search with status, message type and service team is simulated. The search parameter SERVICE_TEAM is used by the widget and filled with the assigned service teams of your business partner. So the actual search behavior is determined by the search parameter.
A different search can be achieved, if we could change the search parameter. One step closer to our desired output, brings us an exchange of the search parameter SERVICE_TEAM with BU_PARTNER. The search parameter BU_PARTNER works together with the partner function. This search parameter is called /AICRM/PARTNER_FCT. Let’s try an adjusted search.
The partner function SLFN0003 corresponds to the service team, but depends on your configuration. Different partner functions can also be used.
But who can the standard search be influenced without massively changing the SAP standard coding?
Solution
The solution comes with extensibility of the WUI components. With transaction BSP_WD_CMPWB you can extend the coding of the different components. The component for the start page widgets is called AIC_IM_MYINCDNT. The trick here is, that the filters are dynamically created from the customizing in the component controller.
At first, create an enhancement for the component controller, which generates all the necessary classes in the customer namespace for you. You should always use the assistant to generate the enhancements.
Now you can freely redefine the methods in your z-class, the assistant took care, that your enhanced controller is called correctly. Open the new class and search for the function GET_FILTER_KEYS and redefine this method.
In the coding, start by calling the original (parent) method. With that, we do not lose any standard logic. CALL METHOD super->get_filter_keys EXPORTING it_filter = it_filter IMPORTING et_statuskey_values = et_statuskey_values et_transaction_types = et_transaction_types et_team_values = et_team_values et_processor_values = et_processor_values et_reporter_values = et_reporter_values EXCEPTIONS no_team_assigned_to_bp = 1 no_bp_assigned_to_user = 2 no_valid_predefined_proctype = 3 no_transaction_types_found = 4 OTHERS = 5. CHECK sy-subrc = 0. CHECK et_team_values IS NOT INITIAL.
The following code is only executed, if the table ET_TEAM_VALUES is not empty. This prevents us from adding the search parameter for the partner function, if there are now searches for the team at all.
We can then simply replace the parameter SERVICE_TEAM with BU_PARTNER in the table. LOOP AT et_team_values ASSIGNING FIELD-SYMBOL(<fs_team>) WHERE attr_name = ‚SERVICE_TEAM‘ AND option = ‚EQ‘. <fs_team>-attr_name = ‚BU_PARTNER‘. ENDLOOP. CHECK sy-subrc = 0. APPEND VALUE ltype_query_item( attr_name = ‚/AICRM/PARTNER_FCT‘ sign = ‚I‘ option = ‚EQ‘ low = ‚SLFN0003‘ ) TO et_team_values.
One small detail: The loop goes only over entries with search option ‚EQ‘. In case you filter for „not assigned“, the generated search query contains „SERVICE_TEAM LE 1“, and we do not want to break this search.
Now, whenever you search with filter for the service team, the BOL query is replaced with the more specific search for the head partner function.
Bonus tip
This new search logic can be what most of your users want. Be maybe, some prefer the standard logic. You can make the logic switch dependent on a user parameter, and skip your adjustments, if the parameter is not set by the user. User parameter can easily be distributed via mass change (transaction SU10). Also, individual users can change their own parameter in transaction SU3.
In the coding, the read can be done with a standard function call. Just use the following code right before you adjust the team value table. CALL FUNCTION ‚SUSR_USER_PARAMETERS_GET‘ EXPORTING user_name = sy-uname with_text = abap_true TABLES user_parameters = it_user_params EXCEPTIONS user_name_not_exist = 1 OTHERS = 2. CHECK sy-subrc = 0. DATA(lv_switch) = VALUE #( it_user_params[ parid = ‚ZCRM_DISPATCH_FILTER‘ ]-PARVA OPTIONAL ). CHECK lv_switch IS NOT INITIAL.