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.

Find more posts tagged with

Gathering votes

Status: Gathering votes

Comments

Rohan V

Hello, @Alexandra Torres! 👋

Thanks so much for posting this detailed suggestion. We’ve now forwarded your post to our Product Team. If there are any updates, we’ll be sure to share them here in the Community.

Florian Kislich

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

Alexandra Torres

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!

Alexandra Torres

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:

Single source of truth. Today, response mapping is defined inside each form; when custom field options change (or we add a new client or client product), every affected form must be updated to keep routing intact. Centralizing the “value → destination” mapping at the custom field level would let us adjust once and propagate everywhere.
Lower maintenance & fewer points of failure. Automations would require value‑specific conditions per destination (no table lookups), so any change to options or folder structures triggers a cascade of rule edits. Field‑level or database mapping reduces this to a single controlled update.
Consistent behavior across forms. Even with “Use custom fields as options” (and the newer Link to database options), mapping destinations is still configured per form. That helps with data consistency, but it doesn’t solve centralized routing.

What would solve it cleanly (and keep flexibility):

Global mapping table at the custom field level.
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.
Bulk management.
Support CSV/Spreadsheet upload for those mappings (we already track client and product lists that way), plus export for audit/backup.
Per form opt‑outs or overrides.
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!

Florian Kislich

Hi Alexandra Torres,

makes totally sense, I support your request!

Florian