"Conversations" for integrations / Email integration

Ideas & Features Integrations
1

OK, this may be crazy or just out of scope for Fibery, but… I’m thinking about the potential future here, building on its strengths and directions so far, working with strong integrations and flexible data model that provides the “mirroring” approach to integrations. And I wonder if there is a big opportunity here (probably along with big challenges though :grinning_face_with_smiling_eyes:).

What would it take for Fibery to become a true CRM and/or support tool? You need to be able to have conversations with people outside your organization, conversations that are separate from “comments”. What if we had an Extension for “Conversations”, that worked very similarly to the existing “Comments”, except it could connect to one (or more!?) external communications systems (email being most obvious, but also through the Intercom integration, and maybe more). OK, so that is no doubt multiple big feature requests: new “conversations” extension, bi-directional sync/update, email integration, and more. Let’s just focus on the “conversations” extension idea for now, because I think it’s very useful on its own.

I use the Discourse integration, and it’s great to have, but I find some frustration with it in how it mirrors/represents the data, specifically for the actual topic content. Since Fibery has no concept of a “conversation”, or a “field” that will have multiple rich text “items/entries” that are related/sequential, it becomes difficult to effectively represent things like a forum discussion. The way it works currently, Fibery just updates a giant Rich Text field with all topic discussion/replies, concatenated together. I imagine the Intercom integration works similarly.

This is messy, for one thing, and perhaps more importantly it loses some valuable info such as date of a specific post, as well as convenience like being able to click on the author of a post to see more info or update something. There is a relation that shows a list of participating users, but no links in the actual topic text in the rich text area. It’s just a poor representation of a forum thread (or other conversation). Perhaps more importantly, long-term, it is not possible to act specifically on one message (e.g. to reply). Basically it seems like co-opting of a general purpose field (rich text) to make the integration work, which is cool because it didn’t require any new features/dev, but is hopefully considered to be a short-term/stopgap approach.

I mean, woulldn’t a “Conversation” extension handle all this much better? It would essentially work similar to (and perhaps even be able to “piggyback” off of the development of) the existing Comments extension. Except it would represent conversations or other sequentially updated data from external systems, within a single field. You’d then be able to have the conversation updates mirrored 1:1, including the User, the Date, and more, all linked properly, plus overall much better and more readable formatting. I mean just take a look at the comparison between native Discourse view and Fibery view of a forum thread:

image
image1142×1485 224 KB

image
image1177×1369 169 KB

Looking further forward, along with my bi-directional sync request, ideally you could then reply to a conversation within Fibery, just like you can with a Comment already. It would then be pushed into whatever system the conversation is integrated with (e.g. Intercom, Discord) and be posted to that system as a normal, native “message”. This latter part may be a tall order, I realize, but could really be powerful and would truly turn Fibery into a full-blown CRM and support system. Or at least a key component of one. It would allow product teams to centralize and integrate so much, and keep more people within Fibery. :smiley:

I’m particularly interested in feedback on the core idea, separate from the additional ones or “stretch goals” like email integration and sending, etc. Would anyone else find such an Extension (or new field type?) useful in how they interact with integrated data? Or see any other use for such a thing?

2 Likes
2

I would really like to see big focus on developing towards this goal. Yes, you made a great point in the Bi-Directional Request that the two-way sync is crucial to true integrations. This would go along with a very good Email Integration

2 Likes
3

It is what Intercom or Frontapp try to achieve, be the inbox for external communication as a team (with assignment, routing, comments on messages only seen by internal members, replies to external user via the channel they use, etc).
Having a separate extension, similar to comments is I think a bad idea. You want to have 1 thread of messages, that includes in time order the “internal comments” (equivalent to Notes in Intercom terminology) and the “external messages”.

Also to compete with specific tools on Communication, you need the following features:

  • files attachment => send as email attachment, or Whatsapp attachment, or in-app chat message with link to download, depending of conversation channel linked
  • routing to teams / individual in charge of answering, usually based on round robin or attributes on the message (for example “if the conversation is started by a trial user, I want to route to the sales team”) => that should be achievable with Automations rules.

For more advanced features, like conversational bot, custom bots (as in Intercom) I don’t think Fibery will replace soon those. The features are much more specialized.

What is not clear is where to draw the limit:

  • is Fibery just there to aggregate the content (1 way sync) and link, but does not replace at all the underlying communication tools
  • does Fibery become the main tool for external team inbox (2 way sync), but communication tools still needed as a channels mainly (ie use Intercom to display the chat in our web app, but not using the admin interface too handle the messages) => will not reduce cost on 3rd parties tools.
  • does Fibery replace most of the features of Intercom or Frontapp, using technical tools like Twilio for the communication channels, but the logic of conversations, selecting the richt channel per user, etc is done by Fibery.
2 Likes
4

I think the implementation choice that ClickUp made would be a good fit here.
The comments section in clickup allows users to toggle between a comment in ClickUp and an email. When an email is selected, the entire thread appears as a threaded comment in the comments/activity section of a task. The bonus of this choice is that team members can leave a comment on an individual email in the thread. It keeps communications in one place.

