Hey guys,
I was wondering, like in Airtable, when you create a view you can edit the record view as well. In Fibery the entity view is universal for all views. A workflow that really is limited now are our forms.
We would like to create records for all the forms in one DB. But it gets really confusing when you open the record.
Is this something that is coming?
Could you explain the question differently, I am not sure Iâm getting the problemâŚ
What I mean is 1 database with multiple forms but the entitiy view changes depending on the view. Like in Airtable:
If the entity-view variation to be displayed can be determined by a field/formula/filter, including WHO is viewing, and what groups/roles they belong to - that would be amazing 
and yes, it would go a long way to answering my need for polymorphism.
Some old related threads:
We want the same and we are facing the same problem.
We have one âFormâ database that we linked to the contact database.
Letâs say you create 3 different forms.
In the current situation you need to add all fields to the form database.
If you open the form entity youâll see the fields of all 3 forms. Which makes it really messy.
Unfortunately thatâs one of the reasons that my clients canât use Fiberyâs form functionality.
Yes that would be awesome and unlock so much possibilities in process automations 
Why do you use a single âformâ database to collect data for three different purposes?
Why not have an âclientâ db, a 'feedback db, and a âdietary requirementsâ db, each with their own form?
What if you have 10 forms? 10 databases?
Well, if you need to collect 10 distinct types of data, then why not?
I want an overview on contact level. The contact database already has 20+ relations currently.
And we have all kind of automations (link the correct contact, trigger the correct workflow, auto create tasks based on formula category) and permissions.
I donât want to duplicate that.
When forms are integrated in the CRM solution then you really only want one form database.
So currently our clients still use Google forms, which we then send to Fibery via workarounds. Which sucks 
@Chr1sG The most common use case for this is for intake of multiple entities at the same time.
Example: a new project/client form should be concise and easy for the end user. It may collect Contact, Company, and Project data at the same time.
In HubSpot, NetSuite, or Salesforce you would create a single form with questions that map back to all three databases.
In database apps, a third-party app or a new data type can collect all values in one place then trigger a create or update workflow to record data in multiple databases.
This is a different case I think.
I agree that having a single form that allows collecting data of different types would be useful, but @YvetteLansâs examples (onboard a client, gather feedback, request dietary requirements) seem to be three different forms to be used on three different occasions (the data is unconnected and not collected at the same time). Which was why I was digging into why she used a single âformâ entity.
Or perhaps she did mean that all three pieces of information would be collected at the same time? 
@Chr1sG - a possible Forms solution for âcreate-and-linkâ related entities:
button there to allow the user to create and link a new entity? button.Hi Chris,
I donât know if I understand you correctly, but I only want 1 Form database.
Because:
When I want to create 3 (or 10) forms, then I need to add all different fields from those 3 forms in that one Form database.
So the entity view will look like this
(but then imagine that you have 3 different forms with each 10 questions)
Thatâs really messy, right?
The only solution is to create a database for each form but as mentioned above, thatâs far from ideal (since you then have 3 âform databasesâ linked to the contact database)
Or you need to leave the form entity view empty and only create views for each form where you then decide which columns you want to show and hide.
But thatâs also weird since we do have other relations in that form (like link to task database, note database etc.)
I understood what you were describing
but when you say this:
it is a statement about what you think the solution should be (i.e. 1 âformâ database which is used for all data collection)
Whereas I am trying to understand what the underlying need is, since it may be better solved with a different solution.
To me, a âformâ is not something that should be a database. A âformâ is a method of collecting data. So is entity view in fact (as well as being a method of displaying data).
The decisions about what should be a database will normally be informed by the data that is to be collected/managed, not by the means of collecting it/displaying it.
So for example, you write that
but is it really âthe only solutionâ?
At the moment, we should look at why you couldnât have a Contact database, and then have 3 different forms connected to it, one form for each distinct purpose (onboarding, gathering feedback, recording dietary requirements)*
*assuming that these pieces of data should logically all be part of the contact db, rather than linked dbs
I can imagine that when you are collecting these pieces of information, there are occasions when you actually want to update an existing entity, rather than create a new entity each time new information is submitted, so perhaps we should dig into that.
SoâŚ
Is there a need for a mechanism to allow external users to submit information, to be associated with an existing record? i.e. an âupdateâ submission. Probably yes.
Does this have to be via a form? Who knows?
What if external users could have limited access to their own corresponding Contact entity in Fibery, so that they can add info/make changes (in a limited way) at any time?
Maybe form view is useful because you can make fields ârequiredâ (which you canât on entity view) so perhaps we need to think about a mechanism to tie a form submission to an existing entity? Or maybe think about ârequiredâ fields on entity view?
Anyway, my point is that we should think about what is the underlying need, rather than directly naming a specific preferred implementation.
And with respect to @helloitseâs comment, it seems like she is asking for the ability for a user to submit data that is to be used across more than one database (Company, Contact and Project).
Which seems not to be the same as your need.
Agree, thanks for asking!
I think there is a little misunderstanding.
Currently the information is only saved in the form entity. So:
Why? Because not all fields that a user fills in belongs to 1 database.
So I do think we have the same need.
Let me clarify our situation with examples and use cases.
Maybe our set-up is wrong/not logic.
Currently there are a lot of workflows/processes attached. In our workspace the workflow is more important than which data is collected/managed.
Automations
Braindump & inbox
Use cases
Current set-up
So I donât have a âfeedbackâ database, âreviewâ database, etc. You can easily gather information for 20 different purposes (even way more but letâs say 20).
If I create a database for each and every purpose, I then:
etc.
Besides workflow/process and automations, it also feels natural to just have one form database. So that you will see:
But Iâm really curious what you think the set-up should be. We donât use forms to update existing records at the moment; only to gather information.
I get what you mean that you donât update existing records, and only âgather informationâ
but when you list your use cases, some of them sound like they are used to gather information that will augment an existing record, especially since you talk about
My point is, that if youâre collecting dietary information, there is a difference between
In both cases, you are only gathering ânew informationâ, but in the second case, you need to not only collect the new information about dietary preferences, but also who they relate to. The dietary information is new, but the who part is not new.
Given Fiberyâs current limitations, someone might think,
"Ideally I would have fields on the Contact database for dietary preferences, but I canât use a form view to populate these fields for an existing Contact, so I can do type 1 data collection, but not type 2.
To work around this, I will create a Dietary prefs db, linked 1:1 to Contact db. I will use an email field in the Dietary prefs db, and use auto-linking to connect Dietary prefs to a Contact.
Iâll make a dietary prefs form, and any time someone submits a form, they need to remember to include in the form submission their email address.
In that way, it will get linked to the right Contact"
Now, what if they also want to collect info on a Contactâs pet.
They do the same thing - create a Pet db, link it to Contact, set up a form view and require an email for any submission, and auto-relate.
âŚ
and so on.
But this isnât the only way to do it.
Someone else might approach this challenge and think,
âItâs crazy having all these extra dbs, so I will add the needed fields on the Contact db (for dietary prefs, for pets, and so on) and then create a single db, called Auxiliary info which also contains all these fields. It will have multiple form views (one for each type of submission) and when these submissions are received, I will use automations to transfer data from the Auxiliary info entity fields to the Contact entity fieldsâ
This sounds a bit like what youâre doing, from what I understand, and I donât blame you for doing that, if it is the least worst workaround in your workspace.
I am not even sure I could ever fully understand your clientsâ needs well enough to be able to determine all the pros and cons of any given workaround 
Perhaps for you, it feels intuitive that a form is type of data, whereas for me, a form is a data entry mechanism
So my toes curl when I read
Having said all that, as far as I understood this topic, as started by @StevenSkillit the original problem is how to display (and be able to edit) data from the same database in different ways (different entity views).
I donât know the extent to which this is overlapping, a superset or a subset of the problem(s) that you and others are experiencing with collecting data from external users.
Finally, there are so many things being worked on (or planned to be worked on), e.g.
multiple entity views with different layouts, public sharing of entity view, custom access levels, etc.
that I wonder whether some of the upcoming features (combined) will unlock a solutions for each of you, @StevenSkillit, @Matt_Blais or @helloitse even though technically your problems are not identical. 
Their needs are really basic Example of 3 forms:
When we follow my approach youâll only have 1 database (form), one set of automations (for auto create tasks when a new form is submitted and link the form to the contact), one relation with contact, inbox, etc.
On contact level that looks like this:
If I follow your approach, it looks like this
and then imagine that the contact already has +20 relations currently. If you have 10 different âform databasesâ then itâs really really messy
I really donât think itâs helpful to create 3 databases and duplicate everything
We include name + email address so that we can link the forms to the correct contact. How else would you do that?
And we also include other CRM related stuff if there is a situation where itâs handy to update contactâs information. Like date of birth, address, etc.
If you look at the average intake form of a consulting company like mine some questions are CRM related (name, billing address, etc.) while others are specific for the service/product that has been bought (whatâs your pain/desire/etc.).
If I donât include CRM stuff in the form then:
(or do I miss something?)
I really donât see the benefit of any of those situations.
So we need this:
But even then I prefer one form database for most of the situations that acts like this:
Then youâll only see the fields that are applicable for the specific form and you can re-use fields if helpful.
With respect to this:
Although @StevenSkillit uses the word âformâ (and labels some views as âformsâ) as far as I can tell, they are in fact grid views in Airtable, which are like table views in Fibery
And when opening a record, he is seeing record view in Airtable (which is entity view in Fibery).
This has nothing to do with âformsâ as defined in Fibery, which are purely a data entry mechanism, and only support creation of new entities (but can be shared externally).
This is why I say that your needs and his are not the same.
Yes, but name and email address donât âbelongâ to the form (at least for the Fibery data model)
Name and email address belong to a Contact.
This is what I mean about a form being solely a mechanism, not a database.
But never mind. I think we just have different mental models
Hey @Chr1sG,
Just to add to the conversation, I think @YvetteLans and I are on the same page. Weâre looking for one central database to capture all the data from our various forms. Since we donât use the forms provided by Fibery, we need a system where we can link different types of forms to the contacts who fill them out. Weâd prefer not to have multiple databases for each form type. Thatâs why I showed Airtable. For example, Form 1 could be for onboarding, showing only the relevant fields for that process. Form 2 might be for feedback, displaying just the fields needed for feedback.
