Basically when setting up a custom action it seemingly grabs the data structure of the results the first time but then caches it such that any subsequent change to the JSON response it’s expecting is ignored. The JSON returned has the new field in it but it’s not accessible to be mapped to a usable magic text available to the page.
I’m guessing the recommendation here will be to create a new webhook URL when making any structural changes to force Adalo to grab the new data structure but unfortunately there’s no way I can tell specifically when using Integromat to change the webhook URL of the scenario (even when cloning it, it uses the old webhook URL). So absent that, is there some way we can force Adalo to refresh each time and always work from the most current JSON in order to ensure those variables are available as magic text fields?
Thanks for the video, really helps to understand it better.
I am going to need a bit of time to investigate this further and see what I can come up with to really determine if it’s a bug on our end or perhaps a different way it can be setup in Integromat or Adalo that would fix this problem.
I hope to have an answer for you in the coming days.
FWIW I don’t believe this is an Integromat issue. It’s returning the proper JSON and Adalo is consuming it (it’s there when you click “show full response”). Adalo just isn’t refreshing the mappings and exposing the new field via magic text. I was just trying to find a workaround in Integromat to force a new webhook URL as a way to paper over this issue but the underlying problem is Adalo seemingly caching the field mappings.
If you create a new custom action and change the webhook URL, does it still not provide the new mapping? Perhaps something to test in the meantime before I can dig in fully.
Which allowed me to test this theory and as I suspected Adalo has some type of caching bug with custom actions errantly using response structure from a previously submitted action. It worked like a charm simply by using a new webhook catch URL:
So without changing anything else in the scenario it now magically works (good news).
The bad news is this means this is an Adalo bug. IMO the fix here is to make it so it treats everything as a new response when editing the custom action (should be no caching of any kind at that point). I think it’s fine if it expects identical structured responses after editing during usage with end users but this is going to be a headscratcher for anyone developing.
For now the workaround is to provision a new webhook URL in the opening webhook element in the Integromat scenario (or whatever system you’re using to create the catch hook). cheers
Just to add to this, I am seeing similar issue where custom actions are unable to load magic text populated from the Logged in User when sending to Integromat. Very similar issue, were the magic text for fields not related to the logged in user populate fine and the JSON payoad is received by the Integromat Webhook. The fields that are supposed to be populated by magic text referencing the Logged in User all come through blank.
