The usual approach to sensitive fields is to encrypt them and then remember to exclude them everywhere — from search, from exports, from AI retrieval, from the next feature somebody writes. BuildWithHQ removes the need to remember: the searchable value simply is not there.
Supported Contact secure fields combine a field definition, encrypted storage and authorized reveal. Confirm the enabled field and key-protection setup before storing sensitive data.
The encrypted value, its nonce, its key identifier, and its algorithm are stored together, and a database constraint makes storing both plaintext and ciphertext impossible.
Encrypted values require configured server-side key protection. Do not assume that another module supports reveal just because it exposes a secure-field definition.
Reading the value is a separate, authorized operation. Rendering a page never triggers decryption as a side effect.
This is a small idea with a large consequence.
When a field is encrypted, the plaintext column is null. Nothing is stored there. That means every path that reads plaintext — keyword search, list views, exports, embedding generation for AI retrieval — finds nothing, with no special-case code in any of them.
The alternative, which most systems use, is to store the plaintext and then filter it out of each read path. That works until the eleventh read path, written eighteen months later by someone who did not know the rule existed.
Security that depends on every future developer remembering a rule eventually fails. Security enforced by a database constraint does not.
A reveal is an explicit request, authorized against the same permission function as everything else, and recorded whether it succeeds or fails. Decryption happens in the application tier, per principal, and the page layout can never cause it — a masked placeholder is what the renderer sees.
Encrypted values are excluded from plaintext search and embedding input. Record, field and AI-read permissions still apply to other content; avoid copying sensitive values into ordinary fields or attachments.
Not by its value, and that is deliberate. If a field must be searchable, it should not be encrypted at rest in this way — the two requirements genuinely conflict.
The current user must pass the record and secure-field reveal authorization checks. Reveal outcomes are audited; ordinary record visibility alone is not a blanket decryption grant.
Ordinary masked display does not decrypt the value. An explicit authorized reveal performs additional work; its timing depends on the configured service and key protection.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docs