Google Sheets Integration

My first use case for this would be using Google Sheets Forms to collect information (e.g. from job applicants), and automatically importing the info into new entities for a Fibery applicant screening workflow.

Or is there already a way to do something like this?

Can you use Google Sheets/Forms → Integromat → Fibery?

Also, related discussion:

And the general “form view” case:

Probably, yes, though :

  1. I’m not a fan of Integromat’s pricing model
  2. I think Fibery really deserves a native Google Sheets Integration :grin:
1 Like

Hey, Matt!
Your request is noted :muscle:
To make it more clear

  • we plan to implement Fibery Forms
  • currently we’re working on some big things and improvements, so can’t say anything about eta. But after those big things will be finished I sincerely hope that Forms will be implemented. (not a promise, but a hope!)

  • Zapier can work for this case instead of integromat :wink: It will be even free, as this one will be very simple. If you want - I can record a video of how it works!

Btw, what else are you missing from Google Sheets? (almost sure we won’t add such integration, so curious to know how can we improve Fibery :muscle:)

2 Likes

Thanks Polina - my main desire for Sheets integration is that there are many, many data sources we use in my company that are in Sheets, so it would simplify data integration for a lot of different cases, and make it easier to transition to using Fibery as a replacement for many existing functions.

I will look at the Zapier integration as a possibility.

Is there any possibility that we can write our own Fibery Integrations? I suppose we could essentially accomplish it just with some scripting and web hooks. I can write Apps Script for Google Sheets, so I could probably make that work. I know there are a lot of Fibery users who would use it :wink:

3 Likes

Hi, @Matt_Blais

Thanks for feedback. We already implemented the possibility to add custom integrations, but it is hidden for now. We need to complete documentation and add some extra examples. Will be available in nearest future.

Thanks,
Oleg

2 Likes

Do you need to edit the Google sheets data, or just read-only?
If the latter, you could create report views with Google sheets as a data source.

3 Likes

Hi, is there some documentation available to integrate data from a gsheet as a readonly database in fibery ? (like we do for Gitlab MR for instance)

2 Likes

There is no native support for GSheet integration/sync into Fibery.
It’s possible that other community members have experience with developing a custom integration, but I’ve not heard much.

Otherwise, your only options are CSV import (or using report view to create analytics if that’s all you need).

2 Likes

Hi @oleg and @Chr1sG,

Is there by now a way to pull Google Sheets data into a database without a custom integration? I know for reports I can pull the data, but I would like to add them to a database.

Is that possible yet?
Thanks!

1 Like

You don’t need a Custom Integration, but you do need to do it manually with some Javascript.

  • Create an “export” link for your Google sheet (File > Share > Publish to Web > Link). You can export a single tab or all tabs in the sheet.

  • In your Fibery script use http.getAsync() to read your exported sheet and process it accordingly.

I believe the only way this will work is if your exported Sheets link is publicly accessible, but only someone who has the URL will be able to access it.

4 Likes

Thanks @Matt_Blais, for the tip! That’s great to hear!

Sadly, it involves my old nemesis and abomination of programming language[1]: JavaScript. :face_with_peeking_eye:

let url = <published google sheet url>
http.getAsync(url)
    .then(response => response.json())
    .then(myJSON => fibery.createEntityBatch("Members", myJSON));

The above is how I think it should work, but it’ll surely not work because:

  1. The whole promise and await syntax and .then( => ) is just confusing
  2. fibery.createEntityBatch surely doesn’t just take that JSON, but there is no documentation

I’d be much obliged for any tips on what that JS code should actually be?

Lastly, @Chr1sG, having to publish the spreadsheet is not good. In this case, it’s a member database, so Ideally I wouldn’t want to have it publicly available even through an obscure URL. Instead, I rather give Fibery access to my Google Drive, like when making a report.

Thanks again!

[1] Horrible dev stack and debugging + weak typing + horrible documentation + random (browser) side-effects => :face_with_symbols_over_mouth: mess :face_with_symbols_over_mouth:

Welcome to Fibery scripting hell :stuck_out_tongue_winking_eye:

You can use the javascript await syntax - much simpler than using Promises with .then()

    const result = await http.getAsync(...)

You can also access sheets via Google’s REST API, which will give you more auth options (and way more complexity to deal with).

Wheee, scripting hell is probably what I do deserve. :see_no_evil:

Don’t get me wrong, @Matt_Blais, I very much appreciate your help.
But I reaaaaaaaaaaally wish Fibery would solve this natively. Especially as reports can import Google Sheets. :melting_face:

2 Likes

Agreed! Although the native Fibery forms now largely replace the usefulness of Google Forms (as per the original request here), I still think there is a significant benefit to connecting with Google Sheets as a data source for migration to a more full database setup in Fibery. This is particularly important as Fibery lacks any good support for spreadsheet-like functionality in non-database tables, and very, very often I find that a full database is far too “heavy” of a solution for some data I want to quickly summarize, run quick calculations on, etc. That kind of work is still perfect for Google Sheets, but then some of it eventually turns into something I do want to do more extensive database operations on, and then moving it into Fibery would be ideal. I talk about this broader concept in a more forward-looking way here and outline some of the needs and benefits:

And all of that of course doesn’t even account for the many, many other tools already integrated with Google Sheets, for which GSheets could then become an intermediary for getting data to Fibery. It seems like on that basis alone it’s a high value thing to implement. As you say Reports already connect, and since it’s all just basic tabular data it seems like it should be fairly trivial to connect with. Why not Fibery team? Why not. :thinking:

1 Like

