Hi all, I wanted to pick your mastermind brains on a project/task concept I’ve implemented in Fibery. In an effort to minimize the potential redundancy/repetition of project and task entities being created in each space, I have created a single Project Management space with project and task entities with a relation field linking projects to a Team entity. I haphazardly discovered this approach when learning about Smart Folders. Given I have Spaces per team and I have a single Project entity with many project records related to Teams, I have created smart folders in each Team Space automatically populating Projects that are assigned to their respective Teams.
I’m curious to hear if other users have implemented a similar approach and learn of any pros/cons to this structure. It seems this method works well if the project and task entities will remain fairly homogenous and unified in the required data fields, but falls short once teams begin requiring domain-specific information that may be irrelevant to other teams (e.g. sales projects need not any of the technical details that may be required for engineering projects).
1 Like
This approach can have the following potential problems:
- Indeed as you mentioned if one team needs more fields, it will not work. Few fields might work, but if you will have dozens it will be hard to use
- Permissions in Fibery are per-Space (so far), it means you have to give ALL people access to Project Management space and they will see ALL projects and tasks. Maybe this is OK for your scenario though. In future we are going to add per-entity permissions and in this case it will not be a problem, since a Team will be a permission container for Projects/Tasks in your case. But it may take us 6+ months to release.
- You have to always use filters to see relevant tasks. This case be solved via Smart Folders, but still you have to always remember about it.
Overall this approach is good if all the problems above are not very important.
3 Likes
@mdubakov - thank you for sharing your thoughts on this approach and for validating some of my assumptions. Problem #1 you pointed out may necessitate we create team-specific entities for those scenarios. I think what we’ll probably move forward with is the current implementation as a "lower common denominator’ PM space, where we keep this entity as agnostic as possible for managing cross-team collaboration/projects. I’m envisioning the potential for specific teams to have their own “Initiative” or “Technical Project” entities which we can relate to agnostic PM entity for transparency.
Excited to hear of the improvements to come in the future. This would provide what seems like an infinite level of access controls.
Absolutely. I’m continuously amazed by Smart Folders, discovering many creative ways to utilize this feature, and hope to recognize some serious benefits with my team. Projects/Tasks folders filtered by Team as and Status, Team folders containing team members, Customer folders containing contacts. It’s such a neat feature that just makes so much sense in my mind and the way I operate in general - structuring work in a way that minimizes wasted time “finding” things.
Thank you and the Fibery team for making magic happen!
3 Likes
This is pretty interesting. I assume that the different workflow status folders you have (e.g. Active, Pending, On Hold …) are each a separate smart folder. When I first saw this, I thought I had missed a major change and that you were now able to group entities in the smart folder based on fields in addition to entity types/databases.
I think if you were able to use certain fields (like workflows, dropdowns, etc.) to further group entities in the hierarchy, that would make smart folders a really powerful feature.
4 Likes
@cannibalflea - you are correct; we manually created a smart folder, one each for workflow status. I agree that Smart Folder would get very interesting with the ability to auto-generate sub-smart folders based on workflow, dropdown, or other deterministic field types.
3 Likes
Yes, I think there is a really big missed opportunity in smart folders and lists by limiting grouping and hierarchies to only relation types (see also Group by fields in hierarchical views). Expanding grouping to other field types would really make for really interesting ways of viewing data.
This would be in addition to supporting grouping in fibery table views which seems to be in high demand (and a standard function in other tools, even something as horrible as SharePoint 
)
1 Like
