We’ve had several experiences where layout configurations were changed in an app using the new record layout, but those edits were not saved properly.
It seems that some field labels/config changes are intermittently not sticking,
The most common issue is with field names and field labels changing.
Sometimes it’s odd because the changes appear to work temporarily. We’ve even built automations and we could see the updated field names in the automation choices. But then later on (hours or days later) the changes had reverted back and multiple toggle fields showed the same cloned field name making it impossible to differentiate one from the others.
Recently we saw this error message pop up:
This short video details some examples of what we have seen:
We have tried to be extra careful to not have more than one user in an unlocked edit mode for any given app at a time.
@Leo can you share any details on what is an expected outcome if two people have an app unlocked at the same time?
Lets say that two users both have the same app opened in an unlocked state at the same time.
Imagine that user one makes edits, locks it, but then user two makes different changes and locks their instance of that app shortly after. Would we expect changes from user one to be overwritten or reverted back when user two hits the lock button?
Is there a way to see or know if another user has an app in an unlocked state?
@Leo we’ve noticed more examples today of field names reverting back to previous values even though they had saved at one point for us. Hoping to get more clarity on what might be causing this issue.
thank you very much for sharing this and for recording the video. I watched it carefully, and it is really helpful for us
From what I can see, there are likely a few things mixed together here.
First, the “Error saving” message usually appears when a save operation would create an inconsistent canvas state. In that case, Tape intentionally blocks the save instead of writing an invalid configuration. This is part of the protection we have built into the system. If this happens again, it would be extremely helpful if you could send us the browser console error. That usually gives us the exact technical reason, so we can fix the root cause very quickly.
Regarding field names and labels: when sync is enabled, field labels are designed to sync reliably. We have invested a lot into the underlying client and server state handling, and the technical foundation here is very strong. There can still be rare edge cases in very complex editing situations, and reports like yours help us identify and remove those one by one.
In the example from your video, I think one part may actually be a misunderstanding between the field title and the caption. It looks like you are using a checkbox-style display for a single select or status field. The text directly next to the checkbox is the caption, which is a separate style setting. It is not the actual field title. Because of that, it is also handled separately and does not behave exactly like the synced field label.
About multiple users editing an unlocked app at the same time: The new record is built for collaborative admin work. Changes are handled through live transactions, not as one big save at the end that simply overwrites someone else’s work. So the technical foundation is already designed for parallel editing.
Live avatars already work today when two users unlock the same record from the same app because in that case they are actually present on the same record. The more complex conceptual part is how to show this clearly when users are editing the same app structure from different records or even different layouts. Technically, the foundations are already in place and the live avatar logic works. We are now refining the experience around unlocked editing so it becomes even clearer who is editing what.
Thanks again for the detailed report. This kind of feedback is very valuable for us and helps us make an already powerful system even smoother and clearer.
Thanks as always @Leo for such a clear and helpful response.
I’m very happy to understand how the technical foundation for live parallel editing is set up. Being able to rule that out as something that we may have been causing with user error is good.
We will pay attention to any future errors with this and try to share the browser console error message for reference.
As you stated, with the difference between the title and the caption, I don’t think that was the issue in this case. We actually started using the captions after noticing this issue. It was an attempt to see if a similar text label on multiple captions while keeping different field titles would alleviate this issue, and that’s where we started getting into the caption piece. We will pay close attention to that and make sure it’s unrelated to that.
