Hi, we’re testing the Hubspot integration. One issue is that many fields are mapped as text string fields from Hubspot, even when they are defined as limited choice pick-list fields in Hubspot. The downside to this is that it impossible to build certain views in Fibery from the data, e.g. create a board view with columns from a HS Pipeline.
Is there any way round this? Or is it possible that the sync could be enhanced to map to a single select field in Fibery?
Thanks! In general the sync looks great and promises to be very useful
Also I notice that the hubspotlink URLs saved to Fibery have the host app.hubspot.com, whereas our HS account uses app-eu1.hubspot.com (presumably because its stored in an EU data centre). This means that any link clicked from Fibery redirects to a Hubspot accounts view to select our account, but then it loses the original link and just goes to an account homepage.
Could the copied URLs be tied to the HS account location?
It seems like almost everything that gets synced other than text fields just gets set to read-only in Fibery…is this the intended behaviour? Even number and date fields, which seems super weird.
If so, I guess the solution is to essentially clone the original synced hubspot entity as a completely new fibery entity so we can actually use that data in any useful way? I don’t really understand the value of the integration if it’s really so limited.
What would you want to happen if you changed data synced into Fibery? Change it back in the source app (e.g. Hubspot)? If so you want Bi-directional integrations/sync. If not I am curious to know what would solve your need.
I think in general the point of syncing data 1-way (as is the case with most - but not all - current integrations) is to link to/operate on that data for other purposes. E.g. link a Hubspot Contact to one in Fibery, or to an internal issue tracker for software dev, or use e.g. a Lookup field to show Hubspot Contact fields on a native Fibery Contact, etc.
I would want the synced entity’s fields to be usable and functional within Fibery, instead of just a static snapshot of what the fields were at the time of sync.
Because most of the fields appear to be read only, I can’t really do anything with the synced entity and need to use an automation to recreate the exact same entity with the exact same fields in a different database so I can use it. So now I have two entities that are virtually identical, except only one has number, date and dropdown fields that are editable.
If this is just a bug and not how the integration is actually supposed to work, then maybe that explains it. It just seems incredibly inefficient to have fields being synced but then those fields end up being non-functional. What’s the point of the “field mapping” if they’re just static?
It’s not a bug. Check out the other thread I pointed to and vote for it if you can because I think bi-directional sync is what you want (and e.g. Coda, Notion, and others already have this for more tools than Fibery does).
I think making them editable arguably requires a one-time sync (not just 1-way but 1-time). Either that or something like:
An indicator when a field has been edited in Fibery and does not match the source data (and some way to make clear that this change is not reflected in the data source, i.e. the other tool)
Possibly a way to re-import just the value of that field from the source, i.e. “reset to source”
I think the reason the fields of synced tools are not editable is to avoid confusion and frustration at the lack of bi-directional integration, i.e. someone changing something in Fibery after sync and expecting it to show up in other tool.
So I guess the question is whether the utility of a potentially confusing/frustrating 1-way editable sync is worth the dev and support costs. I don’t blame them the decision they’ve made to-date.
One reason why the Fibery syncs are almost all unidirectional is that bidirectional sync is hard, since it implies that there exists a mechanism for conflict resolution when data is independently changed in two places, and realtime sync is not possible.
Assuming that users don’t want to leave Hubspot and operate completely within Fibery, then the easiest option is to make Hubspot the single source of truth, and Fibery a mere mirror of the data.
Indeed, which is why it would be so cool and notable (hopefully, to people who don’t already use Fibery!) if you conquered it. Also… many other tools do this with various integrations and you already do this with Jira, so…