[DONE] Form View and required fields

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.

My reasoning:

  • 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.

8 Likes

I agree that native forms will be much easier to configure and use. We’ll re-think its priority.

Why don’t you use Typeform + Zapier for example?

1 Like

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.

2 Likes

Not to mention using two third-party apps to achieve such a simple result is cumbersome and expensive.

1 Like

Typeform / Tally / Jotform etc, can’t use internal app data.
That’s a really common use case to use forms based on existing datas.

3 Likes

+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.

3 Likes

Form View implementation started today. We hope to release something in October.

If you can describe your cases, like full flow with the Form View, it will help us to make better decisions. :face_holding_back_tears:

6 Likes

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:

  1. Text fields on the form unrelated to the databases so that I can add descriptions or links to guides.
  2. A more flexible interface rather than a single question per line.
  3. 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. )
3 Likes

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.

5 Likes

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+Smith&email=jsmith@gmail.com 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
5 Likes

Fillout.com is a new advanced form site to augment some other site’s basic forms. Just wanted to drop it here as a potential resource

1 Like

A teaser

7 Likes

Ooo, this is looking pretty nice! So these connect to Fibery fields, and you can set unique name + description, it seems?

That’s true, despite the field name that we will use by default for question you can set unique name + description for every field.

2 Likes

I hope there’s going to be lookup / relation fields as well. Many thanks.

Lookup fields are read-only, so it wouldn’t make sense to have them as input boxes on a form.

Sorry. I think what I meant is relation, being able to select an existing entity, eg. choosing a project. Thanks.

Yes, this is in plans. First basic release will not have it, but it is in the scope.

2 Likes

Form View is implemented and released. Now you can add more granular feedback

3 Likes