# Allow more field name changes

**URL:** <https://community.fibery.io/t/allow-more-field-name-changes/1086>\
**Category:** Ideas & Features\
**Created:** [October 19, 2020, 10:59am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086 "2020-10-19T10:59:31Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![Haslien](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/haslien/32/493_2.png) [@Haslien](https://community.fibery.io/u/Haslien)\
**Post date:** [October 19, 2020, 10:59am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/1 "2020-10-19T10:59:31Z")

</div>

Was asked to relay this feature request from team members.

They want ability to rename all fields, specifically so we can make them Norwegian and /or give them clearer meaning to anyone that uses the field.

One specific that comes to mind is the Workflow State extension. It allows renaming, but no other name seem to be valid.

---

<div class="post-metadata">

**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\
**Post date:** [October 20, 2020, 1:46am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/2 "2020-10-20T01:46:36Z")

</div>

I think this would be useful for “Assignments,” too. In the case where I have something that is more “owned,” like a Goal or Project, would like to be able to rename that field. We are both talking about Extensions including your case @Haslien.

Sorry to Segway, but I’d also like to be able to have the Assignments Extension repeatable. I have cases where I’d like entity “assignees” as well as “watchers,” or another type of “person” field like “supervisor.”

Thanks!

---

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [October 21, 2020, 12:04am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/3 "2020-10-21T00:04:16Z")

</div>

I think I mentioned elsewhere that it would be nice to be able to duplicate as well as rename Extensions (i.e. have multiple “instances” of an extension). That said would you want the Assignment extension to work exactly the same, just with a different name, for your described use case?

---

<div class="post-metadata">

**Author:** ![Polina\_Zenevich](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/polina_zenevich/32/480_2.png) [@Polina\_Zenevich](https://community.fibery.io/u/Polina_Zenevich)\
**Post date:** [October 21, 2020, 1:01pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/4 "2020-10-21T13:01:27Z")

</div>

Hi!  
Unfortunately renaming those extensions is a problem for our backend ☹  
If this is crucial for you, then instead of a Workflows Extension you can just add a Single Select field 🙂  
The same for Assignment - that is just a relation between Type and User. The only thing is missed for this case - Notifications. But I suppose that Notification will be improved before we will allow extensions renaming 😉

---

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [October 21, 2020, 5:47pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/5 "2020-10-21T17:47:39Z")

</div>

Hmm, yes I suppose if you implement a more flexible/capable notifications system based on rules, then we could setup e.g. “notify user X on Entity Change when value of field Y = A” where “field Y” is a single select with the A being the user’s name, which we can map to an actual system user with this notification logic… Is that what you are basically saying may be possible?

---

<div class="post-metadata">

**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\
**Post date:** [October 21, 2020, 8:50pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/6 "2020-10-21T20:50:56Z")

</div>

> [@Polina\_Zenevich](#):
>
> But I suppose that Notification will be improved before we will allow extensions renaming 😉

Yes I’d like to add that I’m also curious about any information re: any progress on Notifications. I would particularly get good use out of date-based, as well as any way to have more control around user notifications - such as a pretty common concept of a “watcher” that gets notified when activity happens in an Entity. That is a fundamental of most other project management apps I’ve seen.

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [October 21, 2020, 10:03pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/7 "2020-10-21T22:03:34Z")

</div>

I think Polina is just pointing out that the assignment extension is basically no more than a standard relation (between an entity type and the user type) but with the specific functionality of notifications laid on top.  
So when a more generic notification system is developed, similar functionality will be possible for any number of entity\<-\>user relations.  
So I imagine it could be set up so with auto-notification rules like: “Notify X when (boolean)” and here X can be hard-coded, or can be any expression that evaluates to a User.

e.g.  
Notify Task.Watcher when (IsChanged(Task))  
Notify Task.Owner when (Now = Task.DueDate)

Owner and Watcher are just normal entity\<-\>user relationships

The nice thing about this is that standard entity\<-\>user relationships can be defined as one-to-many, many-to-many or many-to-one.  
Useful if, for example, I want to limit a task to having only one owner, or I want to limit a user to only be allocated to one department, or…

---

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [October 21, 2020, 10:15pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/8 "2020-10-21T22:15:55Z")

</div>

Ah yes, that makes perfect sense. Believe it or not I didn’t notice that User was a Fibery Type I could create Relations to!

---

<div class="post-metadata">

**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\
**Post date:** [January 11, 2021, 4:42am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/9 "2021-01-11T04:42:21Z")

</div>

> [@Chr1sG](#):
>
> So when a more generic notification system is developed,

Would very much like an update on that as soon as we can, with Automations showing in the latest WIP on Dec. 10 in twitter, improvements in Notifications are all the more relevant as that’s a key “second half” of Automations in all apps that have Automations in even a basic degree built out.

---

<div class="post-metadata">

**Author:** ![Nurlan\_A](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/nurlan_a/32/1689_2.png) [@Nurlan\_A](https://community.fibery.io/u/Nurlan_A)\
**Post date:** [September 10, 2021, 5:54am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/10 "2021-09-10T05:54:28Z")

</div>

I support this request, renaming is necessary for non-English users. I would like to rename the Name field for now.

---

<div class="post-metadata">

**Author:** ![helloitse](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/helloitse/32/498_2.png) [@helloitse](https://community.fibery.io/u/helloitse)\
**Post date:** [January 12, 2022, 2:54am UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/11 "2022-01-12T02:54:09Z")

</div>

I think that renaming the “Name” field may be easier right @Polina_Zenevich?  
As it is now, if you import a type, you can inherit the name of the name field.  
But I’ve run into a situation where I’ve built an entire space, created reports and want to change the name of this field. I don’t want to have to start all over by exporting and re-importing the data as a new type.

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [December 12, 2024, 4:07pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/12 "2024-12-12T16:07:03Z")

</div>

FYI, Assignee field can now be renamed (it behaves like any other User relation field)

> [@October 10, 2024 / takeout\_box Search in basic text/email/phone Fields, People Field, Space Setup 2.0, and more](https://community.fibery.io/t/october-10-2024-search-in-basic-text-email-phone-fields-people-field-space-setup-2-0-and-more/7512):
>
> Today’s release has many quality of life improvement and one major experimental change for creators. Search in basic text/email/phone Fields Special for @cire12, @Matt_Blais, @JoelH, @Eugene_Vabishchevich, @JMaynier, @uniquelau and so many other people. Now search supports all basic text fields, including Basic Text, Email, Phone and URL. It unfolds some new use cases: Search for people by Phone or Email, useful for Hiring and any other CRM process. Search for specific identifiers, like UUID…

---

<div class="post-metadata">

**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\
**Post date:** [September 25, 2025, 2:44pm UTC](https://community.fibery.io/t/allow-more-field-name-changes/1086/13 "2025-09-25T14:44:38Z")

</div>

Now you can also rename Name field

> [@September 25, 2025 / Disable public sharing in a workspace, Rename "Name" field](https://community.fibery.io/t/september-25-2025-disable-public-sharing-in-a-workspace-rename-name-field/9680):
>
> Disable public sharing in a workspacemoney_bag This feature is available in Enterprise plan only If your organization doesn’t mess around with security and wants to prevent any information leaks to the internet, you can now disable public sharing in the entire workspace: This would make it impossible to publicly share Entities, Documents, Whiteboards, Reports, Spaces, or Forms. The existing shares won’t be affected though. To restrict public sharing, go to Settings → Public Shari…

Still few fields to go…
