Password Fields

A Password field stores a login password on a record. It exists for portals, where the people signing in are your own clients and each of them is a record in one of your tables.

It is the only field in InfoLobby you can write but never read. The value is hashed the moment you save it, and nothing anywhere gives it back: not the grid, not the record screen, not an export, not the API, not an automation, not the AI assistant. Everywhere a value would normally appear, you get dots.

Adding one

In a table's Configure screen, open the Fields tab, click Add Field, and choose Password. The only setting is:

  • Min Length: the shortest password you will accept. Defaults to 8.

A password field is never marked Required. Requiring one would block you from creating records at all, and it would block ordinary edits to records that already exist (see "Editing a record" below).

Setting a password

Type the new password into the box and save. That is the whole flow.

A record that has a password shows a row of dots, so you can see at a glance that one is set. The dots are not the password and they are not its length. They are a fixed placeholder, and there is nothing behind them to reveal: start typing and they give way to what you type, which becomes the new password when you save.

A record with no password shows an empty box reading Set a password instead.

Underneath the box you will see either A password is set or No password set, along with the minimum length. That is as much as anyone gets to know.

Editing a record

Not typing anything means "keep the current password". It never means "clear it".

This matters more than it sounds. Every time you edit a record you are also saving the password field, and you will almost never be changing the password while you do it. If an untouched box meant "clear", editing somebody's phone number would lock them out of your portal.

So:

  • Leave the box alone to change nothing.
  • Type a new password to replace the old one.

The same is true through the API and in automations: sending an empty value for a password field leaves the stored password alone.

There is no way to clear a password back to nothing once one is set. If somebody should lose access, remove or deactivate their record rather than blanking the field.

You cannot look one up

If a client forgets their password, you cannot tell them what it is. Nobody can, including us. Set them a new one and tell them what you set, or use your portal's password reset if you have one turned on.

This is not a limitation we could lift with more effort. A password that can be read back is a password that leaks: through an export somebody emails, through a screen someone is sharing, through an automation that posts a record to another service, or through the AI assistant, which would be sending your clients' credentials to a third party every time it read a record.

Where password fields do not appear

Because the value is a credential rather than data, the field is deliberately absent from several places:

  • Web forms. You cannot put a password field on a form. Letting strangers on the internet set a password needs a signup screen with the protections that belong around one, which is a portal's job, not a form's.
  • Public embeds. The column is not published at all.
  • Exports. A spreadsheet export leaves the column out. Nothing about who does or does not have a password belongs in a file on somebody's laptop.
  • Imports. A spreadsheet cannot set a password.
  • Filters and search. You cannot filter a view or search on a password field, and it is not offered as a report grouping. Filtering on a stored password is a way of guessing it one comparison at a time.

Copying and moving records

  • Copying a record starts the copy with no password. A credential belongs to one person, so it is not carried into a duplicate.
  • Exporting and re-importing a workspace keeps passwords working. Your own backup is your own data, and a restore where every client had been locked out would not be a restore.
  • App Market packs and reseller templates have passwords stripped out. Those archives go to other people, so they must never carry live credentials.

In automations

An automation can set a password, for example generating one for a new client. Reading one gives dots, exactly as everywhere else, so {{record.password}} in an email will not send anybody their password.

To send someone a password, have the automation generate the value, use it in the email, and write it to the field in the same run. Once it is saved, it is gone.

What this does not protect against

Hashing protects the password if your data is ever exposed. It does not stop somebody who can already edit your records from setting a password and signing in as that client. Anyone with Read & Write access to the table can do that.

If that matters for your setup, mark the field Admin Only so only workspace admins can change it, and keep an eye on who has admin.