Performance: Layouts

Discussion created by danjamins on Oct 9, 2018
Latest reply on Oct 11, 2018 by philmodjunk

Hi All,


Just starting this thread to get educated on how portals/related records/unstored calculations/etc. affect layout performance.


The reason being, I just redesigned one of our main client information layouts that has several tabs which used to have container fields in the parent table the layout was based on. We're talking about 40+ different containers, so not an insignificant amount. Recently, I had to make an architectural change to integrate a 3rd party web application for our partners to access client data without needing access to the FM system itself.


This required all of those local containers to be converted into a Documents table which in order to make it feel just like drag & drop container fields that my FM users are so used to for many years, I created 1 row portals that are filtered by the document "type" that should show up. There is a tab that has a full portal with all documents where it isn't filtered at all, but the other portals with the filtering are absolutely necessary to my users - they were really not happy when I tried to get them to switch tabs to upload a document or view the documents.


So I've noticed a bit of a performance impact when switching between records as all the related document portals load up along with the related notes portal (which is heavily conditionally formatted for color coding based on the user departments). I was wonder if there is a way I can minimized this degraded performance by use of popovers or other clever techniques that some of you may have up your sleeves.


Would placing these document portals in a popover button reduce the performance impact on record loading if the popover is not open? That way they are easily accessible without having the user switch to a different tab to view/upload.


Screenshot of one of the tabs attached... There's 9 tabs in total and each have document portals on them, but this tab in particular has the most of all.