A word processor gets by with one kind of text. A platform that serves real businesses needs twenty kinds of field. The difference between "we can model your workflow" and "we can model your workflow well" is almost always the depth of the property library — the catalogue of building blocks you reach for when defining a type. Over four years of steady additions, ours has grown into something we're genuinely proud of.
The basic end of the palette looks familiar. Short and long text, numbers in several precisions, dates and times in their usual variants, booleans, URLs, emails, phone numbers. Nothing surprising there. But the moment you step past the basics, the library opens up: single- and multi-choice enumerations with their own ordering and color coding; references to other objects, in single or multi form, with reverse-lookup rendering; query-result properties that stay live as the underlying data changes. Each of these sounds small. Together they quietly eliminate a third of the modeling contortions that other platforms force on you.
Media is where the library really earns its keep. Image properties come with automatic thumbnails, lightbox viewing, and configurable compression — not as a separate feature bolted on, but as part of what "add an image field" means. File properties slot cleanly into cloud storage. Rich text supports inline mentions of other users and records. Media-library references let a tenant curate a shared pool of assets and reuse them across many records. None of that has to be reinvented per implementation.
The specialized end of the palette is where we've spent the most care. A country property knows which countries exist and handles localization of their names. A color property gives you a picker rather than a hex field. A phone-input property understands country codes. An icon property lets users pick from a curated library. A star rating gives you the widget people expect. A structured field accepts editable nested data when you genuinely need it. A section heading acts as a layout-only pseudo-property, because sometimes what a form needs is just a break and a label. And a money property carries currency alongside amount, which is the kind of small thing that saves an enormous amount of downstream grief.
What makes the library more than a list of widgets is what every property shares underneath. Each one comes with an editor, a display renderer, a filter UI, permissioning, and visibility rules. Consistency is the real value. You learn one set of conventions, and every property type in the catalogue — old or new, common or specialized — follows them. Users don't relearn the platform every time they encounter a different field.
The payoff shows up the moment you turn a property on. Add an expected delivery date property to the Order type, and that field immediately appears in the create and edit forms with a date picker. It becomes a sortable column in the list view. It's available as a filter in every query against that type. Search respects it. The REST API exposes it. Spreadsheet export formats it. The calendar view can group by it. No further work required — that's the whole point of defining things once in a shared platform.
And for the cases where the built-in renderer isn't quite what you want, the inline expression language and the canvas page builder give you precise control over display and layout. But those are escape hatches, not the common path. Most of the time, the right property type picked from the palette gets the behavior right on the first try.
The property library is a dense topic, and this is only the overview. The form builder and the views articles show how that depth pays off in daily use — which is where the choice of property type most visibly shapes the experience.