🚀 Platform improvements for week 16

Note; added an additional fix to the list: 20250418 - Improve sync data processing for role_tab_variant_look_up

Here I noticed that this happens for every col x role (x variant). Of course this can grow very quickly in large applications. The sync takes a long time on the role_col and all similar combinations including role x col. Which is fine if you planned the sync for a deployment package, but with small changes to the gui, for example a change in theme or screentype, going through it all can seem a bit redundant?

Of course one way is to reduce your roles (and/or columns), or variants on the tables (with it's respective roles and columns). Is it possible to do a smart or partial sync? Of course, a full sync is more robust and secure, but not always necessary, and this could speed up the sync process significantly in this case.

 

Hi ​@jwismans,

The synchronization to IAM takes a while indeed, and the size of your model impacts the amount of time it takes. The time spend on synchronizing is the time that is saved when interacting with the application.

On the SF metasource, everything has to be calculated at runtime. On the IAM metasource, a lot of stuff is calculated upon synchronization. That means your application will start up quicker and interacting with entities and data will be smoother.

The caching strategy we apply uses all columns that need to have their effective rights calculated, which means whether or not they should be Editable, Read-only, Hidden, or Unauthorized. The last being a way to have the column completely hidden from the Universal GUI (for that particular role). This optimizes performance when using the UI.

The way to speed up the synchronization is to optimize the role configuration. Note that every column inside roles are included in the effective rights calculation. If you have 500 roles and all those roles have/need rights to a particular column, that column will have its effective rights calculated 500 times; as every role combination can lead to the column being hidden rather than unautorized.

Table variant columns have the same treatment, but being multiplied by the amount of table variants. So with the previous example, that could be 500 roles with 1 column and 4 table variants, thus having 2000 calculations. In the future, we will look into having table variants as first-class-citizens, allowing developers to set up role rights on specific table variants. 

Best practice: (Re)design your roles | Thinkwise Community