Form View and required fields

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.


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!


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


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:


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.


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.


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.


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