Smarter Conditional Mapping for Request Forms Using Custom Fields
In our enterprise, we manage two key custom fields used across all of our ad hoc request forms:
- Client
- Client Product
These fields drive our conditional mapping within Wrike request forms. When a user selects a client and product, the request automatically lands in the correct Wrike space → product folder → year of work. This setup creates a streamlined experience for our teams and keeps work organized by client/product/year.
However, here’s the challenge:
- We have 10+ ad hoc request forms, each supporting different disciplines.
- Any time a client or product changes, every single form’s conditional mapping must be updated individually.
- Worse, changes made to the custom field itself can break the existing conditional mapping, requiring 10+ manual updates just to restore functionality.
Proposed Solution:
We’d love to see conditional mapping controlled at the custom field level, rather than at the form level. Ideally, we could:
- Assign a landing location (folder/project) directly to the custom field value.
- If the landing location changes, we update it once at the field level and push it across all related request forms.
- Include an opt-out option for specific forms, allowing us to override the global mapping logic when a form’s workflow differs from the standard.
- Bonus: Allow spreadsheet uploads to bulk-manage destinations since we already track clients and products this way.
This improvement would significantly reduce admin time and ensure consistency across all our request forms, while still giving us the flexibility to customize where needed.
Rohan V Community Team at Wrike Wrike Product Manager Diventa un esperto di Wrike con Wrike Discover
Rohan V Wrike Team member Diventa un esperto di Wrike con Wrike Discover
Hi Alexandra Torres,
your use case sounds quite interesting! Have you considered using automation to achieve your needs? You could create an automation rule that gets triggerd by a certain custom field value and changes the location of new tasks to a specific folder. You could set up a default landing folder for all of your request forms, and the automation rule would change the location depending on the custom field value. So you'd only have to adjust one automation rule per destination folder, and not all of your request forms!
Florian
Hi Florian Kislich
Thanks so much for the suggestion! I can definitely see how leveraging automations could help in theory, and I’m going to give it a try to see if it works for our setup. That said, based on our current structure, we’d likely need to configure 50+ automation rules per year to accommodate all client/product combinations and their corresponding folders.
That’s a significant manual lift upfront, which is why I still believe having a spreadsheet upload or bulk-management option—whether for conditional mappings or automation destinations—would make this process far more efficient and scalable.
I really appreciate your input and will report back if we find success using automations as a workaround!
Hi Rohan V and Florian Kislich ,
I appreciate the quick thinking and the suggestion to use automations. We tested that path (triggering on Client & Client Product custom field values to relocate incoming items), but it becomes operationally heavy at our scale. Even with a single default landing folder, we’d still need distinct automation rules for each destination, because the routing depends on client × product × year. Across 20+ request forms servicing 2+ work years, that balloons past 100 variables and a comparable number of rules to build, QA, and maintain. That’s not sustainable for us.
Why we’re pushing for field‑level mapping or even database mapping instead of form‑level or rule‑level logic:
What would solve it cleanly (and keep flexibility):
Allow admins to assign a landing location (folder/project) to each Client and Client Product option directly on the custom field configuration. All forms that use those fields inherit the routing automatically.
Support CSV/Spreadsheet upload for those mappings (we already track client and product lists that way), plus export for audit/backup.
Let specific forms bypass the global mapping when their workflow differs (e.g., special intake streams), so we preserve flexibility without duplicating the full mapping.
This approach would cut the admin workload dramatically, prevent breakage when field values evolve, and keep our spaces/folders organized by client → product → year without needing dozens of parallel automation rules. It’s essentially the same outcome your suggestion targets—just implemented once, at the source, rather than repeatedly across rules/forms.
Happy to share concrete examples (forms, option sets, destination folders) if that helps scope the effort. Thanks again for engaging here!
Hi Alexandra Torres,
makes totally sense, I support your request!
Florian