Render Text Formula Output as Markdown Optionally

Ideas & Features
1

Original post reframed

Add markdown format option for string/text formula fields, leading to their output being rendered as markdown.

My bases for this request

  1. Fibery’s current text format options of URL, Email & Phone, already show your team’s acknowledgment that users may want text formatted as an http(s):, mailto:, or tel: link, so proposing full Markdown support isn’t a sudden or unfounded leap. This also tells me it will be a much less complicated development/implementation path, than something like allowing formulas to generate Rich Text fields.
  2. Platforms that were traditionally plain-text (WhatsApp, Telegram, Slack, MS Teams Chat, and Zoom Chat) have all built Markdown or Markdown-like syntax into their applications.
  3. A single platform might add such a feature because of developer- or product-centric design habits. But when so many converge on it, for me, that means the feature is indeed widely used and proven to improve everyday user experience
  4. As a result, where plain-text used to be, now formatted text (bold, italics, lists, …) is replacing it as the baseline in everyday communication for hundreds of millions of users formatting daily with Markdown features, without knowing the name “Markdown.”
  5. Though not ubiquitous in improving prompt effectiveness (broader prompt formatting study by Microsoft and MIT), the use of markdown in Generative AI applications exists both for input and output.

Use cases

In some cases, Markdown output:

  • Blends important info with context while allowing distinction, so you see both at once, but can differentiate them.
  • Makes lists, and search results faster to scan.
  • Reduces clutter through one compact field that carries detail without deep navigation.
  • Highlights key info right where (no click) and when (not stale) you look.

For example:

  • In a formula name/label field:
    • Highlight name of a contact, e.g. “[active] Pedro Glorias @ Microsoft Inc.”
    • Highlight number of attendees of an event, distinguish statuses, e.g. “[cancelled] ABC Conference for 50 pax on 2025-09-01”
    • Many more such composite, compact labels with highlights.
  • In a formula field that returns text:
    • Aggregate emails, their function (e.g. main, personal, accounting, etc.) into one single clickable field, overcoming current limitations of one email/phone/link per field.
    • Generate live (non-button, non-automation), copiable message, email and AI prompt templates.
    • Generate live (non-button, non-automation) summaries, presentation scripts, etc. that are easy to read, and even copy to a rich text field.

I understand that some of these could be handled with more advanced features such as Rich Text generation from Formula fields, but my request is an incremental feature on the way to that end.

Original post

Continuing the discussion from Rich Text field from a Formula:

Though composable formula-generated rich text fields would be nice, my use case would be handled by allowing the output of text fields (formula or otherwise) to contain markdown.

The way I see it, we would have an extra format for text fields/formulas:

  • :sparkles: markdown
  • Text
  • URL
  • Email
  • Phone

This would allow for example our Contact details (Looked up from Roles that are related to Contact Info) to be formatted and usable with clicks, if the following output of the aggregation formula were treated as Markdown:

image
image508×469 13.5 KB

But currently, I have settled for the following:

image
image466×545 11.9 KB

There are many more use cases, that across the past decade and a half we have implemented in other systems for clients, e.g.:

  • generating copiable message templates for email, since most email clients require HTML pasting to retain formatting.
  • aggregating info into one field with links to underlying related entities.
  • aggregating relate contact info with clickable email and phone fields.
  • even clickable map routes (mostly Google Maps) generated from related stops with a description for each stop.
2 Likes
2

I’ve been looking for something like this, to create client agreement, I have a template, but Sometimes a need to be able to change things. Markdown in HTML would be amazing. Or maybe a way to have formulas populate data.

3

I’m not sure I get the feature request.
Are you asking for an option that the user can set for a (simple) text field which would render any typed content in accordance with markdown rules?

In other words, for an editable field, when the user is typing, they can type the following:

# Heading
- list item one

and once they are done typing, the field gets displayed as:

Heading

  • list item one

Tbh, the use cases you describe aren’t clear to me, or at least I don’t understand what is desired that can’t already be achieved using rules and rich text fields, or relation fields.

4

Sounds like an automation rule.

Isn’t this exactly what relation fields do?

5

Hi Chris, thanks for your responses. I have reframed the request, rewriting it, to avoid confusion with workarounds due to relationship/lookup/rollup limitations.

Below I will answer your messages.

Not exactly. That is already done in the Rich Text field. I was referring to exactly what the current format options do for a text field or text formula, which is “taking the underlying data and presenting it in a different format when loaded”.

I have narrowed the request to string/text formula fields, to avoid the input formatting hurdle you are mentioning. In other words, only formula fields that generate string/text output should be able to choose the Markdown format for their output.

Yes, perhaps in some use cases, whereas in others a live, no-click version would serve to improve the UX. For example we have a event message that pulls in data from many different tables such as attendees, allergies, reservation statuses, and creates a block of text copiable as a message. With automation this would be running automations for every little change, since things form allergies to number of attendees and reservation statuses can be changed by any number of operators. Do you :slightly_smiling_face: believe this would be better served as an automation, even though the formula field aggregates everything perfectly, only because markdown formatting is not supported by the formula field?

Yes, you are right. In fact that field in my post aggregates the contact details from relation fields.

