Project plan structure in Wrike

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.

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,

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:

1. Are you using Blue Prints and Request Forms to generate new projects?
2. Do your projects typically have the same number of tasks, or are tasks added/removed as needed based on each unique project?
3. 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?
4. Are your reports typically designed to look at a single level within your WBS structure (while showing the top-level project container)?
5. 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:

1. 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.
2. 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).
3. 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

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:

1. 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).
2. 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.
3. 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.
4. 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.
5. 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