Stable technical identifier (system name / alias) for fields

Ideas & Features
1

Hi Fibery team :slightly_smiling_face:

It would be extremely helpful if fields had a stable technical identifier (system name / alias) that formulas, automations, and integrations could reference.

Currently, field references are tightly coupled to the display name of the field. When a field is renamed, it can affect formulas, automations, reports, and other dependencies. This makes schema refactoring risky in larger workspaces.

Suggestion:

Allow each field to have two names:

  • Display name — used in the UI and visible to users

  • Technical name — stable identifier used in formulas, automations, and integrations

Example:

Display name: Campaign Start Date
Technical name: campaign_start_date

The technical name would remain stable even if the display name changes.

This would provide several benefits:

  • safer schema refactoring

  • formulas that remain stable over time

  • clearer separation between user-facing labels and system logic

  • easier maintenance of complex workspaces

Many automation platforms (for example Make) use this approach, which allows teams to evolve naming conventions without breaking existing logic.

This could significantly improve maintainability for larger Fibery workspaces with many formulas and automations.

2

Note: In general, if you update a field’s name, it should not cause any formulas/automations/reports to break.
They will automatically get updated with the new name.

The exceptions to this are scripting in automations and markdown templates.

1 Like
3

Thanks a lot for the clarification, Chris! :grinning_face: :+1:

It’s really great that formulas, automations, and reports automatically update when a field is renamed — that already saves a lot of issues.

The tricky part we still encounter is with automation scripts. Since scripts reference fields directly in code, renaming a field can still break those references.

This also becomes relevant when working with external automation tools like n8n or Make, where field names are often used in mappings or API payloads. In those cases, a rename can unintentionally break integrations.

So while the current behavior works very well inside Fibery itself, a stable technical identifier (or alias) could still be helpful for scripts and external integrations where automatic refactoring is not possible.

Thanks again for the clarification!

P.S. :grinning_face: Another difficulty is that, as far as I understand :thinking: , there currently isn’t a very clear way to see all scripts or automations that depend on a particular field. Because of this, it can be hard to quickly identify what might break after a rename. (which often means discovering broken automations/scripts only manually)

Of course, building a full dependency tracking system for this might be quite complex and is probably something for the far future :smiley: .

1 Like
4

all true problems, I hope we will resolve them this year

2 Likes
5

I’m so glad to hear it! :star_struck: Thank you and your team so much! :+1: :grinning_face: