[From Wrike] Process guardrails in Wrike? Question to you + Exciting update coming!

Question

Hey admins! Alina from Product team here 👋

I am happy to announce that this year we bringing more governance experience updates! This time, we are looking to expand capabilities around how you manage, control and communicate your process guardrails to your end-teams.

Question to you 🎤 How do you manage the following needs today and do you see yourself incorporating these improvements into your processes?

* Required fields (aka "Mandatory custom fields") to collect data on work handoff and streamline reporting. And you heard it here first: I am happy to confirm that this long-awaited update will be available in Labs this quarter already! 
* Required person to change the status. While no confirmation yet, do you see the need in your processes to specify who exactly can change the status (for example: only Managers can complete projects; only people from Design user group can set tasks in Design)
* Workflow lifecycle visibility and time targets. While no confirmation yet, do you see the need in your processes for:* specifying expected time to transition between one workflow status to another (e.g. between New and In progress it should take 2d).
* later report on planned vs. actual status transition time, workflow duration variance (time to complete planned vs. actual) and delays (planed vs. actual variance)
* report on outstanding approvals and see approval delays (for how long are decisions overdue)

As always, will be happy to learn how these improvements might land into you processes. Let me know!

Chris Pettican · Answer

Hi Alina,

Required fields - This would be extremely useful for us. However, we have occassions where something required may not be known immediately BUT it would be handy if the workflow couldn't advance beyond a certain stage without this required information. So, a user could populate a new project with the information they do have at the time, but then they wouldn't be able to flag it as say, complete, until all the required fields are complete. For our situation, we record a purchase order (custom field) in a custom item with a custom workflow. This purchase order would be required for invoicing but we may start a project whilst awaiting the purchase order to be delivered. It would be useful for us to flag this as a required field for the 'Completed' stage or the workflow but not have its absence hinder the starting of a new project. Hopefully that makes sense?

Required person to change the status - I can see this being useful. Our project managers should be having the final sign-off on completed work that is delivered and ready for invoicing. I would welcome this being restricted from the rest of the team. There are some tasks we also use for the finance team (Finance user group) which it would be useful to restrict status changing to that group only.

Workflow lifecycle visibility and time targets - This could be useful for certain statuses where time pressures are a bit more sensitive.

With regards to workflow approvals, it would be extremely helpful to have more dynamic approvers rather than them being fixed into the workflow. We have multiple project managers, each who are responsible for their own approvals. I don't want to add all of them, because for most of them the approval is irrelevant. We already have one dynamic option - the task creator. However, this person is usually an administrator rather than the PM. It would be helpful to have an extra approver option linked to a custom people field, so whoever is entered for that field will be the approver when it reaches that point in the workflow.

Alexandra Torres · Answer

Hi @Alina Kucherenko We currently require a small set of fields at intake via request forms (client, brand, line of business), and this works well for ensuring requests land in the right structure from the start.

Where we see the clearest opportunity is role‑based control on status changes, especially within complex escalation paths. Our workflows often involve multiple assignees with distinct responsibilities, and while expectations are documented, they can break down when work is moving quickly. Approvals help, but bandwidth and capacity constraints still create bottlenecks or allow work to advance before the right role has engaged.

Being able to restrict status transitions by role or team, for example, preventing work from progressing unless it’s moved by the manager of a specific program, would give us stronger governance without adding more process. We’d apply this immediately within our escalation structure and rely less on approvals as the primary gate.

The biggest value for us overall is time‑in‑status and workflow variance visibility. Defining expected time between statuses and reporting on actuals would provide powerful insight into delivery health, bottlenecks, and friction points. Reporting on status aging, delays, and variance would be invaluable for managers and leadership, especially if paired with automations and integrations with HubSpot and Jira to better manage SLAs and surface escalation risks earlier.

Julien Wuytens · Answer

Required fields are a must-have.

I would definitely use the "Required person to change the status" feature to ensure our internal process are being followed. e.g. only top managers can move a budget to a "validated" status, only controllers can change the status of a project to "closed" when the last documents have been sent to the clients.