Skip to Content

Three ways to control the visibility of an assignment block in overview page in web client UI

Hi Friends,
It is a common requirement that a certain assignment block in overview page should only be displayed under some condition, for example under control of a business switch.
Here are three ways which could control the visibility of one assignment block via code.

Approach1: dynamical view detachment

refine method DETACH_STATIC_OVW_VIEWS of the controller class of your overview page. All views put into internal table rt_viewid will be hidden by UI framework in the runtime. The code below just means you can evaluate some condition in line 3, and if the condition is met, the assignment block SearchResult will be hidden.

Approach2: dynamic UI configuration load

Create a new configuration within which only Search view is displayed. The configuration is bound to a certain UI object type.
Now we have two UI configurations. The standard configuration will display two assignment blocks by default, the configuration with UI object type = CRM_SMC will only display Search view.
  " IF search result view should be hidden
     me->set_config_keys( iv_object_type          = 'CRM_SMC'
                          iv_propagate_2_children = abap_false ).

Approach3: Control the visibility via business switch

This is a most elegant way, however it could only be used if you would like to control the visibility of your view via a business switch.
When you are assigning your assignment view to the view area of Overview page in runtime repository, a business switch can be assigned as displayed in the picture below. If the switch is turned off, the related view will be automatically hidden by UI Framework.
After you have assigned a view to the view area of overview page, the switch ID is displayed after view name.
You could first find the related business function for switch CRM_SOC_SFWS_SMI_2 via tcode SFW1,
then find the business function status in SFW5:
If the business function is deactivated, the assignment block will also be hidden automatically.
You must be Logged on to comment or reply to a post.
    • Hi Raja,

      actually the switch is only necessary in approach3. In approach1 you can use any condition evaluation logic in your IF statement, it is not necessary and not mandatory to evaluate the switch status there. I added some more information for approach3 regarding how to check switch status, hope it is helpful.

      Best regards,


      • Hi Wang,

        Thanks for your reply and also appreciate you time and effort.

        I tried the approach 1 and feel that there is disadvantage of using it.Please correct me I am wrong.

        Say after going to live, if the user wants to detach or reattach a new view dynamically, they need a developer to do it where in the approach 2 is not required.

        I am trying approach 3, Could you please clarify the below queries?

        1) Is it applicable for standard views. If yes how can we assign as I don't find any option for assigning it or how can I know the switch ID if it existed for the standard view.

        Could you please share any document on switch framework explain where, when and how it should be used.

        Thanks in advance.



        • Hi Raja,

          for approach1, in this blog I just hard coded the view which needs to be hidden in the runtime. However, for productive code you can develop a configuration table and put all viewes which needs to be hidden in that table. So whenever your requirement about hidden views are changed, you can just change the entries in the c table without changing your code.

          For approach3, it is still applicable for standard views. You can create enhancement set and then add the assignment block into overview view area with a switch specified.

          You can find document regarding switch framework from sap help.

          Best regards,