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).
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.
@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.
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.
@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.
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 )
We have been using Fibery for about a year now, and I’m currently conducting a review of our Project Management space. Doing some searches I found this topic so I’m posting there.
Since we started with Fibery, it has evolved significantly and today has many more capabilities. We started first with a single Project Management space and today we are thinking in creating separate spaces with separate DB’s for each teams.
The challenge when many people use the same databases is that each team has its own needs regarding fields, automations, etc… Developers think differently than the guys on operations and also have other needs regarding fields, etc…
We are considering a project & task DB for each team but with the same foundation. It means that several fields, automations and other stuff will be the same on every project & task DB’s. After that, each team can fine-tune its Project Management space with extra fields and automations they need. For example, if the development team wants a field to set an ID but the operations team doesn’t need it, they will be able to fine-tune their DB by adding this field. So they can add it and it will not perturb the operations team. In this manner, each team isn’t flooded with unnecessary stuff. After that, we will build views that regroup all of the team’s project & task entities. That’s a vision we are exploring.
I’m interested to hear your opinion and also to know how the community deals with these kinds of challenges. Is it a good practice to separate or is it better to keep everything on the same DB’s and play with views and permissions to show only what matters ? What do you think ?
@Jonathan1 I would probably recommend a single database, but with a select field to distinguish the different types of Project. You can add all the fields you need (for all types of project) to this one database, but then make use of multiple entity views so that there is a tab per project type, with only the relevant fields showing in any given tab.
With entity view rules, you can make sure that the correct entity view is opened based on the value of the Type field.
This means that someone looking at a ‘development’ type Project will see the ‘Development’ entity view, and when looking at an ‘operations’ type Project, they will see the ‘Operations’ entity view, and so on.
Nobody needs to be bothered by the fact that the db contains fields which might not be in use for all Project entities.
It means that when there are things that need to apply to all Projects (automations, access control, specific fields) then they only need to exist/be managed in one place.
BTW, in near future (1-2 months) we are going to implement a feature to Hide Entity Views based on rules. For example, for some project type or some person role you can show only necessary Entity View and hide all others, thus it will reduce clutter when using same database for several things.
)