I am not a dev in our integrations team, so I can’t give a qualified technical answer, but I suspect the problem is not that it is extremely technically difficult to implement something, it’s just very difficult to define what that something should be, and no developer wants to work on a vague ‘sync Fibery to GSheets’ specification.
Well, for the time being, I would suggest trying to achieve what is needed with either Ply, Make or Zapier.
And if a handful of users do this, and discuss here what they did, it would go some way to illuminating what an MVP might look like.
My prediction is that there will be very little overlap between different users’ setups.
I understand that, and it is quite possible that GSheets integration will never be implemented, so I don’t blame you.
But then again, if there aren’t users coming forward to articulate a clear need that they personally have, then one could argue that it isn’t a massive problem to be solved.
Finally, is anyone here in the community aware of any tool comparable to Fibery (notion, coda, airtable) which has native GSheets integration?
(not via scripting / a 3rd party tool and more than just embedding a sheet)
It has been a while since I thought about this. The main driver for me is that one of my clients keeps A LOT of their business data in Google Sheets, and still actively manages it there; much of it would be quite useful to have mirrored in Fibery, if it doesn’t end up being migrated to Fibery entirely.
One-way sync (Sheets → Fibery) would be fine for much of it (and that would cover migration), but there will probably always be cases where the data has to continue to live in Sheets/ClickUp (due to policies/politics/etc), so it could also be useful to have two-way sync.
Fibery’s Custom Integration capability could do most of this, but those are very complex to set up.
Another approach would be to write a Sheets Add-On (Google Apps Script) that would push changes to Fibery (based on criteria defined within Sheets), and perhaps a Fibery Rule to push some info from Fibery to Sheets.
Regarding https://ply.io/ – it’s an awesome idea, but (1) still quite immature, and (2) looks to be prohibitively expensive, by my standards:
For internal features (features you share with your team), it’s likely going to be seat based. There’s likely going to be a free plan with limited usage, a “plus” plan for small teams in the $10 to $12 per seat/month range that will be capped somehow (like number of feature runs or tasks used) and a plan with nearly unlimited usage for ~twice that price for heavy users, which will also include features for larger teams. There will also be an Enterprise plan with advanced security features that will be custom pricing.
As for customer-facing features (which are still in a closed beta), that’s likely to be usage based. No idea about pricing here yet. We need to see some usage patterns and the value our customers get to price accordingly.
Again, this is a general direction and not a commitment, but I understand why this is important and we’re trying to be as transparent as possible about this. Hope this helps
To start, I do not need two-way sync, but the ability to pull data from Google Sheets to Fibery.
I think that’s in line with Fibery’s philosophy to be the fabric connecting data. Sadly we have to collaborate with others via Google Sheets, so being able to pull that info into Fibery is very helpful.
For me, MVP would be to be able to:
Import Google Sheet data into a database based on a fixed mapping that I configure
Regularly add entries that do not exist (based on the config mapping hash) to Fibery as long as the mapping works
An upsert would of course be preferred, if easily possible
That way I can encourage the team and partners to gravitate to Fibery and enhance the entities in Fibery, connect them, etc.
And yes, the Fibery Forms are great help and very useful even for processes, but pulling data in form other sources is what powers the engine. And some of that stuff comes in through Google Sheets.
As somebody who’s a huge fan of “simple tables” and databases, it makes me think that it’s actually more of an interface problem:
I love Flat Tables (I think is a better name than “simple tables”) as part of text and notes. They allow to nicely structure data along a few dimensions, as OL/ULs do not.
Thus I’m also a big fan of merging cells, coloured backgrounds, headers, footers, etc.
Flat Tables often will have more rich text than more spreadsheet views: summaries, some breakdown with some OLs, etc.
These tables are predictable or “frozen” and often hold high-level information to drill deeper
I also love Deep Tables (embedded table views of databases in Fibery lingo) as they allow to apply dynamic filters, sorting and all other fancy stuff
Most importantly, the strength off these are that data is connected and remains up-to-date
These can allow for calculations (sums, averages) and other computation on top of it.
I agree that ideally these should be on a spectrum so that the same data should be possible to display as a Flat Table or a Deep Table. What I currently often do, are simple tables with embedded Entities, which obviously does not do the necessary updating if needed.
If there would be a way to embed a View and then select if this should be a deep or flat projection, that could be very interesting.
The deep view would have a surrounding chrome that tallows sorting, filtering and computations.
The flat view has no chrome, but is optimised for displaying text, automatically merges cells with identical values, etc.
I wish the Simple Tables would get a bit more TLC in Fibery as even adding a new row is painful. But then again, this all is a different thread.