Although Google Sheets is ‘just tabular data’ there is quite a lot of complexity to consider, for example:

  • assuming that each column in a sheet should be matched to a field in Fibery, how can Fibery know what datatype each column of data represents (is it a date, a number (integer/decimal), select field…)?
  • following on from that, how could Fibery adapt if the content of a cell changed such that it was no longer a supported value for that data type? In other words, if the sheet has a column of numbers, Fibery might ‘intelligently’ sync these as a number field, but then what should happen if one of the cells is edited to become a string of letters?
  • what should happen if the user adds more columns? should Fibery automatically add new fields?
  • what should happen if columns are deleted or reordered in the sheet? How does Fibery recognise this (as opposed to perceiving it as changes to the field types and values)?
  • what should happen if rows are deleted/reordered in the sheet? Is it to be expected that Fibery somehow intelligently compares before and after, in order to recognise that the data that was in row 1 (which was entity 1) is now in row 10 (but should still be identifiable as entity 1).
  • sheets are (almost) unlimited in the number of possible columns. Fibery databases are limited in the number of possible fields. Should the sheet data be truncated?

My guess is that different people might have different answers to these questions.
For example, some people might be happy for everything to simply be synced into Fibery as a text field (which is the most flexible/accommodating datatype) whereas others might require numbers to be synced as numbers.
Some might even just want to have a Google sheet embedded into a Fibery document, which is already possible :slight_smile:

Overall, although the use case “Sync Google sheets into Fibery” sounds like something a lot of users might have, in practical terms, it might actually be dozens of slightly different use cases, which typically makes for v difficult implementation.

4 Likes

Fair points and well articulated! As with many things of this type my approach would generally be to not bother trying to answer all those questions for everyone, but simply to answer them internally for whatever has the most consensus then do an MVP (Minimum Viable “Product”, not Most Valuable Player, of course :smile:). Similar to what was done with the AI stuff in last December’s “slow time”, which of course turned into much more because it proved its value. (in fact perhaps this could be someone’s “slow December” project, if they feel so inclined…)

The truth is that with many things we can (and often do!) speculate a lot about what people might want or what differences of opinion there might be, but the best way to find out is to release it to users and see how much of an uproar you get. :laughing: This is not a good approach for all companies, but for Fibery IMHO it really, really is for the following surely compelling reasons :smile: :

  • Fibery dev and release already works this way. That’s really all I should need to say, but I’ll say more. :wink:
  • Fibery has many things that are implemented only “partially” (depending on use case/user perspective/needs), or work only partly well, or are far less sophisticated than many users would like them to be (e.g. very limited bi-directional integration support, the until-recently very limited Tables View, Whiteboard, etc, etc.)
    • Many of these things are “good enough” to continue existing despite their limitations and still contribute significant value to the platform
  • There is already an existing mechanism for experiments, some of which do not become permanent
  • Using this mechanism (most of the time), Fibery has already released things, some of them significant (e.g. nav experiments), that it later removed/changed
  • Furthermore the existing user base is comparatively small, so even if some experiment has negative results it affects a small number of people
  • Fibery has not found true market fit, adoption is still slow and unclear (according to latest monthly progress update), and this has been the case for years now, so more changes probably need to be added/tested

Google Sheets embed is complimentary to a Fibery sync IMO, especially if the sync is bi-directional. I would love to be able to sync some Fibery data out to a GSheet and run some quick, ad-hoc calculations on it! I don’t expect per-entity calculation fields or Ad hoc formulas in views to be added soon, or even this request that Michael said would be considered:

So short of those, this would add most of the benefits of that in some sense, and complement existing functions like embed, reports, etc. that already work with GSheets…

If you need suggestions for specific answers to any of the above questions and more I’m happy to think through the practicals of an MVP!

1 Like

At the moment, I have yet to actually read a single well-defined use case* so for any MVP it feels like we’re a long way from ‘consensus’ :stuck_out_tongue:

*apart from form submission and embedding, which are both solved :crossed_fingers:

But actually, I feel like it’s a square peg-round hole thing. If someone said they wanted to sync Word with PowerPoint I’d be similarly confused about what that could mean.

I should note that your example is now the first:

which I personally believe should be solved in some other way than a bidirectional sync with GSheets

2 Likes

I can work on use cases if the potential implementation will actually be taken seriously as a possibility for some relatively near future. Otherwise, not to be dickish, but I don’t think I want to invest the time to specify and articulate them for likely little tangible benefit to anyone. :sweat_smile: @Matt_Blais did you have any other specific use cases top of mind besides the now-solved form input one?

The bottom line as I see it is that GSheets is a useful way to have more “loose” data, ad-hoc calculations, etc., but it is almost inevitable (in my experience) that at least some of that data starts to become more “firm”, and eventually often needs a more formal solution (e.g. Fibery). I suppose at that point I can just do a one-time CSV import, but then I lose the benefit of GSheets and it makes it much more consequential and thus unfortunately disinclines me from using Fibery more (i.e. I have to be more certain that I need the Fibery formality and “heaviness” and willing to let go of the flexibility, which makes the bar higher). The easier you make it to work between Fibery and other tools, the more toeholds I think you’ll get in multiple markets.

Cool, great, I agree!.. How?

And let me add to that: even if we can both agree there is a more optimal way to solve it, again I am talking here about what I still think is relatively “low hanging fruit” for a GSheets integration. And I strongly suspect that any more optimal solution is going to take a good deal more time and effort to provide vs. this. But I could be dramatically incorrect. Perhaps you have good suggestions for how to do what I want to do with already existing functions, or perhaps I am wrong and GSheets integration - even in MVP form - is very hard, or perhaps… something else. :smile: