I am very excited for this! I think the number one thing I want to be able to do is associate conversations on slack with entities in Fibery. Some of that can happen automatically based on channel (I tend to have a channel for most individual projects, which sort of maps to my Fibery organization), so I think this proposed approach should pretty much work. In the longer run, I would love to have some way to tag messages in slack to indicate that they should be associated with Fibery entities other than the obvious one
Our main goal is to support the product team’s discovery process by linking feedback and other relevant information shared in Slack channels with the corresponding data available in Fibery, e.g., product features, bugs, or ideas.
For this, we are making the conversations happening in the designated Slack channel easily accessible in the Fibery database with this integration.
We have designed this feature to be as flexible as any other in Fibery, making it suitable for a wide range of use cases.
This looks great. Have you given much thought to how you would automate linking between entities and messages?
The way I would envisage this working is that if we are discussing an entity for example a task, we can start a thread with that entities task ID (e.g. Do we want to stop working on this feature given yesterdays decision to stop building client-specific features? Fibery:[task id]), then we can automatically bring that conversation into Fibery link the message to an entity via some regex.
Obviously we could use the fibery UUID as the task id, but I am hesitant to use those because the usability when discussing work isn’t great compared to something easy to say out loud like “BIGCO-1221” The solution I’m heading toward is some kind of uniqueness database that I can query with a script when creating an entity.
The use case is to add a Slack message to a Fibery database and create a reference to a specific target. Slack channels are dedicated to an entity, making the connection easy without specifying the target Fibery entity in the Slack message. To trigger an action, you can use an emoji.
The UUID is not user-friendly. Running a regexp on rich text isn’t straightforward. Let me consider the use case and get back to you.
This makes sense, I know a lot of companies use Jira in this way (even to the extent of automating the opening/closing channels in response to new issues). In small teams for me this seemed quite heavy for quick questions about a bug or something, as mostly my team liked to just drop a message in the #team or #team-dev channel referencing [PROJ-123].
Ahh I hadn’t considered the Slack message would be in Rich text, that seems obvious now upon re-reading the roadmap item (I think the rich text message is missing from the schema in the roadmap?). Yes that’s going to make any post-processing hard isn’t it! At the risk of suggesting a horrible implementation, you could include a second message field that contains unformatted content. ho ho. Well, that’s why I’m not an engineer.
I apologize for the delay in responding. I was thinking about how to make the use case you mentioned earlier above.
The issue we encountered is that (1) Fibery doesn’t currently have a short, unique identifier to refer to a specific entity, and the Slack message is in rich text format, which currently (2) can’t be searched in the automation rule. Unfortunately, this problem won’t be solved until these two features are added to Fibery.
However, I have come up with a potential solution idea to this problem. Since the release of the snippet that creates a text field from the first 3000 characters of the rich text field, we can use these snippets as a proxy to search the rich text.
So, we can create an identifier for each database in a separate field, such as “BUG” for Bug or “FEA” for Feature, and combine it with the database public IDs. Then, we can search for a specific identifier format using regexp, and we can match the “BUG-123,” with the corresponding entity.
The only thing that needs to be added is the formula supporting snippets, which is much easier to solve than the other issues we’ve encountered.
What do you think?
hi Kalman, the identifier is something I’m doing already using the public id, great minds
In terms of being able to interact with snippets using formulas, I think that would be very welcome for a lot of users myself included, for a slack integration that would be ideal because most messages would be relatively short. So in theory on a given item like BUG-123 there would be a relation that listed out many slack messages that were tagged, and clicking on each mesage would allow you to browse the whole thread?
I think that would work great, and is aligned to what I’d need once I get to the point of needing the slack integration. Or in my previous roles using Jira and Slack, this would be a great use case. My own use of slack is a little further off now, so please don’t rush this change in on my account. But the ability to interact with snippets via formulas does sound like a lot of people would benefit from it.