[PLANNED] Enforce unique entries + Data validation + Required fields

Hi guys, I’m new here and so far I’m quite impressed with Fibery - it has a huge potential. I did however react to one thing that baffles me: How come we cannot - in an easy way - prevent a field from having duplicate values? My use case is that we want to move our product database into Fibery, but we can’t risk that people add a product and accidentally enter an already existing SKU (we have thousands, so it’s easy to make a mistake). In addition, we have a naming system in place, so data validation would also be very valuable.

I’ve looked around and seen a few workarounds in the forum, but they are overly complicated (call me an idiot, but I would never figure those things out on my own). Anyway, there are definitely ways to make this more intuitive and easy to use. As an example, I attach a screenshot from another database tool I’ve tried (it has other shortcomings though) that has more settings in general for the fields. It is easy to understand, powerful and the UX is just what it needs to be.

Please have a look and take this into consideration. I believe these are crucial features when databases grow large.

PS. You have it implemented in custom icons, where duplicate names are disallowed.

Is this duplication of existing topics?

Hi Chris,
By the look of it, these two topics should address Data Validation and Required fields. Sorry, I haven’t seen them.

The most important function for me however is “Unique entries” as a field setting.

Field setting

E.g. say you have an automation set up where an article-number / SKU is the key identifier. If you cannot guarantee that field to have only unique entries, the risk of errors is way too high for me to feel comfortable with.

As for user feedback, here’s how you’ve done it for the custom icons:

I understand the issue, but it’s worth pointing out that (unlike when you create/update a custom icon) changes to Fibery entities do not require an explicit ‘save’ action by the user - the data is updated as soon as it is typed.
This adds complexity to any solution that would be implemented.
For example, a user types a field value that is a duplicate of an existing value.
What should happen next? Should they be prevented from leaving the page until they resolve the issue? What if their internet connection is lost at just that moment?
Of course, these challenges can all be figured out, but suffice it to say, making fields required and/or unique is not a trivial feature to roll out. We are gradually working on it though.

Would it be an idea to autosave the entry but make it inactive until the Unique-field has been entered correctly?

Another approach: Would it be less complicated if you could only have one Unique-field per table? (I am aware you have the autogenerated key field, but that is not very useful if our own values have to be unique)

You are right, the custom icon example is a form field, but I think it’s useful to illustrate the visual feedback you can give to the user.

The link you enclosed is for Required (mandatory) fields. Although Unique entries per se have to be required, a required entry doesn’t have to be unique. These are separate features, but I suppose that’s what you mean when you say gradually - one step at a time.

I’m not sure what you mean by ‘inactive’. In Fibery, an entity exists or it doesn’t :person_shrugging:

:+1:

I meant that it should exist but in a third state, like a draft of sorts. It would allow you to enter the whole entity, but until fields that are required or unique are correctly entered, that particular entity won’t automatically be included in calculations, lookups, forms, views etc.

Sorry, I’m not familiar with all the technical jargon, but I hope you understand what I mean. From my perspective running a business, when dealing with values that without exception have to be unique (customer numbers, article ids, part numbers etc) this is an extremely important feature.

It might be a bit odd if an existing entity apparently disappeared from the workspace because someone tried to change its name to a name that was already in use, and didn’t realise.

Anyway, the problem is well understood. It’s just a case of figuring out the optimal implementation given the underlying technical constraints.
We’ll obviously update this thread when a solution is developed.

1 Like

Fibery can do many things “in the background” via Automations and Integrations, including creating new entities, and there is not always a way for those operations to interact with a User, e.g. to warn them about a duplicate field value.

The best that could be done in such a situation is probably to generate an error Notification.

1 Like

Unique field value across the whole database is in plans for Q1 2025

2 Likes