I have a multi select field ‘status’. And an automation that updates several fields, the status field is one of them. When the automation runs, I can see the changes in the new record experience screen appearing. But the status field remains in the old value. Unless I refresh the browser, or wait 5 or 10 seconds.
I tried to update the status in a seperate step in the automation, even putting it before the other updates. It didn’t help.
Is this behaviour deliberate? What can I do to make the multi select field show quicker and at the same time as the other fields?
Thank you so much for your detailed bug report! We’re already looking into this.
We actually rolled out a complete overhaul of Tape’s real-time update logic last weekend. We tested it extensively, as the goal was to make live updates 100% robust and reliable, especially when multiple people are working on the same record or when changes are made through AI via our MCP Server or the API (which also includes automations). These scenarios are becoming increasingly important.
So this could indeed be a regression we accidentally introduced with that update.
One quick question: Which display type are you using for your status field? Is it a dropdown or inline buttons? It might be related to the display type, but we’re already investigating the issue on our side.
We’ll get back to you with an update and hopefully a fix very soon!
Sorry for the trouble, Eric, and thanks again for taking the time to describe the issue so clearly. Really appreciate it!
Thanks for looking in to this so rapidly!
The fields are shown as inline buttons. I noticed the delay a few months ago already. Sorry for not mentioning it before. In those screens it wasn’t that important, but it is now in another app.
If you need any other input from me, don’t hesitate to ask.
You’re very welcome, @Erik_Mathlener! That’s what we’re here for!
We’ve actually already identified the issue, and the fix is in progress. It was indeed related to the inline button display type, which is particularly important as it’s often used to trigger automations and reset the buttons afterward.
The component wasn’t properly reacting to external changes and only updated occasionally when other changes were triggered, exactly as you described.
So it was actually a pre-existing UI issue, completely unrelated to our recent real-time logic overhaul.
The fix should be live by tomorrow at the latest. I’ll let you know once it’s resolved!