But at the risk of diverging from the main topic of this post, I would like to explain why we have chosen that path. Given the current (justifiable for an active roadmap) limitations, it is a visually and navigationally complex to get the contact details of a contact in our setup, which is as follows:

  • Contacts table
  • Roles table connecting a subject contact an object contact through a role, e.g. Pedro is employee of ABC, Inc. Lack of polymorphic relations has led us to include a hack of “self” Role, for use in the Details table, below.
  • Details table connecting a contact detail (Email, Phone, Address, Link) to a Role, together with attributes such as consent status and date, function/use/purpose of the detail e.g. for accounting, logistics, personal, etc. To avoid further nesting, and possible future feature conflicts for specialised text fields, we have decided to have four columns in this table, only one of which should be used in any given row: Email, Phone, Link, Address.

In this scenario, we have detailed context, and audit trails for contact Details, and Roles, but the UX of find all the details and deciding which one to use gets vastly improved by a aggregation formula, like in my original post.

6

I’m curious what purpose this ‘event message’ is used for? Is it supposed to act as a quick summary for anyone to see info from a variety of linked data (in which case I wonder if some form of entity view ‘dashboard layout’ might suit your needs)?

Or is it to be used in some automation, later down the line, e.g. ‘Email the event message summary’?

Just to clarify, when you use the word ‘table’ do you mean ‘database’ (as Fibery uses the term)?

So you have

DBs:

Contacts, Roles, Details, Companies?

What are the relations and their cardinality?

What are/were the limitations you are experiencing? For example, I don’t get this:

Overall, I think that this:

is the root problem to be solved, and I don’t know if we should be jumping to ‘format simple text field as markdown’ as the solution.

7

Hi. Thanks again for your response.

Thanks for seeking interim alternatives. The dashboard layout for entity view would be a very nice addition, but a markdown format for a formula field, would still be the way to compose a formatted/pseudo-rich text field for other purposes.

As for automations, they would also help, though they would not address one of the main points of Markdown rendering of Text Formulas, which is improving visual UX.

For instance, almost all of our databases (and even our clients’ databases in other systems) use dynamic labels (formula-generated names in Fibery) to:

  • In global search, as well as when trying to pick it inside a relation field search (since relation field entity pickers are cramped across all platforms):
    • Quickly pin-point the right entity.
    • Easily filter the results using context, e.g. “supp ABC” to find the supplier entity of ABC, not the many people who work there, or “eve cancel 20250901” to find the event cancelled on 20250901, etc.
  • Quickly develop understanding of an entity in a compact visual zone, without the need to enter an entity or scroll a table horizontally.
  • Copy the label to messages, emails, and external systems to ensure they reference the correct event or any other entity.

Yes, sorry about that. :smiling_face: When I say table I mean Database in Fibery. It has been hard to adopt that word, since it literally means a collection of tables, haha.

Without taking us off topic, I would say that the relation aggregation is one of the many different reasons behind the markdown formatting. I would even invite you to ignore that use case, and focus on the in-line formatting of things like labels (formula-generated names) since the main point here, is allowing a visual UI rendering of Markdown.

I agree, but as a developer of almost 25+ years, I love prioritising features that have the mechanism already in place (i.e. the Phone, Email, URL formats of Text Formulas), and that would not only introduce a new feature, i.e. highlighting/formatting just like in Whatsapp/etc. but also stand in for longer-term features while they are being developed, such as an improved multi-hop, many-to-many with junction attributes, relation UX.

8

We hope to make improvements to search, so that it is not necessary to include a load of field data into the name in order to make sure the item you are looking for is identifiable/informative.

If this is the primary need, then maybe there are other requests that would benefit you, e.g.

TLDR, I am not trying to deliberately try and dissuade you of the need for markdown in simple text formulas, but rather focussing on what problem we might be solving if we supported it.

Appreciate the engagement :+1:

At the moment, there are probably many technical limitations to the simple text field which would make this a very complex feature to implement - it is quite different to the phone, email, url formatting.

For example, we don’t really support markdown rendering anywhere except rich-text fields/documents. It would mean introducing a prosemirror-like functionality for every UI component in the workspace that is currently used to displaying simple text (± hyperlink).

1 Like
9

p.s. if you want to get a feel for how we prioritise, these are nice reads:

10

Thank you for all of these amazing resources and your engagement! :heart:

Absolutely, I understand. I have been in your shoes, and everybody considers their feature request a bug that must have been solved yesterday :laughing: .

Thank you so very much! I will study them. But I must say that in the past few decades, I have rarely seen such a transparent and active roadmap as Fibery’s. Congratulatons on that front! :clap:

1 Like
11

I wanted to clarify that to address your extremely valid concern (text in bold above), I had changed my initial request to be limited to only text formula fields, meaning it only affects output, if the formula writer chooses so.

In other words, there is no change to any input, since the formula generates the markdown, and the output uses the same mechanism it does for URL, Phone, Email formats to transform the output.

:thought_balloon: You could even limit it to your own subset of markdown to make the transformation less resource-heavy, e.g. bold, italic, strikethrough, and maybe lists (Like Whatsapp for example).

12

I think we understand each other :crossed_fingers: but the problem is that even just adding support for rendering bold, italic, strikethrough etc. will affect every UI component where a simple text formula field might be displayed, and it would be a significantly greater undertaking than what we do for URL, phone and email.
The URL, phone and email format options are simply adding a static hyperlink functionality to the entire text string, whereas markdown rendering would require a whole new set of dynamic UI components. It would not be ‘the same mechanism’.

13

Thanks for the explanation. Yes, I see now. :slight_smile: I thought that the URL, Email and Phone ones were also using components to render the links. No feature is ever as simple as the user thinks, even if the user is a developer, haha!

1 Like