2 Likes
5

Yes, that’s true. And when you put it that way, it does seem like a big challenge and possibly some scope creep. I’d be curious to know from @mdubakov if they have any internal goals to handle this kind of thing, even if only long-term and unscheduled.

That is a fair point. I thought it could be separate primarily to avoid complicating the existing and useful Comments function that is needed for so many other things that have nothing to do with external communication. However it does perhaps make sense to make this “conversations” thing an extension of Comments, i.e. additional options within the existing Comments extension. That said, having them as separate extensions might still be fine, perhaps if only one could be enabled at a time. I don’t know, Fibery team should be able to determine what makes most sense I think. If they even want to implement this…

Yes, I would not want to see Fibery try to implement these things. My goal is to be in Fibery as much as possible, but to use external integrated systems (with bi-directional sync) for their key/unique functions when necessary. The key to it all, really, is bi-directional sync, because then it doesn’t matter which system you choose to use. And I want to stress that I see great benefit in that flexibility. My intention is not to replace these external systems, necessarily (in many cases not), but simply to avoid having to jump over to them for the many cases of very simple or for example semi-automated interactions.

A great example would be interactions with users around issue reporting and fixes/releases/updates. Let’s say you get report of a crash from 1: a forum thread, 2: several people in Intercom. In Fibery you can easily link those together to a single task/bug/etc. So when you do that, you first want to update all linked conversations letting these users know it is now in the issue tracker and being worked on, and perhaps a fix time line if available. Then when it’s resolved, you want to easily push out an update to the forum thread and the Intercom conversations saying it was fixed, what version, link to download if applicable, link to change log, etc.

I suppose this example raises the question of how to handle multiple incoming “conversation” streams, too. Not sure, but maybe they’d each exist in their own separate Type through an integration, and then there could be some Automations feature so that when I perform some action on a linked e.g. Issue (Close/mark Complete and add fix description), it then does something like: “add text of field ‘Resolved Description’ to conversations of all linked entities and mark forum topic(s) as ‘resolved’”. Which I imagine might be achievable with automations.

Agreed, this is the critical question.

This is how I envisioned it, but your point about it not reducing costs is important. The thing about that, though, is I think staff time is worth more than subscription costs. My goal was to save time by not having to e.g. jump over to Intercom and update 3 conversations (in the above example) as well as the forums when an issue is resolved. If I wanted to actually have a conversation with any of those people on Intercom, or to more fully interact with the forum thread (with all the benefits of Discourse), I would still want to go to those individual systems, and would be happy paying for their benefits for when they are needed. My goal, essentially, is to streamline, but not replace. I think that is pretty valuable in itself.

The other point about replacing tools and reducing costs is that this must almost certainly come along with pricing changes for Fibery. You can’t expand the Fibery team to be able to do what Intercom does without increasing pricing a lot, or at least providing an optional “add-on” to handle Intercom-like functionality. I don’t know if the Fibery team wants to go this route, with add-on pricing for every major suite of tools they replace. So far, no. But it raises an interesting issue as Fibery moves to replace more and more systems. Is the “all inclusive” model sustainable? You could imagine that sheer volume of subscribers from all those replaced tools might sustain the company, but given the widely varied prices of the replaced tools it’s hard to imagine that being the most effective approach.

Lots to think about. But I’m encouraged by your comments and interaction here. Although I don’t get a clear sense of what your preference is for these levels of integration.

Interesting and yes that sounds promising. I left ClickUp some time ago so I haven’t tested this newer feature, but I might have to take a look so I fully understand how it works. Regardless it is good to hear others are tackling similar problems of integrating internal comments and e.g. external email.

6

I want to be clear that for me the goal if this feature request is specifically just to better represent integration data that is “conversational” in nature. There are many such examples, Discourse, Integromat, and now Hubspot at the least. The way these are currently represented is just as big Rich Text fields, that seem to be updated every time a discussion is added to in the host/originating app. This is an effective but fairly clunky approach IMO.

I would really like to see individual messages/replies to e.g. forum topics represented in Fibery. This could be done now by simply making a “Message” Type with a Relation to Topics, and add each new Message as a relation to a given Topic, going into a Collection on that Topic. But this is both clunky and, I think, a bit of overkill (arguably). Critically it would require you to open each Reply Entity individually just to read through the discussion.

So what I am requesting above is a new type of Extension/data model in Fibery that is able to represent “conversations” in some more functional way. The way the References Extension works already is actually a pretty good model. It includes Text Content, and it shows the Author (person who linked), which maps well to the needs of e.g. a Reply on a Topic or an Integromat chat message. So the Conversations view could work similarly, but allow full content, e.g. images, etc. as well as Link to Entity and other functions. But not editing, for example (which is one of the issues with the current way e.g. Discourse topics are represented as Rich Text).

