Why keep the default Project/Task item types with custom item types now available?

In Wrike, the clear division between standard Project and Task item types can complicate certain functions. Notably, you can't display these two item types together on a single dashboard/report, sort them together in tables/lists, nor can they be managed by the same automation or be created by the same request forms.

For example: Say your setup includes projects, tasks, and a custom item type named "Requests" for high-level inquiries that are smaller than full projects and not linked to any existing project.

When a team member receives both these high-level "Requests" (categorized as a custom project item type) and standard tasks, they're unable to view both item types simultaneously on one dashboard. If you reclassify "Requests" as a task item type to solve this, they then become invisible on project-level dashboards. You also cannot create things like a unified form that could create a project item, or a request item, instead needing 2 separate forms.

The ideal scenario would be for team members to be able to access all their assigned items – whether projects, tasks, or custom types like "Requests" – in a unified view on dashboards, in reports, and via the same submission forms.

The availability of custom item types in Wrike prompts a question: Why not just create a project item type named "Tasks" and categorize all items as Wrike "project" types (or all as "task" types)? This approach would potentially unify dashboard views, reports, and form submissions, regardless of whether they're projects, tasks, or custom types like "Requests".

Assignee/Owner are functionally the same column, you can assign specific statuses and allowed sub-items for custom item types, and you would be able to see all items on the same dashboards, reports, automations, and forms. What are the downsides of this method, considering it seems to eliminate the drawbacks of the traditional project/task split?

0
👍 Spot On 💡 Innovative Approach 💪 Stellar Advice ✅ Solved 🪄 Remove Kudos
1 comment

Hi Nick Giordano, thank you for creating this post! It is definitely an interesting one. Although your suggestion could be taken of as a workaround for this limitation, the system understands tasks and projects differently, therefore, this solution would work only considering that all users would understand that the task you created is actually a project and not a task, which might lead to some confusion.

There will be some important limitations in case you decide to go forward with this idea. For example, you can't use dependencies in projects, only tasks can have predecessors and successors. Also, some inbox and email notifications are based on tasks and not on projects. You can learn more about this here and here.

Tasks and projects are two different item types and were designed to serve different purposes. Having that said, I wouldn't recommend following this workaround.

I've passed your feedback on to our Product Team, thank you once again for sharing your use case in such detail, posts like this help our team to continue improving our platform 💪

Although this is not exactly what you were looking for, I'd like to mention that public links in the New Table view have been recently released, which you can use to share information about projects and tasks even with people who don't have a Wrike account yet.

Please, let us know if there is anything else we can do to help or if you have any additional questions 👍

Juan Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover

Juan Wrike Team member Become a Wrike expert with Wrike Discover

0
👍 Spot On 💡 Innovative Approach 💪 Stellar Advice ✅ Solved 🪄 Remove Kudos

Folllowing List for Post: Why keep the default Project/Task item types with custom item types now available?
[this list is visible for admins and agents only]

Top
Didn’t find what you were looking for? Write new post