October releases have been 


Annotating things inside a system is so important for onboarding and your future self. Especially in a platform like Fibery, that is prone to sprawl into many databases, fields and views, if adopted well. 
I have some feedback for forms! 
Can we have the form field trim the (plain) text fields on submit?
I.e. want a user that copy-pastes an entry like ID abc123 to be stored in DB as abc123
It’s super duper common when users copies and pastes data from other applications, that leading or trailing whitespace is transferred, and in my experience there are never a reason to “respect” leading or trailing spaces, in simple text fields. If the form doesn’t trim it, we have to put cumbersome automations to do it.
Notion actually trims all leading and trailing whitespace in most inputs including databases on copy-paste (Fibery does not
).
In Notion DBs, trailing and leading whitespace are stripped on paste into text fields, but user can manually enter a text field, and add (back) whitespace via keyboard, if they so wich. Spaces added this way are then retained on copy paste (I don’t know how they do it, but it’s super nice).
Personally I cannot think of any use case where I’d want to intentionally store leading or trailing spaces in a text field on manual user input. (Updates via API should naturally preserve content including whitepace.)
It would be super great with basic regex validation on (plain) text fields
One typical benefit of forms is to validate user input. With the form being connected to fibery that has typed field, this is already very good. Dates, Numeric fields, Selects, etc.
However, text fields are a bit problematic. Typical use case is we ask our user for something like a customer id or order id. But our users easily confuses the IDs, or types something else that is wrong.
Regex is very powerful here to validate text fields, and raise the data quality of data from submissions.
Therefore I’d love basic regex validation support for (plain) text field. Since regex is so powerful, we can build most of any pattern validation we want.
I don’t think we need a separate validation error display field apart from some error highlight on the offending field, since we can put the input (format) we expect into the field descriptions, which is already supported.
Add ‘submit another’ after submission
It would be great if admin could set if user should get a “Submit another response” link, that returns the visitor to the form again (blank).
Especially when a form is iframe:d, it can be hard for the user to work with the form otherwise, if they need to make multiple submissions. Even if you can refresh the page without side-effects, its not really obvious that it’s possible.
Microsofts Form has one implemtation of that. In MS Forms, it’s an option the form creator can enable per-form. I typically think its fine as a default behavior, but I can imagine some users might want to have it as an option.
Idea: can we have the option to let Creators & Admins “lock” the default view mode to preview ?
I can see the form being useful not only as a shared link outside of Fibery users, but as a simple templates for internal Fibery users. I guess this a bit analogous to the “create Issue” forms that Jira always had.
If you create an entity and it has 20 fields, it can be hard to focus on the most important fields. Once you update, you typically just work with one or a few fields, but that is not the case when you create an entity.
For example, to quickly register a add a new invoice to Fibery, I’d like to use the “Add Invoice” form inside Fibery as well. Using the form, I got nice descriptions, and I can focus on only the relevant fields thanks to the form. I have some simple validation to guide me as well.
However I do recognize this path is a little… slippery slope-ish?
Because then next, I’d want the form submission page (inside Fibery only) to give me the option to redirect to the newly created entity, or to submit another. And maybe have the have form presented as an option to use, when a user creates an new entity.
I see something more controlled, like Jira-forms, down this path (which is a good thing! but obviously requires significant effort). But I be curious to hear if you have planned something like this for later?
Other form issues
You already seems to be working on relations and putting hidden inputs, so we can properly target a form submission with a automation rule. 
I wonder if we will be able to filter the relations that will be selectable, since it can potentially be quite a lot that shows up (e.g. and 90% might be archived/non-relevant)?
Also templates in rich fields would help a lot to keep things dynamic and flexible, perfect for stuff like bug reports and as a template for user requests and feedback (what data we expect user to send in).
But I think you are working on a solution to make that possible as well?