sveltekit-admin inspects each field’s Prisma type to decide how to render it in create/edit forms, and how to convert what was submitted back into a value for the column.
Supported field types
Relations are not in this table — a foreign key is rendered from the relation graph, not from its scalar’s type. See Relations.
What an empty field writes
A field that is present in the submitted form but left empty writes null,
whatever its type. A field that is absent from the submission writes
nothing at all, and the column keeps its current value.
That distinction is what separates “the user cleared this” from “this was never
submitted”. A readonly field, a field hidden through models[].hidden, and a
column with a @default (which the create form does not render) all fall in the
second case.
If the column is declared non-nullable, an empty value is refused with a 422 and <field> is required shown on the field itself — the form comes back with
everything you typed still in place. Two exceptions, both deliberate:
- a column filled in by
models[].scopeis imposed by the server rather than refused, so a model whose tenant column is required and visible stays creatable from the admin; - an empty required relation is reported on the relation (
author is required), not on its scalar (authorId).
Values that cannot be converted
A value that cannot be turned into the column’s type — for example unparseable
JSON, or a numeric value that produces NaN — is refused the same way, with <field>: invalid value on the field. Nothing is written.
Numeric values currently use JavaScript parseInt/parseFloat; malformed
partial strings such as 12abc may therefore be coerced to 12 rather than
rejected. Invalid DateTime text is passed through to the adapter and may be
rejected there. Treat these as current conversion limitations, not strict input
validation.
Types the admin does not edit
Bytes is not rendered in forms. There is no meaningful HTML input for
binary data, and the text input it used to fall back to could never work: the
driver expects a Uint8Array and receives a string. A model with a required Bytes column cannot be created from the admin — manage that column from your
own application code.
Two precision limits worth knowing, since neither raises an error:
BigIntgoes throughparseInt, so a value above2^53 - 1(9007199254740991) loses precision on its way to the column. Values within that range are exact.Decimalgoes throughparseFloat, so it is subject to the usual binary floating-point rounding. If you are storing money and need exact decimal semantics, do not edit that column from the admin.
Automatic hiding of sensitive fields
Any field whose name contains password, hash, secret or token (case-insensitive) is treated as sensitive. This covers hashedPassword, passwordHash and refreshToken with no configuration.
- Sensitive-looking
Stringcolumns are excluded by default from list views, search, filters, audit payloads and edit forms. An explicitlistFieldsentry can override a false positive for list display, buthiddenalways wins. Sensitive values still remain excluded from search, filters and audit payloads. The create form still offers the field because nothing is stored yet to leak. - Only
Stringcolumns are affected. The match is on substrings, so without that restriction anIntnamedtokenCountorhashtagCountwould have become uneditable. Those stay visible and editable. - If the heuristic gets a
Stringfield wrong, list it explicitly in that model’slistFields(see Model Configuration) to bring the column back in list views. Usemodels[].hiddento remove a field from the admin entirely, everywhere.
The admin writes what is typed straight to the column, with no hashing.
Setting a password from the create form stores it in plaintext, which will not
match an application using bcrypt or better-auth. Put the field in models[].hidden and manage credentials in your own app.