Quick question:
When employees sign up on my platform, they first create a company profile by filling out a form.
The form directly adds the user to the company profile via their email, and then the recordID of the company appears in the user profile via a lookup field.
However, if I direct the form to the userâs new company profile, the match has not been made yet. It takes a good 30 seconds of refreshing the page until the company profile will appear.
Does someone know why this happens? What am I overlooking?
Is there a time delay until a lookup field works?
Or is Airtable data only refreshed after a while?
I need to solve this to have a good user experience in the sign-up process, would really appreciate any help
There is a caching system linked to user groups.
You cans ask the support to remove this caching system. Though there will be an option very soon to enable/disable the caching system.
Nope, not such custom code. Even if I had this, I wouldnât give it as it would mess with the existing cache system of Softr with unwanted consequences at all levels
Also you need to understand that this cache system is in place as it fits the majority of the use cases of Softr apps (if you are wondering).
@matthieu_chateau
I see an option already to do so, but I guess that disables it for the entire website and things will be substantially slower? Is there any way to just disable it for that one page?
By default, the current userâs data is cached in the backend systems for a short amount of time; this is a great boost for 98% of apps, and in some rare use cases, when user signup and onboarding flow modifies userâs state in the datasource you might want to disable the caching to always get fresh up to date data from the datasource.
I am happy to hear about your use cases; we might still learn and enforce the case for users who have been active in the system for some time
In my case itâs exactly what you said: Iâm creating a marketplace for neighbors and contractors, and my signup flow has two âlogicsâ: if people have complete profiles or not (this is mostly due to Google Login, because people need to complete their profiles after logging in with Google) and whether they are contractors or neighbors. This results in 4 possible combinations that see different things in the web (pages and block visibility settings). Until today, I managed to create unnecessary success pages to give it time for the user sync to run
Maybe in the future this could be a setting mapped to certain blocks, in order to keep fast loading times but without completely turning off the caching system. Like, a checkbox in some blocks that, upon form completion, a user sync is triggered.
Iâll definitely test turning it off to see what happens! Iâm worried that my entire app gets much slower if I turn it off?
In my case, there are two essential times when I need changes to be implemented instantly:
A user creates a company profile and then should directly see the profile they just created â Page loading after form filled out.
My pricing is based on company size, so the user will only see the correct pricing once the user has the company size of their employer in their profile via a lookup field. So if it does not refresh quickly, the user will see a prompt to please set up the company size first again, even though they have already completed their profile.
Hi,
It is true that the loading speed is better, however I have the same issue than many others : when customers and users create an account, depending on the information theyâll feel (their profile), the cache makes them have a very bad experience because theyâll have to wait like 3 minutes to get to the right place. in the meantime, they are lsot and donât understand whatâs going on, because they provided the right information.
bad consequences for my app reputation : it is like 2% of the app usage, however as it is the very first steps of users journey on my app, they can just give up and quitâŚ
on the other, disabling the cache will also have bad consequences for 98% usage.
so it would be great that we can decide on which pages to disable the cache option , or maybe disable it for user group function⌠!!!
we have different types of users :
-non profit organisations which will have a 4 steps process with many information to create their profile and active it.
-users (volunteers) which will have a 3 steps process with series of quick questions. it takes 1min max to activate the account
we set this up as itâs user friendly ; much better than having a long list of questions to fill at once (which is discouraging).
in both cases, the series of questions are requested right after signing-up.
But since cache option, I have a pike of technical requests from new users/non profit org. saying that their account doesnât work⌠in fact, itâs like a lag of 3minutesâŚ
Same issue here. I have user groups âTraineeâ, âTrainee in-progressâ, âNew Userâ, âUserâ.
Each is an incremental step to the next. After sign up, everyoneâs user role (group) is âTraineeâ and they start on the home screen which is a welcome page with a list of trainings they must complete. Once they complete the first lesson, an automation changes their user role to âTrainee in-progressâ. When they return home a different screen should appear. However, it takes up to 3 minutes before the system recognizes the changed user role and shows the correct screen. I had to add another page that says, "Please wait 3 minutes before clicking âHomeâ. Same after training is complete, their role is changed to âNew Userâ and the Home screen should change to a form but again it takes up to 3 minutes until the form appears. I really donât want to slow down the whole site because I have large tables of data that must load.
You need to disable the user caching in the settings panel of the app => advanced settings.
Once you have done this you also need to use a personal access token for Airtable as a data source, not Oauth, it will be faster and at the end the performance changes should not be visible.
Yes. I have it set that way. Thanks. It is better but not perfect. My delay tactic of having them go to another screen and read some jibberish just to keep them occupied for a few seconds seems to work with these settings in effect.
There are more options, dare I say too many, now to connect to a data source (PAT Vs. OAuth), with performance trade offs depending on more settings (User Caching Vs. No Caching). It appears these new settings are necessary to not only optimize, but maintain performance?
This might be another one of those chicken or egg issues where the majority of builders (98% - @artur) do not use forms and profile block to adjust usersâ states, not necessarily because they wouldnât, but because they are not optimized to be responsive enough. If Iâm following this right, I have to trade off performance over the whole app for my usersâ to see their group changes in a reasonable amount of time since caching adjustments are sitewide (all-or-nothing)?
If these settings are necessary, rather than having builders trade off when performance issues arise, I like the two percentersâ ideas of cache settings at the page level, or even better, built into the blocks/groups so we can keep building apps fast without worrying about performance .
