There was recent mention about Forms not being prioritized because Fibery doesn’t feel it is important, but I wanted to express my opinion that I think Forms are absolutely critical to product team adoption.
A core function of product teams is to manage external input
As a developer of a tool for product teams, you should be trying to minimize key friction areas
Getting external input into Fibery has a very large amount of friction and adds cost beyond the core Fibery service cost
Available workarounds are very labor intensive, slow, and error prone
Available workarounds force us into using Fibery’s competitors to fill the gap (airtable, coda)
These forms can’t be integrated into the Fibery experience
My current solution is to use Coda to recreate my Type I want to collect and build a form for it with help text, required fields, etc. You really need to model this out correctly so that you have the information you are expecting, which takes time. Then, I had to create an automation in Integromat to map the coda fields to Fibery’s fields. This automation can only be triggered by a timer, so there is no real time push for Coda, and I’m not sure there are any free form tools out there that would give real time push to Fibery.
To be completely honest, after I quickly built a form for this in Coda, then went through all the trouble with Integromat to get that working, I asked myself “If this was so easy, why don’t I just give Coda another try?” This is not something you want your Product Team target audience doing.
What does Typeform + Zapier give me that Coda + Integromat doesn’t? Either way I have to maintain consistency between the Fibery type, the automation platform, and the form, no matter what it is hosted through right?
With Typeform I think you’d gain immediate submission via webhook but have limits on questions and forms, while with Coda or Airtable you have to poll for the submission, but don’t have the form/question limitations. We don’t pay for or currently use typeform, which is why I didn’t start there.
+1 for this as a much needed feature for collecting external inputs
If / when you do implement forms I would really love to be able to prefill the form fields using URL parameters like Google Forms does.
Also having hidden fields would allow for some pretty neat automations. For example I can have one automation button attached to a Sprint entity that sends an email to a client for work approval, that email includes a link to the Fibery form that is prefilled with a 1) hidden field that is that clients Fibery entity ID and 2) the deliverables summary which is just the deliverable entities attached to that sprint. When the client submits the form there could be another automation that marks the Sprint as approved.
This is great news! In order of want: (required fields, hierarchical relations, same formula capabilities as automations/buttons, and multiple (linked) databases per form)
Use Case: Simplifying Infrequent Complex Workflows (e.g. project setup)
When logging a new project in Fibery, there is a natural sequence that I want my team to create the information across databases/views. So instead of a different form, I’m looking for my team to have one form (or multiple pages) for filling out information across different databases.
For example: from top-level project information (project database) to filling out which scopes are included in this project (scope database), filling out listing all companies (company database) and tying them to the scopes above and assigning people (people database) to those companies, etc.
The tricky part is I want the latter questions to be filtered by their hierarchical relations of the earlier questions. But ideally I want a single workflow to set up a project team for success. Creating these longer forms focused on the workflow between databases is important to me because it standardizes important processes which in turn helps me with onboarding new users.
Additional Misc. Wants:
Text fields on the form unrelated to the databases so that I can add descriptions or links to guides.
A more flexible interface rather than a single question per line.
Listed checkbox selection of options rather than only a multiselect relation.
(For example: I have a task / QAQC template database with an automation that looks for aspects of a project (type of project, client, scopes, materials, etc.) and duplicates those templates for the team to then have on their task list at certain stages in the project. This works fairly well, but it would also be good to lay certain options out on a form for the team to check off if relevant or not. I always liked how Ninite.com did it, allows you to quickly select all of the options you would want to add to that relation field. )
Fantastic to hear implementation is underway for Forms.
I’m happy to share my thoughts on use cases. In simple terms, I find there are two classes of Forms: basic and advanced.
Basic forms for simple Intake forms such as:
Customer Support ticket submission form
Feature request form
Graphic design request (for teams requesting some design/artifact from a marketing team)
Equipment/software request (for team members requesting the purchase of equipment or software)
Handoff forms (to cover team-to-team handoffs, such as Sales closing a deal and submitting intake forms to Customer Success to kick off customer onboarding and/or to Engineering for new tenant creation)
Advanced, layout-based forms a la “wizard” experience with required fields such as:
Sales CRM forms for lead, account, contact creation, with fields sequenced in pages/modals, requiring the user to input specific field before being allowed to proceed to the next step
Employee onboarding forms, with sequenced fields collecting the employee info, and possibly even a series of “Checkbox” fields as a “Checklist” for the user to mark off as those items are completed.
The use cases are quite endless here across many domains: Real Estate property listings, Construction Management subcontractor setup/contracting, etc.
I anticipate the need for field dependencies at some point as well, which would be helpful in both basic and advanced forms. I define field dependencies as the ability for one field’s display and/or dropdown values to be dependent upon the value the user previously input into a preceding field. For example, we could have a customer support ticket form with a “Type” field and a “Category” field. When a user selects “Type” = “Bug”, then the “Category” dropdown field would be displayed or enabled and display values only related to Type = Bug. Alternatively, when a user selects “Feature Request”, the Category field would not be enabled or displayed at all.
For my team specifically, we have immediate needs only for basic forms specific to customer support, feature requests, and team-to-team intake/handoff requests.
To me key features of a form would be ones that enable the user to complete a workflow in a self guided way. I want to be able to say “Hey new client/user/worker please complete this Onboarding Form” and they should be able to complete it without additional instructions from me.
The bare minimum features would have to be:
What is the form for (title, rich text description),
What is each field for (title, rich text description),
Input validation (required field, must match this Regex)
Advanced features that would make Fibery native Forms powerful:
Value must be unique requirement - checking if any other records in the DB have the same value for that form field
Conditional logic - being able to make certain fields show/hide or required/optional based on the input provided in a prior field allowing to automatically hide/skip irrelevant questions. This is how Typeform does it:
Prefill a form using URL parameters - meaning if I have a form for creating new Contact records with the URL https://the.fibery.io/Contacts/The-Form you can prefill the Name and Email fields in the form using the URL like this https://the.fibery.io/Contacts/The-Form?name=John+Smithfirstname.lastname@example.org This is enormously useful when paired with hidden fields for things like:
referral tracking - generating form links with a hidden prefilled ID field
if its shared publicly, being able to note where or with who it was shared
providing additional conditionality for triggered automations