Password
A field whose contents are masked as they are typed.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → Security:
- Authentication Methods — how user passwords are actually handled
- Permissions — restricting who can see a secret
Masking is presentation
The dots hide the value from somebody looking over a shoulder. That is a real benefit and it is the only one the masking itself provides — it says nothing about how the value is stored or who can read it later.
Not for your users’ passwords
The most important thing on this page. Sign-in passwords are handled by the platform's own authentication, which hashes them, applies your policy, and never stores anything reversible.
Creating a password field on a datastore to hold user passwords bypasses all of that. Do not do it — and if you find one in an existing application, treat it as something to remove rather than to improve.
What it is legitimately for
- A credential for a third-party system that your application must present.
- A shared secret for an integration.
- Anything a user should be able to enter without bystanders reading it.
Encrypt it, and restrict it
If the value is a real secret, two things follow. Turn on field encryption so it is not readable in a database backup, and use field security so only the people who need it can see it at all.
A masked field with neither is a secret in plain text with a cosmetic covering, which is a worse position than storing it openly and knowing you have.
Prefer not storing it
The best handling of a credential is not to hold one. Where the platform offers a proper connection type — a data source, an API client, a mail account — use it, because those store credentials encrypted and are built for rotation.
A password field is what you reach for when nothing better fits, not the first answer.
Masking hurts accuracy
People mistype what they cannot see, and a mistyped credential fails somewhere else entirely, often much later. Where the value is not secret from the person entering it, consider whether masking is helping or just making entry error-prone.
Think about the audit trail
Changes are recorded with before-and-after values like any field. For a genuine secret that means the audit trail contains it — worth knowing when deciding who may read the audit log for that datastore.
Worked example
An integration datastore holds a partner's SFTP credential in a password field, encrypted, with field security limiting it to two administrators. User sign-in for the same application uses the platform's own authentication with passkeys — no password field is involved anywhere in it.
Recommendations
- Never use it for sign-in passwords.
- Encrypt and restrict anything genuinely secret.
- Prefer a proper connection type over storing a credential.
- Consider who can read the audit trail for that field.