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!
