Hiding possible link values from FORM user

Let’s say that’s a SSN field.

Do you want to hide the field or allow users to enter their SSN without being able to pick from the list of existing SSNs in the other table?

The second. Enter their SSN without seeing all the SSNs in the pick list.

Rather than linking to that field in the column, you could reverse it. Here’s what I mean:

Current Setup
Table 1

• Name
• Link to SSN
  …

Table 2

• SSN
  …

With this setup, when you create a form view of Table 1, you’ll see SSN as a select box, which you don’t want.

New Setup
Table 1

• Name
• SSN
  …

Table 2

• Link to SSN
  …

This way, when you create the form view of Table 1, both will be inputs, and because of the link you’ve setup, the other table will get populated once the data’s entered.

Does that help or is there a specific reason why you need the original field in the second table?

Thank you, Daniel. I’ll spend more time thinking your reverse design.
BTW, if you look st a recent posting,“Signup Sheets”, you have a similar requirement. But, I don’t want the select-from-names because the signup-era will be able to see all the other participants’ names.

I’m not sure exactly what you mean. If you have a sample base you could show me I’m happy to take a look :grinning_face_with_big_eyes:

Sent link to the example AT via OM

This is an interesting problem… because it can’t actually be encountered in Airtable due to a restriction in its forms.

The key blocking issue is you can’t create new linked field entries in a form. A straightforward implementation would obviate the security concern: users of the form can only select from what’s already there – Table 2 would just need to contain a billion entries, one for each possible SSN.

A Free Plan–friendly solution requires manual (or Zapier-automated) intervention, and would look something like this (I’ve labeled the field types for clarity):

Table 1

• [PRIMARY] Name
• [NUMBER] Submitted SSN
• [LINKED FIELD] Link to Table 2, displays Primary Field, {SSN}
  …

Table 2

• [PRIMARY FIELD] SSN
• [LINKED FIELD] Link to Table 1, displays Primary Field, {Name}
  …

Form (Table 1)

• [PRIMARY] Name
• [NUMBER] Submitted SSN

When a user fills out the form, instead of entering their SSN into the linked field, they’d enter it into a normal number field. You then copy and paste the value manually into {Link to Table 2}.* This has a side benefit of identifying duplicates ({Link to Table 1} will have more than one linked record).

*Or you can use Zapier to automate this step by first creating a view with the following filters:

• {Submitted SSN} is not empty, and
• {Link to Table 2} is empty

Then in Zapier, set a Zap to fire every time a record appears in this view.

As an aside, the diagram Danny gives for the Current Setup doesn’t paint a complete picture, since it’s missing one crucial field: the linked field on Table 2 that references Table 1.

Table 1

• [PRIMARY] Name
• [LINKED FIELD] Link to Table 2, displays Primary Field, {SSN}
  …

Table 2

• [PRIMARY FIELD] SSN
• [LINKED FIELD] Link to Table 1, displays Primary Field, {Name}
  …

Table 2 records can only be linked via the Table 1 linked field – Table 2 cannot just “listen” to an arbitrary field (the two linked fields above are created simultaneously, and will remain even if the link is broken (just converted to a short text field)). Thus, the Table 1 Form must include {Link to Table 2} (for the setup in the original question as stated). Otherwise, no link between a Table 1 submission and a Table 2 record will be created, and (in theory) Table 2 will not be populated with new SSNs if the linked record does not already exist.

We’ve built a solution for this :tada:

Check out this video where I showcase the tool: