TL;DR: Use multispace custom fields and workflows, required fields, and cascading fields together to standardize work across teams. Set up shared fields once, enforce the right information at every workflow stage, and automatically keep data synchronized across projects, tasks, blueprints, and request forms. Explore four real-world governance setups for client services, product, PMO, and marketing.
Hello Admins! I'm Damiano from the Wrike Product Marketing team.
Today, I'd like to dive into workflow governance in Wrike and how it can help you control your work. Multispace custom fields and workflows, required fields, and cascading fields. You've seen each of these land on its own over the past few months. Individually they each make your life easier. Configured together, they govern the whole path from intake to reporting, and that's where the real value shows up for you as an admin.
Why it matters right now: together these give you real control over how work gets captured, and a clear view of what's actually happening across your spaces. You decide what data has to be there, it stays consistent as work moves, and nothing slips through half-defined. Clean, structured data is also what makes Wrike's AI worth trusting, so this foundation pays off there too.
💡 A quick refresher on the four
- Multispace custom fields and workflows: Build a field and a workflow once and reuse it across specific spaces. No duplicates, no forcing it onto the whole account, consistent data everywhere.
- Required fields: Mandatory guardrails at the workflow status level. Work can't move to the next stage until the fields that matter are filled in.
- Cascading fields: Enter data once at the project level. One click syncs existing subitems, new ones auto-fill, and it works natively with blueprints and request forms from day one.
Here's the part that makes them one system
An account admin shares both the custom field and the workflow into the same set of spaces. From there, a space admin in any of those spaces can put the field to work locally: make it a required field on a status transition in that shared workflow and cascade its values down through projects, blueprints, and request forms.
So it's one field, governed once, then enforced and cascaded consistently everywhere it lives. Data is clean, AI is happy, and you are in control. (You’re also happy—admit it.)
Now, four use cases you can set up with all these features working together.
🤝 Client services delivery
The problem you're solving: a client submits a request and delivery teams are ready to start, but internal details like PO number, billing code, or delivery owner are still missing. Work begins anyway, and hours get logged before the commercial details are confirmed.
- Start with multispace custom fields and workflows: the account admin shares Client, PO number, and Billing code, plus the client delivery workflow, across the relevant spaces, so every team gets the same structure for intake, execution, and reporting without duplicating configuration.
- Then the request form captures what the client can realistically provide, like client name, requested deliverables, and due date, and cascading flows those values from the parent item down to the delivery subitems, so teams start with the right context from day one.
- And a required field on the workflow transition becomes the internal control point: before work can move from New request to In progress, the delivery or account manager must complete the fields the client wouldn't provide, like PO number, billing code, and delivery owner, so execution can't begin until the operational and financial details are in place.
🚀 Product lifecycle
The problem you're solving: features move between discovery, build, and release with missing effort estimates and inconsistent priority labels, so roadmaps drift from reality.
- Start with multispace custom fields and workflows: the account admin shares Product area and Release version, along with the product lifecycle workflow, across the design, engineering, and product spaces, so one release report reads the same everywhere.
- Then the space admin adds a required field that blocks the move from Discovery to In development until effort and the shared Release version are set, so planning runs on real inputs.
- And cascading carries those shared Product area and Release version values from the epic down to every subtask. Because this works natively with blueprints, when engineers spin up new technical work packages, those new items automatically inherit the cascaded values, ensuring they never mislabel what they're shipping.
📊 Portfolio management (PMO)
The problem you're solving: every team labels priority and status its own way, so the portfolio roll-up is a guess and executive reviews start with data cleanup.
- Start with multispace custom fields and workflows: the account admin shares Strategic priority and Business owner, together with the delivery workflow, across every team space, so the portfolio roll-up reads the same the moment you open it.
- Then each space admin adds a required field that blocks the move from Proposed to Active until those shared fields are filled in, so nothing enters the portfolio half-defined.
- And with 1-click cascading, the PMO can instantly apply that shared Strategic priority from the parent program down to every single existing project and task underneath it. The whole hierarchy stays perfectly aligned retroactively, with zero manual data entry required from the project managers.
📢 Marketing
The problem you're solving: a campaign gets reconsidered and a new channel is added mid-flight. The change has to reach every deliverable underneath, and the team picking up the new channel needs to supply the details specific to it before they run with it.
- Start with multispace custom fields and workflows: the account admin shares Campaign and Channel, plus the campaign workflow, across the demand gen, brand, and regional spaces, so the same fields and workflow exist everywhere the campaign touches.
- Then cascading does the distribution: the campaign manager updates the Channel field once on the top-level item, and it flows down to every deliverable underneath, so nobody retypes the change on - let’s say - task 41.
- And the change becomes a control point: when Channel changes on specific item types, an automation moves the item into the matching workflow status, and a required field on that status makes the assignee populate the channel-specific details before they can move the work forward.
💬 Now show us yours
Those are four setups we've seen work, but as admins you'll build combinations we haven't thought of. That's exactly what we want to hear.
Have you tried to combine all or part of them? Drop a comment below!
Need a refresher on any single feature? The original announcements have the full details:
