I feel like I still don’t understand the root of this issue. The use of a form database is anathema to the Fibery data model, so we should nail down why you (both it seems) feel the need to create one.
Putting aside the choice of tool, and without stating a preferred method to achieve it, perhaps you can state what it is that you want each different type of user to be able to do, e.g.
“A client needs to be able to provide information about their dietary preferences”
“My teammates and I need to see all clients who are vegetarian” etc.
It might turn out that multiple entity view layouts, granular permissions, including entity view sharing is enough to solve it, without even using Fibery forms and without having a ‘form database’.
Or it might turn out that there’s a need is to have a form view that can collect data for multiple different databases.
Or maybe there’s a need for form view to support entity updates as well as entity creation.
Who knows?
Starting from the premise that there needs to be a form database, is constraining the range of possible solutions to be considered.
Quick questions:
With a setup like this, is there anything to stop an anonymous user filling in a form with someone else’s email address and thereby updating someone else’s details?
Is it therefore leveraging ‘security-through-obscurity’?
Would it be preferable if a user needed to provide credentials (or use some kind of email validation) to identify themselves?
One solution that could be possible here is having one Rich Text Field as the form submissions and each form has different Initial Text Value with the questions you want. This means all form submissions are unstructured data, but then its all indeed one form database.
If you want structured data, I agree with Chris that having one database for each type of data makes most sense. If its all in the same database with hidden fields for each form, then you’ll have a database with many hidden fields.
That being said, if its about having a Form Overview per client you could coinsider setting up a “Form Lookup” database (this would be the “one” form database), which is linked to the client, and the relevant form database. This adds an extra click when wanting to open the form itself, but would make it a bit more neat with less relationship fields if thats what you are looking for. It would need some automations to link it properly, but it should be possible. Let me know if you think it could solve the issue! I could try mocking it up if its unclear.
I think there are in general two different type of needs:
You quickly and easily want to gather information and you want to use a form for that (instead of an email for example). The data that you gather don’t need to be saved in specific fields/databases in Fibery → you just want the data.
You want to gather information and save it in a structured way so that you can analyze data, make calculations, create reports, stuff like that.
For me and my clients +/- 90% of the forms are in category 1.
As a (non admin/non creator/non tech savvy) Fibery user I:
Want to quickly create a form as fast as possible to gather structured and unstructured information
Don’t want to bother admins and creators → I want to do it myself.
I don’t want to think about automations, relations, workflows, views etc.
I just want the information.
Let’s say you have a company with 100 employees (= Fibery’s ideal client).
Imagine if every Fibery user can:
Easily create a form to gather information, without worrying about ‘technical stuff’. Like they can do in Type form, Google form, etc. They only want to think about “which questions needs to be answered”
Include/re-use (structure data) fields if that’s handy for the form because it will give you more options. And so that it can be processed easily, triggers workflows and automations etc.
We build workspaces for our clients. They don’t have knowledge of Fibery. Our current solution:
Their current forms are already created in tools like Google, Type form etc.
When a form is submitted, we send the data to Fibery.
The structured data (like name, email address) will be put in fields.
All open questions + answers will be in 1 rich text field (structured as question 1 / answer 1 / question 2 / answer 2)
Depending on the form/category we trigger automations/workflows/permissions etc. and link the submitted form to relevant entities.
Can you imagine how happy users will be if this is possible without external parties?
What I want as a Fibery admin / creator user:
An easy way for the end user to do a lot themselves so they don’t need an admin/creator for simple stuff.
Re-use existing workflows, automations, views.
A fast and light workspace with as less databases/spaces as possible.
However; sometimes you don’t “just want information”; you actually want to:
Analyze data, spot trends, create insights, etc.
Make calculations, create reports, etc.
Want to save structured data in specific fields
Then you need a different solution. It’s good to have a database for that since it gives you more flexibility.
Apologies that I need so many words to explain myself and I didn’t even answered all your questions. But I hope the information is still useful.
It would be awesome if a user can identify themselves somehow.
The actual security risks depends on the data that you’re gathering and how you share the form.
Is the form visible on your website for the public (like a contact form)
Or do you share the link with a specific person (like an intake form)
In our set-up the risk is limited because:
Forms are not shared publicly, but with a specific person. Of course people can somehow get the URL, but it’s a low risk.
For most forms we only use name and email address to link a form to a contact.
And if we have a form with (multiple) CRM related fields (which we only share with a specific person), we don’t automatically overwrite existing information in the contact. We only fill in empty fields.
But there is still a risk so it would be a nice feature.
However, I do think stuff like ‘conditional logic’ will make more users happy. But that’s an assumption.
Thanks! There are indeed several possibilities. But given the current possibilities/limitations in Fibery we’ll stick to 1 database.
Last note
I can also understand if Fibery don’t want to support the ‘Google / Type form style’ and that forms can only be created by creators. Just wanted to share the needs of ‘basic’ users that want to use forms to avoid emails and gather information.
You say that you want to use a form. What are the characteristics of a ‘form’ that mean it is your preferred mechanism?
If you could share an specific layout of entity view with someone, allowing them to add data into fields/rich text (and/or update existing data) what would be the disadvantages?
Where do you want the data to go, if not into Fibery?
If the data is not going into a Fibery database, then using a Fibery form definitely doesn’t make sense
OK, I’m confused now
Do you mean that the data does need to go into Fibery, but stored as some vague ‘submission’ record with no structure?
If so, then I guess having a database for ‘submissions’ makes sense (if that’s what your Form db is for)
So it is structured data? (or are we talking here about the 10%?)
Are your clients collecting data from someone who is already known to them (an existing Contact) or someone new? Or both?
As you know, Fibery Form View only supports the latter.
If a person who needs to provide data could be granted a (free) user account in Fibery, with only the ability to see/edit a single entity (their Contact entity) would that be useful?
Then they would need to log in to do anything, so that provides security.
But perhaps even logging in is too much friction?
This sounds like a well-defined use case
So the question then is: why can’t you grant Creator permissions to the users, perhaps limited to a specific space, solely for the purpose of allowing them to create whatever views they like, including form views?
From what you wrote here:
it seems as though there is a certain amount of tension between these two things.
I understand wanting to hide complexity from users, but then you are also going to limit what the users can do.
I suspect that this may be getting to the heart of why Fibery is not quite able to deliver the functionality you are after; there is a specific subset of things that you want the users to be able to do, whilst simultaneously keeping them ring-fenced from accidentally breaking stuff.
I imagine it will be almost impossible for Fibery to make a sufficiently flexible permissions system that would allow you to create your preferred boundaries for what is and isn’t possible for any given user.
That create a new (submission) record in a database
So that you have an record which contains the data that somebody provided.
That’s a good idea! But it will not work:
If there isn’t an entity yet. We use forms more as ‘submissions’ and based on the submission we create entities (like a contact).
If you have really long questions, then the Fibery field needs to be really long as well. Plus it’s handy to have some extra description to a question (like we currently have in forms)
Apologies, I will be more specific.
All data goes to Fibery. The beauty of that is that you have all data in 1 system. That’s our goal.
Forget about ‘structured’ and ‘unstructured’ data → I think I didn’t used those terms correctly if I google it. What I mean:
For some questions that are answered in a form, we have a field in Fibery. Data can be stored there. Example: name, address, date of birth, company name, etc. If those values are set, we then update empty fields in a linked contact entity.
For some questions we don’t have a specific field in Fibery. We currently save those questions/answers in one rich text field as followed:
Question 1
Answer 1
Question 2
Answer 2
Ideally you want to have as much structured data as possible, but we also want to limit databases, fields, etc. and make the life of the user that creates the form as easy is possible.
Side note: when I filled in the Fibery partner form last year you guys also choose to put the ‘other questions’ in a rich text field. The questions where set as default value and I then could type the answer under that question (all in 1 rich text field). Problem however was that the person that filled in the form also could easily remove those questions from the rich text field since it was like this:
But looking back I think we had the same ‘problem’ → we didn’t had a field in Fibery for each and every question (and we also didn’t wanted to create a field for that specific question).
So yes, my ‘form database’ stores the form submissions in records. With a bit structure for fields that we can use to link the form/submission record to a contact or other entity. But all other answer/questions are ‘dumped’ in the rich text field.
Both.
Because we have a ‘form/submission database’ that’s in between, we can handle both situations
Fibery always creates a new entity when a form is submitted.
If we can find a contact (based on email address) we link the form entity to an existing contact. Else we create a contact and link the form to that new contact (and fill in data such as name and email address).
It depends on the use case:
If you have to collaborate with a client (like when we onboard a new client in Fibery and deliver a workspace) then logging in or creating an account is not a problem if you can do other things as well (like showing project status, assign tasks, provide information etc.)
If you sell an online course and you want to sent a present to everyone that bought the course and you ask them to fill in a form with their address, it’s too much friction.
Same for filling in feedback/review/support forms.
But I also don’t think it’s needed in the last 2 scenarios that a user identifies itself.
The problem is not that I don’t want them to create a form view or add fields. That’s simple stuff.
What we don’t want:
Manual processes instead of the automatic processes that we have build (like automations to link forms to certain entities, auto create and assign tasks based on the category of the form)
Duplicate all automations/workflows to avoid manual processes, just because a form has different fields/database.
In task, contact, project, product databases (which current have a relation with form database) 20+ extra relations if a user has 20 different forms that are 20 actual databases.
What we do want:
And ideally a ‘dummy proof’ way for users to gather information via forms that they can easily create like they now can in Google form.
I don’t think the user is really limited if we can find a way to gather ‘unstructured data’.
Then the only thing the user is limited in, is that not all data is stored in a separate field, but some of it will be combined in the rich text field (or some other solution).
If they do need structured data (because of calculations, reports, analyse purpose) then they can (ask a creator to) create a database with fields and a form view like now.
Yep. In the current set-up it’s hard because a form is a view (which is a common approach that I really understand).
If you have a form that acts like an entity (and submissions of the form are linked to that entity), then you could rely on the current permission model. But you will also face challenges then I’m afraid.
I was thinking about this thread, and was re-reading some of the earlier posts in an attempt to understand why there seems to be a misunderstanding, and I think I now know
The word ‘form’ is being used for different, distinct things.
Namely, it is being used to mean both
the page/view (initially blank) where a person can enter information
the information that is being provided
I would like to suggest giving these things distinct names: form view payload
There is also the need to give a name to the event when the payload information is entered into the form view and the submit button is pressed.
Let’s call this the submission event
With this in mind, let’s imagine that the database that you call ‘form’ is actually called ‘payload’, and let’s look at some of the things you wrote:
Throughout the conversation, I have been reading the word ‘form’ and thinking of ‘form view’
I suppose it is my fault for not detecting this distinction earlier.
I was definitely right when I wrote
!!!
Bearing this in mind, I now believe that actually the issue at play here is that Fibery uses a data-driven architecture and some of the functionality that you are looking for will work best with an event-driven architecture.
For example, all the Fibery automations are primarily defined in relation to a data type (a.k.a. database) and secondarily to the events for that type.
Contact → Created
Contact → Updated
Project → Created
Task → Linked to Project
etc.
Similarly, form views are linked to a single data type and allow only creation
It seems that your use case would benefit from automations that are primarily defined in relation to an event type and secondarily to the type of data being created.
Create → Contact
Update → Contact
Create → Project
Link → Task to Project
and a form view would ideally allow creating (and updating) of any number of data types (for the same submission event).
My conclusion is the following:
your use of a single form payload database is actually a workaround to this fundamental dichotomy
By having a payload database, you can handle all submission events in one single place, i.e.
Payload → Created
But it unfortunately means that a ‘payload’ needs to take on the role of an umbrella data type, with all fields needed to cover all possible data types for which you might want to collect information from a user.
What is being asked for in this topic (‘Entity view customisation’) is actually an attempt to make the workaround less painful, by allowing the ‘Payload’ entity to display different fields, according to whether the payload represents a Contact, a Project, a Task, a Dietary preference, etc.
If/when it is implemented, it may bring some improvement for your use case, but it will not solve the fundamental issue:
Fibery databases are not intended to be used as containers for distinctly different data types
And I think it is fair to say that Fibery is so deeply data-driven, there will never be any features released that would resolve this issue.
Please let me know if I now have or haven’t understood, and accept my apologies for this not dawning on me sooner
No apologies needed! I was having a hard time to explain myself; thanks for your time and you understood me correctly after giving everything a distinct name.
Yes, I think this is the root cause. We automate as many processes as possible to avoid manual actions. So we have a
Yes, I understand.
Fibery is so powerful. Because almost everything is possible I always try to find a way. But in this case I think I have to stick with the Google Form/Fibery solution.
@Chr1sG now that we have the possibility ‘hide when empty’ in views I do see possibilities to use Fibery’s form function in combination with a ‘payload database’.
User adds fields in the payload database → the questions that needs to be answered.
User creates form view and only include those fields/questions that are relevant for the specific form.
User sets all fields in the ‘payload entity’ to ‘hidden when empty’ so that the view isn’t cluttered and only shows the questions that has actually been answered.
Maybe I’m stubborn But this feels very doable for my users. They can still profit from the automations that we have (i.e. auto create tasks when new form is created, auto link existing contact or create new contact etc.)
Only problem now is that rich text fields can only be hidden when you show them as snippet. And because a the person that fills in the form can give longer answers, information will get lost (and user can’t use the highlight function, which is awesome to collect data in forms).
Is there any chance that the ‘rich text field - document’ types can also have a setting ‘hide when empty’?
Or is that technically impossible given the current set-up?
EDIT
Maybe still a good idea, but I just discovered Formbricks which seems to be a much better (open source!) solution for our clients.
But this feels very doable for my users. They can still profit from the automations that we have (i.e. auto create tasks when new form is created, auto link existing contact or create new contact etc.)