It’s been rumbling on for years, but the compatibility between Softr’s long, rich text editing to Airtable long, rich text fields still seems incompatible. Yes, rich text editor in Softr is set to on. But it still doesn’t harmonise with Airtable, basically showing Softr edits as correct in Softr, but corrupting Airtable’s source of truth rich text formatted data, because Airtable has it’s own weird proprietary markdown rich text method, and doesn’t like Softr’s incoming html changes.
Softr is my user front end for inputs, and Airtable is source of truth and delivers to PDF generator. The issue and frustration happens whenever an edit is made in Softr to rich text, causing corruption of line breaks and bullets/lists in particular, and Airtable has no support for underline.
One method suggested by AI is to have two fields in Airtable… one for Softr’s incoming HTML, and one for Airtable’s own mark down, and for a script to interpret the HTML into Airtable’s own markdown. Has anyone done this successfully, and does such a script exist that actually knows Airtable’s quirky markdown? Or is it Airtable’s secret markdown source they don’t want to share with anyone? It really can’t be that complicated can it? Anything I am missing, as so few seem to complain about it?! Thanks.
You’re not missing anything, the two formats just don’t map cleanly. The two-field idea is what I’d do too: let Softr write only into a plain long text field that holds the HTML, and have an Airtable automation (trigger on that field changing) run a small script that converts it into the rich text field. Airtable’s rich text is basically markdown, so bold, italics, bullets, numbered lists and line breaks translate fine. Underline has no equivalent there, so you have to decide whether to drop it or turn it into bold.
Point the PDF generator at the rich text field and nothing downstream sees the HTML. Because the automation only watches the HTML field, it won’t loop.
Thanks for the reply, appreciated. As you can imagine, I’ve done a thorough research into this. Softr uses HTML and Airtable uses proprietary markdown for rich text which in itself isn’t even conversant with standard markdown. It’s really frustrating. So, I’ve had to create an automation script that converts the Softr HTML to Airtable’s markdown in a separate field. The issue here is that it uses a lot of automation slots for the conversion process and I have a lot of Rich Text fields. The options here are to write a script that watches all the required fields in a table rather than per field. The other issue here is that once the HTML > Markdown conversion happens, any further edits to the markdown field (which you shouldn’t do) will result in it being overwritten if that field is updated in Softr later on. It basically an awful workaround and last resort. The best solution is to run those fields only in Softr, but that takes you out of Airtable. Overall, my wish is for a universal rich text editor that stops this being a headache. But that will never happen it seems. It’s one of those issues you only discover later in the process. It’s no issue for standard data, but in my case, where there’s lots of written documentation, I am left with the ultimate compromise… allow only plain text for most long text unless fundamentally it needs Rich Text. Sigh.
We ran into this with a client too. The two field approach is the one that held up. Keep Softr’s HTML as the edit layer and run an Airtable automation to convert it into Airtable’s own markdown, so the PDF generator only reads the clean field.
On the slots: you don’t need one automation per field. Use a single “When record updated” automation with all the HTML fields under “Fields to watch”, pass the record ID into one script, and let the script loop over a list of HTML-to-rich-text field pairs. For each pair it keeps a short hash of the HTML it last converted (a hidden text field per pair, or one JSON field for all of them) and only converts and writes when the current HTML no longer matches that hash. That also takes care of your overwrite problem: if Softr saves the record without that particular text actually changing, the hash still matches and any manual tweak in the rich text field stays put. It only gets replaced when someone really edits that text in Softr, which is what you’d want anyway. The script only writes to fields the trigger doesn’t watch, so it won’t loop. If you’d rather not build and maintain this yourself, I’m happy to set it up as a small fixed-scope job, handled entirely in writing, just send me a DM.
Thanks for your input, which is appreciated. I actually said I moved to an automation that covered all the fields per table. I don’t think it’s possible to watch fields in a single automation across multiple tables. So, I think I have that covered. But I didn’t come across the hash solution, which is clever… but I’ll need to restrict the process that edits are only made in Softr, and leave that extra hash function out of my process for now. I don’t let anyone edit in Airtable, except myself, so shouldn’t be an issue. It’s a messy solution overall as I have a ton of tables that I can’t spare automation slots for… would love this Universal Rich Text solution to be a reality one day.