Structured data tools are great at columns and terrible at paragraphs. The moment you need something with actual formatting — a property description with headings and bullet points, a service report a customer will read, a proposal with sections and emphasis — the plain-text cell falls apart. So the formatted version ends up living somewhere else: a Google Doc, a PDF, the body of an email you rewrite by hand every time. Your database holds the record, but the content people actually read lives outside it, drifting out of sync.
That is the gap Mulstra just closed. Rich text is now a first-class field type you can add to any object, and the formatted content you write on a record flows straight into the two places it matters most: your automated emails and your public site. Write it once on the record. Render it everywhere, cleanly.
What "rich text" actually means here
This is not a bigger text box. A rich text field stores real structured formatting and renders it faithfully wherever it appears. On any object — units, jobs, clients, articles — you can now add a field that supports:
Headings and subheadings to break long content into scannable sections
Bold and italic emphasis where it carries meaning
Bulleted and numbered lists for specs, steps, and checklists
Links to related pages, documents, or bookings
Callouts for warnings, conditions, or things a reader must not miss
Inline images for a floor plan, a damaged part, or a signed detail
Because it is a field like any other, it sits next to your structured columns — status, price, dates, relations — not in a separate document off to the side. The record is finally complete.
Write once on the record, render everywhere
The point of putting formatted content inside your data is that it stops being a copy. A property manager writing a unit description writes it on the unit record. That same content renders on the public listing page and drops into the "your new home" email a prospect receives after they inquire. One source, three destinations, always consistent.
Your database stops being a place formatted content goes to die and becomes the place it lives.
This is the same principle behind keeping your site in sync with your data: the record is the source of truth, and every surface reads from it. When the description changes, the website and the next email both update. Nobody re-pastes anything. Nobody ships a listing that says one thing on the site and another in the confirmation.
For property managers: listings that read like listings
A unit is more than a price and a photo. It has a story — the light in the mornings, the rebuilt kitchen, the parking situation, the pet policy that has three real conditions attached. In a plain-text field all of that becomes a wall of text or gets abbreviated into nothing.
With rich text, the description on a unit record carries headings for Layout, Amenities, and Terms, a bulleted list of what is included, and a callout for the application requirements. That formatted content renders on the public listing exactly as written, and the same block anchors the automated inquiry-response email. For teams running this at scale, that consistency is the whole game — see how it fits into property management workspaces.
For field service and security firms: reports people trust
A service job report is a customer-facing document whether you treat it like one or not. When a technician closes a job, what the client receives should not look like a raw database dump.
A rich text report field on the job object lets the tech write:
A short summary of what was found
A list of the work performed, itemized
A callout for anything that needs follow-up
Photos of the before and after, inline
That single field renders into the completion email the customer receives and, where relevant, onto a shareable job page — no separate PDF pipeline, no reformatting. The record closes and the polished document already exists. This is the backbone of clean service management workflows.
For agencies and operators: proposals and knowledge bases
The same field type quietly solves two more problems.
Proposals. A deal record can hold a formatted proposal — scope as a numbered list, pricing in a clean table of terms, a callout for what is out of scope. It renders to a client-facing page you send as a link, or into the proposal email itself. When the deal terms change on the record, the document a prospect is looking at changes with it.
Knowledge bases and docs. Internal SOPs, onboarding guides, and policy docs are just records on a "documents" object with a rich text body. They render on an internal site for your team or a public help center for customers, formatted and searchable, without a second tool to maintain.
Why this matters for a structured platform
Plenty of tools do rich text. Plenty of tools do structured data. The rare and useful thing is having both in the same place, where formatted content is a column on your record rather than an attachment bolted onto it.
No more Google Doc that is the "real" version while the database holds a stale summary
No more hand-formatting the same description into every outbound email
No more choosing between data you can query and content that looks presentable
One edit updates the record, the site, and the next automated message at once
Formatted content and structured data were never supposed to live in different tools. Add a rich text field to an object, write the content once, and let it render where your customers actually see it — on the site, in their inbox, on the page you send. That is the whole idea: rich content, finally, across your data.