Email, phone and URL fields

Underneath, all three are the same thing as a text field: one line of plain text in a real Postgres column. The type declares what the text is supposed to be — an email address, a phone number, a web address — and that declaration is what buys the small manners around it.

In the field list they're called Email, Phone and Web address.

Make one

1. Open the field menu and choose Email, Phone or Web address.
2. Name it.
3. If no two records should share a value — one row per address, say — turn on Require unique values now. It can only be set at creation.

There are no other settings. The type is the setting.

Marked, never blocked

Tabla checks the shape of what you type, and the check never stops a save. A value that doesn't look right gets a small wine-colored dot in the corner of the cell — in the grid and in the record panel, where it carries the tooltip "Doesn't look right for this field". Fix it whenever; the value is stored either way.

The checks are loose on purpose:

• Email wants something@something.something.
• Web address wants a dot somewhere — https:// is not required.
• Phone is only flagged when it contains no digits at all. Phone formats are chaos, and pretending otherwise loses real numbers.

An empty cell is always fine.

This is the honest trade: a strict validator would reject the odd-but-real value someone pasted from an email signature. A marker tells you where to look without deciding for you.

Where they become clickable

A URL field is a link inside the app. The address draws in link blue, underlines when the pointer is over the text itself, and opens in a new tab when you click it. The clickable part is the address, not the whole cell: click the space beside it and you simply select the cell, so a column of links still behaves like a column. Enter — or a second click — opens the editor to change the address, exactly as it does everywhere else. Only http and https addresses open, and a bare tabladb.com is read as https://tabladb.com. In the expanded record the box stays an ordinary editable one, with a small open button beside it.

Email and phone fields read as plain text inside the app. Clicking a cell selects it — it never navigates, so you can't fire up your mail client by mis-clicking a column of addresses.

On a public view link, an email gets the same manners: it renders as a mail link, and a web address renders as a link that opens in a new tab. Phone numbers are not click-to-call anywhere in Tabla today.

If what you want is a button that opens https://wa.me/{Phone} for the row you're on, that exists — it's a button field with a URL template.

Filtering, sorting, searching

All three filter like text (is, contains, is empty and so on), sort alphabetically, and are matched by the search box. Filtering Email contains @gmail. is a fine way to find every Gmail customer.

Over the API

Plain JSON strings, under the field's name. From the demo shop's Customers table:

{
  "fields": {
    "Name": "Nour El-Sayed",
    "Email": "nour.elsayed@example.com",
    "Phone": "+20 100 555 0101"
  }
}

Writes accept any string — the API applies the same never-block rule as the screen, so an integration can't be rejected over a formatting opinion. See /docs/api for the write shapes.

Changing your mind

Email, phone, web address, and single line text all share the same storage, so converting between them is free — nothing is rewritten, the same values wear a different label.

When you actually want a different field

• A column of teammates' emails that you filter by and assign work with is a member field — it stores the email too, but picks from the database's member list and shows names and avatars.
• An email address that comes with a name, a phone and order history is a Customers table, and the field you want here is a link to it. One fact per place.