The reason I am clarifying this is:

  1. The subsequent discussion above included a lot of speculative possible additional functions, many of which would be great, but seem far more difficult to achieve
  2. @mdubakov renamed this Topic recently, and added “email integration”, which to my mind may be separate, unless that just means that incoming email is represented in this “Conversation View Extension” I have described
  3. I am concerned that if the scope/ambition of the feature request(s) contemplated in this topic becomes too great, people will be unwilling to vote for it, or misunderstand and overlook it, or it will simply be deprioritized by Fibery team because it requires a lot of work

I don’t want this to be seen as a major endeavor because I don’t think it has to be one. It is doing specifically and only the following, to my mind:

  1. Take existing data already represented in Fibery through integrations
  2. Look at existing “References” Extension design
  3. Adapt #2 to better represent #1 (obviously I don’t mean to literally re-use the References system since it works differently, I just mean it’s a design model)
  4. Ideally, re-index/reimport/reformat all already-imported data in integrations to use this new system, but without losing existing e.g. entity links

Other things such as Bi-directional integrations/sync, replying from within Fibery, etc. would certainly build on or otherwise interact with and extend this. But I think it’s valuable to have this fairly simple (seeming!) idea as its own feature request, because I believe it could be implemented much faster than full bi-directional sync and other things discussed in this topic, and would help a lot in making imported integration data more clear and actionable.

7

We envision two possible solutions here:

  1. Go with Types and every Message will be an entity of this Type. Then create a Feed View that you will be able to embed into any other Entity View and see a list of Messages in a feed format, so you can read all the content in a single feed

  2. Go with Blocks and in this case every Message will be a block. Again, Feed View may help here to see all relevant Messages/Blocks for some entity.

Both scenarios have advantages, and maybe both will be supported. @antoniokov Will take this into consideration since this case was discussed internally.

1 Like
8

Ah! That’s a good point, I hadn’t thought about taking existing functionality (Types, Entities) and creating a new way to view them that would be more conducive to the goal I am hoping to achieve with this request. Rather than creating a whole new kind of content-holding Extension.

The idea of a “Feed View” is actually really interesting because it meets another desire I have had, that I don’t think I’ve posted about yet, which is for a way to actually view the full contents of multiple entities sequentially or, perhaps, at least the contents of one field between multiple entities in a single view (yes, Tables do this, but they don’t work well for e.g. Rich Text). So if you do implement such a view, I hope (and imagine, given Fibery’s history) that it will be done so in a flexible way not focused just on integrated data for “conversations”, but usable for any Type and collection of Entities.

I am not sure what you have in mind for such a view, but to be most useful in the context you’re describing. I imagine you would have to specify some value of a relation/reference field in Entities to create a Collection for viewing. Ideally you could then specify which field (or multiple fields?) will be shown in this “feed view” as full contents. And I imagine a link to the full entity view perhaps.

One thing all this reminds me of is a feature of the old Filemaker Pro software that literally just let you view full database records sequentially, in an infinite scroll. It was surprisingly handy. If this could emulate something similar, it’d be great IMO.

All that said, there are some potentially unique needs for a “Conversation Extension” which might still suggest at least a “mode” for this “Feed View” extension to accommodate, especially in the hopefully eventual future where e.g. emailing from Fibery is possible. If the “Feed View” were flexible enough to accommodate specifying multiple fields from the target Entity to show up, and do so in an intelligent way, then custom functionality for a “conversation view” might be avoided. Primarily I am thinking for example of the need to have:

  • Rich Text (content of reply/message)
  • Date of message
  • Author of message

You’d want those fields at a minimum, I think. In the possible future where Fibery can do emailing from an Entity, that would complicate this “feed view” a bit perhaps. You could argue that new replies should be made from the parent Entity to which these “reply” Entities belong, and maybe that’s the way to go. It still suggests some potentially special relationship between “feed view” and the idea of a “conversation” as a unique type of Entity, at the least.

9

You grasped the idea of Feed View quite fully. It will be possible to select fields that are visible and we’ll format them in a sane way. Most likely there will be limitations on how many fields you can select, but we’ll see.

We are thinking about this for sure, but did not find unique cases for discussions (yet). Maybe we will, but there are just thoughts experiments in the moment.

2 Likes
10

That sounds very promising indeed! Now I’m excited (though I imagine Feed View will not be available for some time).

11

It’s an important part of Blocks, so I hope we’ll implement it in 2-3 months

2 Likes
12

When talking about 2-way sync, I envision Fibery as a primary tool for slow communication only:

  • Product community (Discourse)
  • Technical support (email)
  • Sales (email)
  • VC (email)

I don’t think we’ll ever replace or send messages directly to Intercom or Slack.

I agree here.

3 Likes
13

I agree, I wouldn’t want to see you try to accommodate real time/synchronous communications. Too many additional challenges that are outside your scope. However I do think there is room for a different type of integration in the future, one more like what ClickUp and some other apps do, where they integrate functionality into the other app’s interface. So for example if you were in Intercom chatting with a customer, you could Link to a Fibery Doc right from a built-in search in Intercom (a search that would reference the Fibery entity index), or create a new Entity, etc. there. But yeah, that’s outside the scope of the feature request contemplated here.

1 Like