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

[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...