Feature Request: Prefix Builder for Projects & Automations
Why Wrike Needs a Dynamic Prefix Builder
Wrike is a leader in workflow automation, but one major gap remains: the ability to dynamically generate standardized project prefixes based on form submissions and custom fields.
Currently, teams relying on automated project creation have no way to systematically generate naming conventions that reflect the details of a request. This results in inconsistent project names, manual renaming, and a lack of automation flexibility—especially when dealing with blueprints and automated workflows.
The Problem: No Way to Auto-Generate Project Prefixes from Request Forms
Many organizations use request forms to collect key details before a project is created. However, there’s no built-in way to:
-
Extract data from form submissions to automatically format project prefixes (e.g.,
{Department}-{Year}-{ProjectName}). - Apply prefix logic at the blueprint level, so that all projects follow a uniform naming convention.
- Recall prefix rules in automations when using the "Name" field to generate new projects dynamically.
This leads to manual workarounds, such as manually renaming projects after they’re created or relying on inconsistent naming structures across teams.
Proposed Solution: A Prefix Builder Based on Custom Fields & Form Inputs
Wrike should introduce a Prefix Builder that allows users to:
✅ Generate Project Prefixes from Request Forms – When a request form is submitted, Wrike should dynamically pull values from custom fields (e.g., {ClientName}-{RequestType}-{Year}) to generate a structured project prefix.
✅ Apply Prefix Rules to Blueprints – When a project is created from a blueprint, the prefix should follow a predefined logic based on custom field inputs (e.g., {TeamCode}-{CampaignName}-{Qtr}).
✅ Recall Prefixes in Automations – Automations should have the ability to reference and apply a project’s prefix when naming new projects. This ensures that when a project is cloned, split, or generated by an automation, the name follows a consistent and logical structure.
✅ Ensure Sequential & Structured Naming – Subprojects and phases should inherit their prefix from the master project based on predefined rules (e.g., {MasterProjectPrefix}-{PhaseNumber}-{TaskGroup}).
How This Enhances Wrike’s Automation Capabilities
💡 Eliminates Manual Renaming – Projects auto-name themselves based on request input, reducing administrative work.
💡 Maintains Consistency Across Teams – Ensures standardized project naming for easier tracking, searching, and reporting.
💡 Strengthens Workflow Automation – Enables automations to generate structured, sequentially named projects, improving visibility and organization.
💡 Improves Form-to-Project Automation – Requesters input key details once, and Wrike automatically builds a well-structured project name.
Example Use Cases
🔹 Marketing Team Requests: A form collects Campaign Name, Year, and Department, and Wrike automatically names the project {MKTG}-{2025}-{NewProductLaunch}.
🔹 Product Development: A team submits a sprint request, and Wrike names the project {PD}-{SprintNumber}-{FeatureName} automatically.
🔹 HR & Client Onboarding: A form submission collects Client Name & Service Type, and Wrike names the project {ClientCode}-{OnboardingPhase} upon creation.
🔹 IT Service Requests: A request form captures Request Type & Location, and Wrike names the project {IT}-{NewOfficeSetup}-{City} based on the inputs.
Let’s Make This Happen! 🚀
If this feature would help your team, upvote this post and drop a comment on how it would improve your Wrike workflows! The more support this gets, the better the chance Wrike implements it!
Wow! it would be very useful
This would be amazing. Anything that can be done to help us know at a glance what something is would be very helpful as in the end tweaks like this could save a great deal of time.
Wow! Yes, I have been thinking this so many times. Glad someone wrote it down! Upvoted!!!
Sounds amazing!
I just would like to have this functionality right way expanded to project description an custom fields!
Florian
This is a good suggestion, Conrad Aleshire! Thanks for creating such a detailed and clear feedback post along with examples. I’ll make sure it reaches the right team to look into. 👍
Thanks everyone for expressing your thoughts and adding your support for this post!
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
Yes, please
I would like this, please.
Hi Amy Hildreth and Steve Mruskovic, thank you both for supporting this suggestion. If you haven’t already, please add your upvotes to the post above by clicking on the “👍”. This will help us assign a relevant status once it gains 60 upvotes.
In the meantime, if there are any developments, we’ll keep you in the loop. Thank you!
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
It would also be great if the item ID could be included as a prefix. We're switching to Wrike for our intake form process and we handle a large number of tickets. Our old system automatically used the ticket number as the title (ie. Request #51234) and our team and business partners are used to referring to tickets that way. In Wrike, however, the item IDs are hidden in the details of the ticket. Even if I move the ID field to the top of the custom item type it's not very prominent, and you still have to click "more" to see it. This will make it hard for submitters to follow up on specific tickets with us since we'll just be looking for their manually entered title among what might be dozens of similar titles. It would be a lot easier if we could automate a prefix to be something like "Request #1234567890: Title of Request."
Hi Eli Pollard 👋 thanks so much for sharing this detailed feedback and use case. It’s really helpful to understand how you were using IDs in your previous system. I’ll share this with our Product team and will keep you posted if there are any updates 👍
Rohan V Community Team at Wrike Wrike Product Manager Become a Wrike expert with Wrike Discover
Rohan V Wrike Team member Become a Wrike expert with Wrike Discover
Upvoted. Not being able to dynamically create task names, task dates, etc. is a seriously missing functionality.
I don't know what unicorn businesses the developers seem to think use their products, but a recurring issue across many threads is the assumption that manual corrections and workarounds are acceptable solutions to functional gaps.
There appears to be an expectation that entry level or frontline users will reliably remember or are capable of executing manual corrections. The purpose of implementing structured software is to reduce, and ideally eliminate, human intervention and error in process-heavy work.
Wrike is deeply embedded in our business and manages a large portion of what our ERP does not. However, whenever a process requires formal governance, we consistently encounter functional limitations within Wrike.
For example, when a product becomes unavailable, a resourcing task is created. Once resourcing is complete, an automated subtask called “Price Review” is generated and assigned to the commercial team. This task is added to the broader price review folder and linked back to the resourcing task.
While the automation itself works, the resulting task names cannot be identified to a specific product because there is no ability to control prefixes dynamically through automation. This forces manual intervention. Either the resourcing user must remember to rename the task, or the commercial team must navigate back to the parent task to do so. If neither occurs, the price review folder quickly fills with indistinguishable tasks titled “Price Review”.
The alternative is systems administrators continually scanning for and correcting these tasks to prevent ambiguity from leading to inaction. At that point, the automation no longer reduces effort. It simply shifts manual risk and workload elsewhere.
Agreed. It also seems to suggest a lack of understanding of how business processes work at a large scale. Manual workarounds may work for small businesses that only manage a dozen or so projects at a time (although it would still be tedious) but it is absolutely not scalable for large businesses managing potentially hundreds of projects at once.