I’m building an app for bug reporting that has multiple rich text fields (“steps to reproduce”, “expected behavior”, and “actual behavior”). I’d like a form view for this type that lets me enforce that users must fill out these fields in order to create a new a bug report.
2 Likes
Possible workaround? (Note: I haven’t tried this)
Third party form builder that you integrate with your Bug Reporting app called ‘Bug Reporting Admin’ for example that you restrict access to so only you can view. You’d then create another Bug Reporting app that your staff would view and use the lookup fields to pull the information from the app they cannot access, into the app they can only view and not edit as they’re lookup fields.
This would force them to use your form from a third party such as Powr or Jotform etc where you can force them to fill in specific fields and they have a HUGE amount of features that could make your form better than any software a project management software could do.
You could then add note fields, status fields such as ‘In progress’, ‘Done’, ‘Referred Higher’, ‘Awaiting IT Response’ etc and you could even make it a board view that you move across and add notes as you go, all the while your staff cannot edit the original bug report details only amend them in the notes or request that you (or managers) edit them yourself. This way sounds much better to me!
If @mdubakov and his team ever implement the embed feature to the document view (which would be incredible albeit they have a lot to do) you could embed the form into your document inside Fibery so you’d never have to change tabs to do it.
Hope I’ve helped!
1 Like
I definitely would love to see required fields native in Fibery. Either via a form view that would require certain fields on form creation, or possibly if there is soon a way to create an entity via a “big plus sign” leading to a modal with entity details to be filled out. This 2nd option is similar to how you create an issue in Jira, which has certain fields required.
Thanks guys!
3 Likes
I see Fibery as having a huge potential to disrupt Salesforce for smaller companies and teams. This would be an essential feature in order to compete there. I’m hoping this becomes a bigger priority as the team grows and should they acquire more VC
2 Likes
And this is another great CRM reference, I second this, too!
In fact, we have a great chance to get ahead of Notion, which has been responding to the request since Dec. 18! –
They even suggest here to use Typeform, then import the data via .csv, talk about a lot of manual work!
Could probably get a lot of converts if we could simply have an Entity creation inside Fibery that would require some fields. I assume if that was built, it wouldn’t be a stretch to expose externally and get a proper form that would dump data directly into Fibery. And that’s where the Notion use case would be met.
1 Like
The Required Fields aspect of this request is becoming a greater need for my team. We are using liberally multiple Rich Text fields (which is great you can build entities with as many of these as you’d like!), and some are required. But it’s hard for my team to remember to fill them out.
I wanted to add to this just so it’s clear another good post about the need which is in another request - invoking a Fibery-esque transposing of that:
which incidentally uses the cool “quote” feature here in Discourse… that @Oshyan suggested might be useful to see come over to Fibery, too:
2 Likes
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. 
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:
- 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. )
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