Required fields in Detail View

1

Is there any development for using required fields in Detail view?

The best I could think of is Button (Open row) > which opens a Canvas row in dummy table > Embedded link to a published form in the Canvas row. Works, but is kind of clumsy because of the sizing of the embed and taking too much screen space.

This approach offers another benefit which ideally would be native to Coda - using different Detail/Form views for different buttons.

Is there any other neat resolution of required fields?

1 Like
2

Hey @Stefan_Stoyanov,

Thanks for writing in. If i’m understanding you correctly, you could build out a detail layout view of a table, that then has a “submit” button at the end of it, that when pressed will push each response into a correct table. But you can add to the Disable IF section of the button all the fields that are required not to be blank, and then make sure mark them as Required.

Hopefully that helps!

Best,
Dan

1 Like
3

Dan, thanks for your response. However, if the button is Add New Row it would add the row on clicking it with or without the “Submit” button. Of course, automation can clean the table from incomplete entries but that doesn’t help in cases like internet crash and incomplete entry (there is no cashing of the fill-in information for Detail view).

4

Hey @Stefan_Stoyanov,

If you have an Add New Row button, it will add new rows, but the rows that come up will not be submitted until that submit button is clicked. My thought here is you could add a check column that is hidden that will be selected when the row is submitted, and then filtered out of view. This way any “form” that wasn’t sent would sit in the table unfiltered.

Additionally, you could then set up a notification of the person who filled out the form to be pinged through Slack or Email that says “Hey, it looks like you started a report but didn’t finish it. You can find that Here: . Can you update or delete this for us?”

Don’t know if that helps!

Best,
Dan

2 Likes
5

I tend to take a two prong approach.

  • I have a formula field that calculates if data entry is complete and valid. (Simply having a value in required fields is not sufficient because different fields are required based on the selection of other fields.) This formula field says what any issues are—fields missing data, fields with data that is out of range, or fields with incompatible data, etc.
  • Rows have a single-select for the lifecycle. The lifecycle starts out in a “data entry” stage. The button or automation used to advance the row to the next stage is only enabled if the above formula field is empty.

There probably are lots of other creative solutions. This is just one that has worked well for me.

2 Likes
6

Another pattern is using a separate entry table. So clicking Add New Row actually adds a row to the form table, which you can wrangle how you want, and then the user clicking save puts the values into the real table. You can also have a cancel button which deletes the row, and the user closing the modal will also cancel (which I think matches user expectation).

Not that different from @Kuovonne ’s approach with a single table and a “data entry” status (and maybe single table is better in most cases?), but another option.

2 Likes
7

Here are my reasons why I prefer a single table:

  • If you have two tables, any field changes need to be maintained in two places. For example, adding or removing a single select choice.
  • Any fields that are linked relations have more linked relations, making the schema more complex.
  • Many of my records have a lifecycle anyway, so one more “data entry” lifecycle option isn’t a big deal.
  • My data validation formulas still apply after the record moves into a future stage. For example, it is possible for someone to change data after the record is past the initial data entry stage to that the data ends up being invalid–someone deletes a required name or changes a date to an invalid date. Having fewer data validation formulas is easier to maintain, and makes it easier to surface data validation issues later.
3 Likes
8

Yeah I think single table is usually better.

The one thing I like about separate table is being able to give people extra contextual explanation through different column names, when they’re “filling out the form” initially, while keeping views of already-entered data uncluttered.

9

Interesting point. I guess I haven’t come across this use case yet. So far having different views for data entry versus other stages has been sufficient, along with specifying the long name / description in the details view.

10

Yeah when they added this, it took care of a pretty decent amount of the usefulness of my multi-table method.

11

All these clunky workarounds should make it clear we need required fields…

1 Like
12

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.