# Forms are unintuitive and silly in more ways than one
**URL:** https://community.fibery.io/t/forms-are-unintuitive-and-silly-in-more-ways-than-one/11315
**Category:** Misc
**Created:** [September 24, 2026, 1:46am UTC](https://community.fibery.io/t/forms-are-unintuitive-and-silly-in-more-ways-than-one/11315 "2026-09-24T01:46:44Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@AdVhPkgKad](https://community.fibery.io/u/AdVhPkgKad)
#### Post date: [September 24, 2026, 1:46am UTC](https://community.fibery.io/t/forms-are-unintuitive-and-silly-in-more-ways-than-one/11315/1 "2026-09-24T01:46:44Z")
**Standalone Forms**
These views are architecturally treated as an external-submission mechanism (shareable by URL to non-Fibery-users). That design choice is why they don’t get the “Create and open” panel redirect that the “+ New” popover on grids/boards/lists gets. Although I would appreciate parity for the users, I acknowledge it’s a deliberate product tradeoff, so I am not asking for this to be changed at this stage.
However, I do want to make a note that the form could check whether a user is logged-in and navigate them to the created entity on save, if it was set up that way.
**‘Create Entity’ Functionality and Usability of In-Platform Forms**
While the forms available by the ‘C’ shortcut are nice for power users, the following issues have been raised from our team since adopting this platform 15 months ago:
- **Default form for each form type is not set here** — The standard ‘Default’ form is effectively required fields only, which is almost never correct due to automations, validation rules, and values populated from different entry points. While the addition of ‘Required Form’ toggle (Pro feature) can be set on a form itself, it doesn’t help if there is a level of polymorphism which requires more nuance than a blanket solution.
- **Forms open in ‘Compact’ mode, always** — Users have expressed that this layout is unintuitive and limiting. They prefer the ‘Full’ layout to be the global default for all forms, and I tend to agree. I think Full should be the default, with Compact as the optional alternative.
- **Compact form ordering is set and unintuitive with formula names** — ‘Name will be generated by a formula’ is not helpful information. Many times throughout the app, I’ve used a pattern where the Name formula is delimited ‘text field’ + ‘some identifier’. In the Full forms, the field from which the Name is derived can be hoisted to the top of the page for legibility and a very human sense of orderly progression; this is not so in Compact form views.
**‘New Entity’ Usability of Smart Folder Shortcuts**
Similarly, when there are Smart Folders in the sidebar with ‘+’ icon, the subsequent ‘New Entity’ button that appears functions identically as the ‘C’ shortcut — Compact mode, no default set. The ‘Required Form’ comment above still stands (in my opinion, it’s actually _ **more relevant** _ here) since each Smart Folder has its own filters applied, which set the default value of fields.
Take, for example, a ticketing system. Tickets may have different types, each with their own ‘required’ fields. Without true polymorphism (a base Ticket, a Bug implementing the Ticket interface, etc.), the system must either treat them as two completely different entities (each with a separate database), or as the same entity type with caveats, including messy field validation.
**Conclusion**
I don’t know whether any of this is on your radar or planned for future re-visiting, but I thought I’d just get it out there and start the discussion.
---
### Author:  [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)
#### Post date: [September 24, 2026, 2:43am UTC](https://community.fibery.io/t/forms-are-unintuitive-and-silly-in-more-ways-than-one/11315/2 "2026-09-24T02:43:18Z")
I agree about the “Name will be generated by formula message”. I think most people don’t need to know that. Maybe let the architect decide if to show it as the “Name” field or not.
But the Fibery team disagreed with this back in 2025:
> [@April 17, 2025 / leaf\_fluttering\_in\_wind Duplicate Field, Improve Entity creation flow when entity name is generated via a formula, Multi-accounts in Google calendar](https://community.fibery.io/t/april-17-2025-duplicate-field-improve-entity-creation-flow-when-entity-name-is-generated-via-a-formula-multi-accounts-in-google-calendar/8625/12):
>
> > [@April 17, 2025 / leaf\_fluttering\_in\_wind Duplicate Field, Improve Entity creation flow when entity name is generated via a formula, Multi-accounts in Google calendar](https://community.fibery.io/t/april-17-2025-duplicate-field-improve-entity-creation-flow-when-entity-name-is-generated-via-a-formula-multi-accounts-in-google-calendar/8625/9):
> >
> > And a small thing that could be nice is that if there is only one field to be set by user, just show that as the primary field without the text of “Name will be generated” it could add confusion to the end user.
>
> Here I tend to disagree. Without this message it can be unclear what is happening.
> [@AdVhPkgKad](#):
>
> However, I do want to make a note that the form could check whether a user is logged-in and navigate them to the created entity on save, if it was set up that way.
This is great idea!! I have a link to a view which shows on submission “See your submission here” which takes them to a table view which then they need to find the thing they just submitted. A “Create and open” in standalone form views would indeed be nice.
> [@AdVhPkgKad](#):
>
> - The standard ‘Default’ form is effectively required fields only, which is almost never correct due to automations, validation rules, and values populated from different entry points.
Note: you as the architect can change this. But indeed it is not clear that it changes for everyone and not just for you. This still doesn’t change the
> [@AdVhPkgKad](#):
>
> - it doesn’t help if there is a level of polymorphism which requires more nuance than a blanket solution.
problem you state, but I am not sure what solution would make sense here… how can the system know which form you need when you press “C”.
> [@AdVhPkgKad](#):
>
> - **Forms open in ‘Compact’ mode, always**
100%! I also don’t like the fact this is set per view and not per form. This should be form settings, not view settings. The number of fields and the form type usually indicates if it should be full or compact, not the view in which it is in. So it doesnt make sense to have it a per view setting.
* * *
I am wondering what you think of this: [Open new entity in side panel for data input instead of form or in-line](https://community.fibery.io/t/open-new-entity-in-side-panel-for-data-input-instead-of-form-or-in-line/10984) I think it’s somewhat related. Basically opening it directly in entity view, and you can then set rules on the entity view on which to open (solving the polymorphic issue). Then it’s not set per view, but as a filter on the data of the entity itself. What do you think?