# Render Text Formula Output as Markdown Optionally **URL:** \ **Category:** Ideas & Features\ **Created:** [September 26, 2025, 2:47pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689 "2025-09-26T14:47:28Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 26, 2025, 2:47pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/1 "2025-09-26T14:47:28Z")
## 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](https://arxiv.org/html/2411.10541v1)), 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](https://community.fibery.io/t/rich-text-field-from-a-formula/5223): > > 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: > > - ✨ **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](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/4/4a227640719e941b98827e20338ef3fcb315cf87.png) > > But currently, I have settled for the following: > > ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/d/db379c5341c8a42d64ed7d94bc6078cad5de6a2a.png) > > 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. ---
**Author:** ![Eva\_Folch](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/eva_folch/32/11814_2.png) [@Eva\_Folch](https://community.fibery.io/u/Eva_Folch)\ **Post date:** [September 28, 2025, 6:35pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/2 "2025-09-28T18:35:27Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 28, 2025, 8:25pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/3 "2025-09-28T20:25:11Z")
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: ```auto # 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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 28, 2025, 8:26pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/4 "2025-09-28T20:26:52Z")
> [@Sev](#): > > generating copiable message templates for email, since most email clients require HTML pasting to retain formatting. Sounds like an automation rule. > [@Sev](#): > > aggregating info into one field with links to underlying related entities. > > aggregating relate contact info with clickable email and phone fields. Isn’t this exactly what relation fields do? ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 29, 2025, 11:00am UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/5 "2025-09-29T11:00:08Z")
Hi Chris, thanks for your responses. I have [reframed the request, rewriting it,](#p-36672-original-post-reframed-1) to avoid confusion with workarounds due to relationship/lookup/rollup limitations. Below I will answer your messages. > [@Chr1sG](#): > > 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: > > ```auto > # Heading > - list item one > > ``` > > and once they are done typing, the field gets displayed as: 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. > [@Chr1sG](#): > > Sounds like an automation rule. 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 🙂 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? > [@Chr1sG](#): > > Isn’t this exactly what relation fields do? 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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 29, 2025, 11:56am UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/6 "2025-09-29T11:56:41Z")
> [@Sev](#): > > 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. 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’](https://community.fibery.io/t/what-if-entity-view-was-treated-as-a-dashboard/8322)might suit your needs)? Or is it to be used in some automation, later down the line, e.g. ‘Email the event message summary’? > [@Sev](#): > > 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 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: > [@Sev](#): > > Lack of polymorphic relations has led us to include a hack of “self” Role, for use in the Details table, below. Overall, I think that this: > [@Sev](#): > > the UX of find all the detail 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. ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 29, 2025, 12:18pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/7 "2025-09-29T12:18:40Z")
Hi. Thanks again for your response. > [@Chr1sG](#): > > 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’? 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. > [@Chr1sG](#): > > Just to clarify, when you use the word ‘table’ do you mean ‘database’ (as Fibery uses the term)? Yes, sorry about that. ☺ 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. > [@Chr1sG](#): > > What are/were the limitations you are experiencing? 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. > [@Chr1sG](#): > > 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. 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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 29, 2025, 12:37pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/8 "2025-09-29T12:37:32Z")
> [@Sev](#): > > 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 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. > [@Show fields in search results](https://community.fibery.io/t/show-fields-in-search-results/9673): > > We attach a lot of our data (tasks, wikis, travels, bookings) to a database with projects. It would be great if the default search has a fields option (like most views) so we can show which database an entity belongs to / is linked to. > [@Show lookup fields in certain search fields?](https://community.fibery.io/t/show-lookup-fields-in-certain-search-fields/9193): > > Maybe this is already possible, but I routinely have trouble knowing what precise entity to select in certain search fields, if lots of entities have the same name. Attached is an example. I could obviously label the entities differently, but it would also be great to force a linked lookup field to show in these search fields. My database is such that although there are entity IDs, which is helpful, it isn’t a great solution. I know this is possible in certain other places. But it appears t… > [@Filter search results based on Field Values](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052): > > The more I actually use Fibery day-to-day, the more tasks I complete, and the more “closed” entities I end up with. Yet they all still show up in my searches. This really limits the usefulness of search at times, whether in the Ctrl-K pop-up or in-line entity linking (this is even more of an issue due to [Narrow texts in entity search pop-up make correct selection difficult](https://community.fibery.io/t/narrow-texts-in-entity-search-pop-up-make-correct-selection-difficult/1051). I’m not sure the best way to handle this. I know the “status” is a feature of the Workflow Extension. It seems important e… 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 👍 > [@Sev](#): > > I love prioritising features that have the mechanism already in place 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). ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 29, 2025, 12:39pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/9 "2025-09-29T12:39:47Z")
p.s. if you want to get a feel for how we prioritise, these are nice reads: > **[Use Networks to Prioritize Product Features](https://fibery.io/blog/gems/use-networks-to-prioritize-product-features/)** > > Features prioritization is the hardest problem in product management. Learn how to get better in it using... networks. > **[Enhancing prioritization with networks](https://fibery.io/blog/gems/enhancing-prioritization-with-networks/)** > > Prioritization formulas like RICE measure features in isolation, missing out on powerful network effects. Luckily, there is a fix. ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 29, 2025, 12:44pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/10 "2025-09-29T12:44:33Z")
Thank you for all of these amazing resources and your engagement! ❤ > [@Chr1sG](#): > > 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 👍 Absolutely, I understand. I have been in your shoes, and everybody considers their feature request a bug that must have been solved yesterday 😆 . > [@Chr1sG](#): > > p.s. if you want to get a feel for how we prioritise, these are nice reads: > > [Use Networks to Prioritize Product Features](https://fibery.io/blog/gems/use-networks-to-prioritize-product-features/) 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! 👏 ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 29, 2025, 12:53pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/11 "2025-09-29T12:53:06Z")
> [@Chr1sG](#): > > 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)**. 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. 💭 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). ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [September 29, 2025, 1:04pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/12 "2025-09-29T13:04:38Z")
> [@Sev](#): > > 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. > > 💭 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). I think we understand each other 🤞 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’. ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 29, 2025, 1:21pm UTC](https://community.fibery.io/t/render-text-formula-output-as-markdown-optionally/9689/13 "2025-09-29T13:21:52Z")
> [@Chr1sG](#): > > 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’. Thanks for the explanation. Yes, I see now. 🙂 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!