Forms in Interface Designer

Interface designer is designed for internal users and such the forms must be catered to internal users. Currently, the selection for related linked record is still much basic.

Screenshot 2022-08-18 094756

I do hope it can follow linked record selection in the table where you can see related information.

Screenshot 2022-08-18 094734

2 Likes

Good evening @Emily_Sermons

Further feedback for Forms, importantly for both Interface Forms and View Forms. Currently, it’s not possible for an applicant to be limited in numeric fields to maximum and minimum values.

For example, a number field requesting a value, the applicant can enter any number they wish. The only way an administrator can post-govern this is with an Automation script, such as;

let adjustedQTY = Math.min(Math.max(1, inputConfig.userQTY), 9);

With this above example, if the user enters in 200, then the automation will execute off of a maximum of 9.

Just as important on View Forms;

It feels ugly employing automative hacks when really this range functionality is expected. The applicant has no sense that their value is being mutated in the backend, and can lead to confusing situations due to the lack of Form Feedback (but at least the Automation allows for form execution).

In summary - we really, really need a method to limit user inputs for numeric values for both Interface and View Forms - the Airtable community have been asking this for years now, so I figure now would be the perfect time to implement this feature. :pray:t2:

PS: Please don’t judge me on my example Airtable Base. :lollipop:

1 Like

Good morning @Emily_Sermons ,

I’ve a further request for both Interface Forms and View Forms when working with Linked Fields.

Below shows an example of a Multiselect Field “List” box selection within a Form View;

But with Linked fields, we don’t have such luxuries for list display within Forms (either interface or view forms)

image

Weirdly, there’s the ability to select Linked records during the form creation, but this doesn’t actually result in any feature/function in the final form?

In short, when working with Linked fields, I’d like to see the option given for Tick Box selection.

image

There’s no real “automated” workaround to this problem due to Automations not supporting Field option maintenance (this can only be achieved through a manual script extension).

It would be great to see tick-box / check-box navigation added to Interface and View Forms for Linked Field selection.

Further to my above feedback, could we please have an update on Interface Forms, or Interfaces in general?

1 Like

Two possible solutions:

  1. If you have a modest amount of fields you’d like to prefill, you can add to your Interface the Filter element and the Table element, making sure you allow the Interface users to add new records in the table. When they create a new record, each new record will include the fields as they appear in the filters.

Flaw: If the Interface user edits the filters, they would edit the pre-filled fields as well. Doesn’t seem to be a way to lock the filter. Additionally, if there are a ton of fields, confusing fields, or unsightly/secure fields, you would reveal that information to the user, though I suppose you could have some formula field as the filter to hide what you’re pre-filling or bundle your pre-filled fields, using an automation that states “if {Formula} = 1, then edit xyz fields”. It solves the unsightly issue, but I think interface users have full access to read all of the records’ data anyways through the expanded record view, so perhaps that security issue is unavoidable.

Here’s a look at an example:

Below, in the expanded record view, you can see that the filtered field of {Project}=“Steady Now” is reflected in the new record. Disregard “Standby” as that’s the result of an unrelated Automation.

  1. If certain users use a specific Interface as the only way in which they edit a table’s information, you could create an automation that would “post-fill” the records that they specifically edit (assuming your table has a “Last Modified by” field) to include the information you wish you could pre-fill.

Example: The only way that Derek is accustomed to interacting with the “Assets” table in my base is via the Asset Requester, so I know if he edits any field in an “Assets” record – or, even more granularly, just the X and Y fields in an “Assets” record, which are the ones I have editable in the interface – I can be sure that Derek is editing via the interface, and can post-fill using an Automation that says if X field isn’t empty, Y field isn’t empty, and Derek was the user who it was {Last Modified By}, then I would instruct it to fill whatever other fields in that record accordingly.

Flaw: This would likely mean creating a new interface every time you want to trigger different pre-fills, or working up some convoluted automation schemes that are specific to either specific users or specific combinations of fields that any Interface user filled out. Also, if a user doesn’t ALWAYS use Interfaces to input data, this method would not work.

1 Like

Further Interface Forms feedback. We really need the ability for Automations to handle both View Forms and Interface Forms, giving Automation authors a ‘toggle’ list that allows them to define which forms (either interface or view forms) trigger an Automation.

The inability to program default values is an absolute pain and show stopper. As a workaround, an automation could be employed to fill in the blanks after the fact, but still, it would be most preferable for an Interface form to support both default values AND to have an Automation trigger.

Again, to save on maintenance and the fact that Automations are capped, we should be given the ability to configure an Automation trigger to accept/trigger from multiple types of forms of either View or Interface, and multiple of each.

1 Like