Delay time between filling out form to create company and user being allocated to company

Hey guys,
Happy Monday! :rocket::rocket:

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 :slight_smile:

Have a great start to your week! :raised_hands:t3:

Hi Tim,

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.


Awesome, thank you, Matthieu!!
Is there any downside to emptying it? Slower loading speeds?

Theorically, removing the caching system should slow down the loading speed of the app.
Needs for confirmation by @artur

Hi guys!

I have exactly the same issue, so I’ll contact support. Thanks a lot!

@matthieu_chateau as an alternative, is there a way to use some custom code to “force a sync”?

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 :sweat_smile:

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


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? :slight_smile:

Great, I didn’t check it yet :sweat_smile:.
No option to do so.
But feel free to try the difference, it won’t be really that visible.

Hey folks,

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


Hi @artur !

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 :sweat_smile:

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.

1 Like

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:

  1. A user creates a company profile and then should directly see the profile they just created → Page loading after form filled out.

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

1 Like

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… !!!

Would you support such request ?


@hallofchange When users are being created, are they typically filling the profile right away?

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…

I hope my explanation is clear

1 Like

I have a similar use case where being able to switch caching on for different pages would be really valuable as well :slight_smile:

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 :wink: :wink:.