More flexible field mapping and combining for Readwise sync and possibly all synced tools

I just saw this video covering the new Readwise → Tana sync and while it largely feels quite fiddly and cumbersome (as many things in Tana do, despite its power), I did note some pretty cool and much more flexible import and field config capabilities that I wanted to make Fibery team and the community aware of as a potential future addition to Fibery’s Readwise (and perhaps general) sync handling:

In that video at that timestamp you can see how you can essentially use field variables that correspond to both Readwise field names and Tana field names to not only map one to another (which Fibery already covers visually), but also (and more importantly) to map multiple source fields to a single target. I would love love to be able to do this! Rather than having to simply not sync a particular field, if I could instead flexibly combine multiple fields (along with free text, etc., like a normal formula) as part of the sync, rather than having to sync all the data, then have an entirely separate database (or added fields) to then concatenate/combine data together the way I want. The latter approach means I end up with all the fields I may not want separate, alongside the combined field of data that I do want.

Fibery already suffers from “database proliferation” and “field excess” in my experience, where because of certain missing functions, I have to use a new field for many things I would rather handle in other ways (an obvious example is recurring functions, which in my simple setup requires 2 fields, and in more complex setups requires whole new databases to handle recurrence intervals, etc.)! I would love more affordances for reducing field and database proliferation and I think such things will be critical to Fibery’s long-term success if it continues to be a tool partly (or largely) sold on its ability to replace many other tools.

The other thing I wanted to mention is that, because Fibery’s Readwise integration is native and initiated from Fibery’s side, it doesn’t show up in Readwise itself! This means you miss out on some potential exposure just from people seeing the tools Readwise can sync to. Hopefully Fibery team can remedy that too somehow.

While I’m no active Readwise user, I :100: agree with what you call “database proliferation” and the need of creating extra fields rather than being able to do stuff on the fly when displaying data in Views or entering data through forms or import.

One way to address this without completely re-doing things could be to create a “transformation step” that can be used to configure views before displaying and modifying layout or on input before storing the data.

That part definitely has my vote! :slight_smile:
Thanks!

1 Like