Which one is preferred: Adapt UI or Adaptation Projects?

[RaminS]

There are many good blogs/docs about key user UI Adaptation at Runtime to customize Fiori apps and create variants, and many good blogs about developer Adaptation projects in BAS at Design time.

But which method is preferred?

Assuming only developers will be making customizations (not key users) and no additional controller logic extensions are needed, which method should be used? 

Runtime Adaptations are easier with less overhead. But I'd like to see what other people think.

Thanks

[OliverGraeff]

The changes are 'added up' according to their layers. See details in https://ui5.sap.com/#/topic/17d2d4e8f9f3416da8865c1032f3dc19

[benderskiy · Accepted solution]

This is a great question! As you rightly noted, when it comes to implementing uncomplicated UI extensions— be it adding or removing fields, setting default views, renaming labels or titles, rearranging elements, simplifying the UI or introducing mashup content—the use of Key User Adaptation is allowing to avoid overhead of development and thus is highly recommended.

So, even developers or IT specialists are encourage to extend via key user adaptation and expedite the process from requirement to go-live, thereby minimising delays usually associated with development projects.

Despite it's simplicity focusing on adapting for all end users, key user adaptation also supports extending UI for specific user roles in SAP BTP ABAP environment or, by creating application variants and assigning them to different roles, in S/4HANA.

[RaminS · Accepted solution]

Thanks very much for the clarification, and the links.

[RaminS · Accepted solution]

Is there anyway we can assign variants to specific roles in on-premise S4/2020?

We need a display-only version of Manage Sales Orders. We've created a variant as per instructions for Adapt UI, but cannot assign the variant to a role. Is that feature only available in BTP?

Thanks.

[benderskiy · Accepted solution]

Yes, key user application variants (as well as deployed developer adaptation projects) can be assigned to users similar to how custom apps are: https://help.sap.com/docs/ABAP_PLATFORM_NEW/a7b390faab1140c087b8926571e942b7/877a1b392b7f466e8be3b33... Administrator needs to create a target mapping and a static app launcher.

[RaminS · Accepted solution]

If the same app has runtime UI Adapt variants, and adaptation projects deployed by developers, which one takes precedence? Does Adapt UI variant overwrite the developer variant?

[RaminS]

Thanks for sharing the link @OliverGraeff . It was very helpful, but it also raised a question.

In our scenario, we have 5 different sales groups which use the same tiles, each with their own UI and filtering requirements. We have created separate key-user variants for each group, assigning the variants to the corresponding role for each group.

If an end-user in group 1 creates a new variant in the personalization layer and make it Public, will it be visible to all users? ie. even the users in other business groups?

According to the document you provided the link to, end-users can create Public views:

How do we prevent Public views from each group to be shared only to their own user group?

Thanks

[kirilin]

Hi @RaminS,

You're right. If an end-user in group 1 creates a new variant and makes it Public, it becomes visible to all users. 

Could this pose a problem for your use case? If so, why? Are you looking for a way to entirely prevent the creation of public views? Or did you expect a different behavior when using the "Save as" function from a view with a role assigned?

It's important to note that key user adaptation isn't a security feature. Instead, it's a UX improvement feature. This means it can only hide elements, not fully remove them from the DOM. So, let's say you create a new variant for group 1 and remove 2 filters. An end user can still re-enable those same filters for their own use at any time.

[RaminS]

Hi @kirilin . Thanks for clarification.

Yes, if possible we would like to avoid end-users' ability to make Public variants.

Each of our sales groups operate under a different Company Code (sales organization). The role authorizations in the backend filter the data for each user to their own sales orders based on the company code. However, it would be bad usability if a user in Group 1 makes a filter default of Sales Organization = 001 and make that public for all other groups.

Do you have any suggestion on what the best way is to restrict UI adaptations to within specific groups?

One option we are considering is to make a separate tile for each group. Copy the standard SAP tile to 5 Z tiles (with all the target mappings), one for each group. That way a public variant of the tile for group 1 will not be visible in group 2, and so on. But that means creating a lot of Z copies of SAP LADI's.

Would appreciate any suggestions.

Ramin.

[kirilin]

Hi @RaminS.

Sure, it's possible to disable the 'Public' variants functionality as an FLP Admin. Please refer to this documentation: https://help.sap.com/docs/ABAP_PLATFORM_NEW/a7b390faab1140c087b8926571e942b7/1f4fcc6ea5ff440c84c2810...