I’m not sure your last post @mdubakov at me, but in case it was, I will tell you that my team in fact actually has the most success of all use cases probably with candidate tracking! We don’t need form view because we collect candidates from multiple other sources aside from our website, it’s not hard to manually input them into Fibery. Likewise, we communicate with them through various services directly and Email integration that would work for us would be far too complex and no tool out there has an Email integration that is satisfactory. So in fact we don’t need either to successfully use Fibery to track candidates. We in fact however have the most frustration with this use case with comments and notifications. We discuss quite a bit the candidates, interviews, onboarding, meetings around candidates, in Fibery. And it is simply frustrating on a daily basis (I say daily because probably 80% of the time for over 2 years we are doing some activity in Fibery around recruiting) to not have threaded comments, not be able to “heart” a comment that you saw it, not quote another team member’s comment when responding to it, have references and comments in different places (which I’ve discussed ways to solve a few times including here) so you can’t truly “update” an entity using one or the other, which would be great given the power of references in the first place. These are “Quality of Life” issues we’ve talked about before, and cause a lot of frustration on a daily basis.
I truly think Fibery works much better out of the box for tracking candidates than just about any other use case you are working on, in particular Product Development, which is what my team does, but we do not really use Fibery for this. A main reason is forced hierarchy when creating folder-type structures. I think I have discussed this in the forum somewhere, but it’s been a while I can’t recall where those discussions are. What I mean is we have a product structure, and one Master Feature may have a sub-feature, but another may have 3 levels of sub-feature. The only way to represent this in Fibery is create 4 types/db’s related to themselves, so in the first case the Master Feature needs 2 “artificial” levels between it and the sub-feature on level “4” (I hope that just made sense) Polymorphic would solve this, but not sure where that is on the timeline for development it’s not on the public board I noticed…Bottom line is tracking our Product Development in Fibery has not been easy, but tracking candidates was very easy to set up and we manage this process better than in any other app we’ve ever tried! And this is where the “quality of life” stuff comes up, because we encounter stuff like randomness of the keyboard that @Matt_Blais talked about daily and it’s frustrating!
I certainly hope this comment also isn’t directed at me. I have spent countless hours providing detailed use cases, I make sure to do it almost every time I post in here. A lot of my requests with use cases don’t get responses, such as this one and this one
I think @Oshyan has made a great case for the benefit of polish on some work management features, etc. that is the theme of this thread. It appears that doesn’t jibe with a lot of the live feedback the Fibery team is receiving. I continue to think that if you guys went outside your regular procedures for prioritization and focused on delivering some refinement in these areas, you’d see huge benefit.
Thanks!