Project plan structure in Wrike

Hello everyone,

I manage complex projects using a WBS structure in Wrike. I work with nested projects, and I’ve noticed that in Wrike reports, it’s only possible to display the immediate parent project of a task. I’d like to pull up the root project or a higher, useful level in my reports without losing my structure.

Has anyone found methods or workarounds to get around this limitation (e.g., custom fields, multiple tagging, naming conventions)?

Thanks in advance for sharing your experiences or best practices!

Find more posts tagged with

Comments

Claude Perreault

In an attemp to better explain the issue here are additional informations:

It concerns the ability to structure our project plans with a clear, hierarchical sequencing system.

Specifically, we need to assign a numbering structure that reflects the project’s work breakdown hierarchy — for example, using levels such as 24-1154, 24-1154.1, 24-1154.1.1, and so on, as shown in the GSS_WBS_SEQ column in the example I’ve attached below.

This type of structured numbering is essential for us to maintain clarity in project tracking, reporting, and invoicing.

I initially tried using the task ID, but it doesn't follow the project hierarchy. A temporary solution was to create a custom field to manage this manually, but since custom fields cannot be made mandatory in Wrike, it often gets overlooked when team members update the project plan — which makes consistency difficult to maintain over time.

Given the operational impact, I would greatly appreciate your guidance or recommendations from the community on how to implement or automate this kind of hierarchical numbering within Wrike, or any possible workaround that would help us manage this reliably.

I’ve attached an example of our current project structure for your reference.

Thank you very much in advance for your help — I look forward to your advice.

Michael Minovsky

Hello Claude,

Michael, PM for Analytics here. Can you please summarize to me - you want to show the full hierarchy of your WBS like you can in table view but in reports or do you need something more to achieve your goal? The first message was clear to me and sounded just like this but reading the second one, I am not sure if that covers your needs fully.

Best,

Michael

Claude Perreault

Hello Michael,

Thank you for your message and for taking the time to clarify — much appreciated.

To confirm, while being able to display the full hierarchy of our WBS in reports, similar to what we see in Table view, is definitely part of the need, there’s an additional, equally important requirement on our side.

What we’re really aiming for is to maintain a structured, hierarchical numbering system — like the one illustrated in the GSS_WBS_SEQ column I shared earlier — that stays consistent and reliable throughout the project lifecycle. This numbering is crucial for us not only for reporting purposes, but also for accurate tracking, invoicing, and for generating structured exports for internal and client reporting.

At the moment, without a system-enforced structure or a way to make this numbering mandatory and tied to task hierarchy, it often gets missed when plans are updated, leading to inconsistencies that create operational challenges.

I hope this helps clarify the full scope of the requirement, and I’m more than happy to discuss it further if needed.

Thanks again for your support!

Best regards,

Trevor Tollefsbol

Hi @Claude Perreault,

Thanks for sharing the details. I see you're already familiar with Custom Item Types. I have a few questions to help me better understand what level of filtering you are attempting to use in your reports and some possible methods to try in your system:

Are you using Blue Prints and Request Forms to generate new projects?
Do your projects typically have the same number of tasks, or are tasks added/removed as needed based on each unique project?
In the structure shown, it appears to have one 'Project' container with multiple tasks/sub-tasks beneath. Do you have scenarios where sub-folders/sub-projects are contained within the top level project?
Are your reports typically designed to look at a single level within your WBS structure (while showing the top-level project container)?
Do you want to display multiple levels of the WBS structure in the same report (or table/dashboard)?

Some of our own observations about reports, tables, and dashboards:

I find the filtering by 'Custom Item Type' gives much greater control over what is shown in the report, table, or dashboard when combined with other filters.
Filtering sub-tasks in reports makes it a bit more challenging to display the project structure versus table views (where the structure is grayed-out while the filtered task(s) is displayed normally).
Dashboard and tables give live updates while reports are static outputs (unless refreshed).

If you're able to answer some of my questions above, I may be able to give better suggestions.

Cheers!

Trevor

Claude Perreault

Hi Trevor,

Thanks a lot for your message — I appreciate you taking the time to dig into the details. Let me answer your questions and add a bit more context based on your observations:

Blue Prints & Request Forms:
Yes, I’m using them, but I know I am they are not optimal at this point. My goal is to develop the right blueprint structure that supports both my project delivery workflow and reporting needs internal and external (customers).
Project Task Structure:
For at least 80% of my projects, we’re working with a relatively standard number of tasks like my example given, added or removed as needed. Right now, it’s managed on a case-by-case basis, but I believe there’s potential to standardize this — I just haven’t found the right structure yet. Also, it is a bit of a discussion between commercial method and internal technical method and terminology that’s in the way making it tricky.
Project Container & Sub-Elements:
Correct — I have one main project container, subdivided by phases, with a mix of tasks and deliverables under each. There’s also a common block for project management & communication activities, where I capture all customer account-related work that doesn’t tie directly to a deliverable. This section is under a phase in my structure.
Report Structure Goal:
Ideally, I want a report that shows effort by phase and then breaks down the effort into deliverables only (value added in the view of the customer) — meaning, it would encompass both the deliverables and the time effort from tasks embedded within the deliverables or their phase.
Multi-Level WBS in Reports:
Yes, and this is where I struggle. Different tools in Wrike (reports, dashboards, tables) don’t offer the same level of flexibility in accessing and displaying hierarchical information of filtering the same information.

Additional comment:
One of my key concerns is that this whole process lacks a Poka-Yoke (error-proofing) control. Meaning, if a user doesn’t follow the intended structure or process, the system won’t prevent it, which often leads to messy data and reporting issues. I haven’t yet found a way to enforce or control this structurally within Wrike.

Another example, I have created custom filed like the project # or customer name. It is easy when someone add not the document that field. And in some cases, it is just to replicate from the original project container.

About your observations:

I agree that filtering by Custom Item Type gives better control — but only in the table view.
The limitation is that if the custom type isn’t a ‘Project’ type, subtasks don’t roll up their time to the parent. If I make it a project type, it does roll up, but then users only see this parent in their timesheets without a clear link to the actual overarching project, which causes confusion as many projects share the same task structure.
Somehow it seem every corner I take brings me other issues or limitations.

What I’m really aiming for:

A clean, reliable way to report time effort:

By Customer
By Project
By phase
By deliverable (value added items)
While preserving visibility on the overarching project
And ideally, introducing some process controls to avoid user errors in task/project structuring.

If you have ideas, workarounds, or best practices to recommend — or know of Wrike setups with more rigid WBS enforcement — I’d be happy to hear them.

Thanks again Trevor — really appreciate your help!

Cheers,
Claude

Michael Minovsky

Hi Claude,

are you still using the custom field to manage your WBS hierarchy IDs? I am afraid we cannot automate that but I am thinking about how to better enforce it so it is not forgotten.

One option would be to create an automation that prevents users from changing a task status without having this field filled in. It would also notify them in case they try to do so.

Another option is to make this report/view/dashboard status when it comes to columns so users would always have it visible. But I guess that might not be enough, right?

What are your thoughts now, after some time?

In general, we are going to converge similar features which should then help us optimize the one unified experience we shall keep. There will be ongoing investment into dashboards and less so to reports. Once we launch multi-level grouping in dashboards, I suggest that you use those because all the gaps will be closed there by preference.

Best,
Michael

Claude Perreault

Hi Michael,

Thanks a lot for your message and for thinking through potential ways to make the WBS hierarchy field more reliable — I really appreciate your continued support.

I still intend to use the custom field approach to manage the WBS hierarchy IDs, but I haven’t yet found a fully effective way to implement it. As you anticipated, ensuring consistent usage remains a challenge, especially as project plans evolve and multiple users contribute to updates.

The idea of using automation to block status changes unless the WBS field is filled in sounds very promising — it could definitely improve compliance and reduce errors. I can also see other potential use cases for this type of Poka-Yoke logic through automation rules. I’d be very interested in exploring what that setup would look like. For example, what kind of automated action would you suggest to trigger if someone attempts to change a task without populating the WBS custom field? Also, when creating automation rules with multiple conditions, would we need to build a separate rule for each condition, or can we group them within a single rule (how does and/or work in this case)?

Regarding visibility of the WBS field in dashboards/views/reports: while helpful, as you mentioned, visibility alone isn’t always sufficient to ensure consistent usage. Enforcement mechanisms would be a great complement.

I was also wondering — since we're talking about future direction — what it would take to make custom fields available as a grouping option in the Timelog view. That functionality would be extremely useful for us and I’d be curious to know if that’s feasible or potentially planned for future improvements.

In any case, it’s encouraging to hear about the direction Wrike is taking, especially around dashboards and multi-level grouping. Once those capabilities are live, I’ll definitely be looking to shift toward dashboards for structured WBS reporting.

Thanks again, and I look forward to hearing your thoughts.

Best regards,

Michael Minovsky

Hi Claude,

I cannot comment so much on the timelog view but we will support timelogs in dashboard tables in the future and that will then have grouping in it.

Best,
Michael