🟢 Lockable Fields

An incredibly useful feature on Tape will be the option to Lock Individual fields on the records.
Something like this:

Lock Fields

Any locked fields should only be edited via automation, which will prevent accidental edits from people with access to the records. We should be able to lock any and all field types.

Additionally, it would be amazing if we could lock the fields via workflow automation after certain conditions happen.

For example, you have a Contracts app with a text field (with the content of the contract), a Client field (Related), an Effective date, and a Status. When the Status changes to “Contract Accepted and Signed,” then the automation will lock all fields.

Hi @Luis,
Thank you for sharing this great idea.

I have been thinking about something similar and I believe something like this could effectively be super helpful. I was calling it editable in my head but it is kind of the same. Definitely a ton of value.
This would also help as a way to input some texts and locking them such as instructions, procedures, “wikis” or “knowledge” in general. Maybe some useful reminders or notes. I actually was in the point of asking the community about how to solve this instructions setup, and this could already be kind of a solution.

On top of what you mentioned, there could also be a lock symbol :lock: at the end of the locked field (or app or record or workspace) in order to know if something is locked. Although I’m not sure about that since it could alter everyone’s layout. Maybe there could simply change the color of the fonts to a less dark more grey color instead of a symbol. Or maybe we could just do it without any symbols at all.

test lock

(maybe a black and white symbol would be better or any symbol).

I may disagree with the fact of only being able to unlock from automation because it feels too extreme and it could be cumbersome. But a simple latch as you depicted could be simple and effective.

On the other hand, having automations tied to this is what would render it indeed helpful. We could build workflows that lead to kind of “save” previous work and protect it from accidental edits.

Thanks Luis.
R.J.

2 Likes

Hi @R.J ,

What I’m doing to “lock” sensitive information that I don’t want anyone (even me) to change by mistake is always hiding the field and using a calculation to reference the hidden field. At least that way, there will be no accidental edits, but that means I have to use two fields instead of one. If you want to do a wiki or instruction utilizing this method, you must temporarily unhide a text field, create content, and then permanently hide it again.

I love your idea of having a lock symbol beside the name field. It will make it very easy to identify.

As for unlocking only via automation the reason for that is, to me, lockable fields are to be used for circumstances where changing the value will cause irreversible damage to the content or when a change accidentally runs multiple automations that were not supposed to.

Another option will be to be able to edit lockable fields only once on the record creation. After that, only via automation.

3 Likes

Hi @Luis and @R.J,

a really extremely valuable feature and a very exciting discussion! Thank you very much for the request @Luis.

We have been thinking about the best possible implementation of how to change individual field properties depending on certain conditions for quite a while now. That’s why it’s extremely valuable for me to analyze your described use cases to see if they could be implemented with the current ideas. Thank you very much for that!

The whole topic is firmly planned on the roadmap in the next big record upgrade.
As @Luis has already recognized, it must be possible for every field type and also be integrated into the automations. That’s why we want to consider this requirement cleanly in the upcoming refactor right from the start.
We still have to decide how to solve it in the simplest and at the same time most powerful way. An interesting possibility would be to extend the permission levels by can view. And then to extend the permissions on field level and to offer an action for it in the automations. This would allow you to flexibly set content at record, app and field level to read only or to no access and thus hide some fields for certain users or set a complete record to read only.

I also like the idea with the small lock icon next to a field of @R.J to show the restriction status.

Cheers
Leo

3 Likes