Request forms in Wrike are one of the best tools for managing work intake. They structure information almost immediately at the point of submission and connect to blueprints and route work automatically. The limitation that creates governance risk for teams managing work across multiple spaces is that each request form can only save to one location.
A submitted request that needs to be visible in two spaces, for instance, a client delivery space and an internal operations space, cannot do that natively. You have to find a workaround.
The two most common workarounds I use are blueprints and conditional field logic.
With blueprints: set up the form to trigger a blueprint on submission and configure the blueprint’s Create to functionality to place items in multiple locations. The request arrives and the blueprint fires, with the resulting work item getting structured and placed according to the blueprint’s configuration.
With conditional field logic: add a mandatory single-select question to the form where each option corresponds to a different parent folder for cross-tagging. The person filling out the form makes a selection and the task is tagged accordingly.
Most teams use the conditional field approach. They configure a mandatory single-select question.
With blueprints a blueprint that is modified or deleted can cause requests to stop landing where they should, often without warning. The form will keep accepting submissions but items will end up in the wrong place, or not be created at all. By the time someone notices, a backlog of work may have accumulated.
With conditional field logic editing the custom field that drives the routing, renaming an option, removing it, or modifying it can break the logic. The form will still work but the placement is wrong and there is no way to alert admins. For enterprise setups where client and product custom fields drive routing, ownership, and reporting, these are exactly the kind of thing that surfaces during an account audit or when a client asks why their project submissions have not been appearing in the right space.
Multiple Save to locations would solve being able to define multiple save locations directly on the request form, without depending on blueprint integrity or conditional field logic, which would make intake significantly more reliable. It would be a durable, form-level control that does not break when blueprints are modified or fields are renamed.
From a governance perspective, requests would consistently land in the correct spaces, intake behaviour would be stable through account changes, and teams would not need to maintain workarounds purely for these purposes.
But what can you do in the meantime?
Build your workaround as intentionally as possible. Using blueprints for routing means assigning an owner to those blueprints and documenting which forms trigger which blueprints. Any change to a blueprint referenced by a form should go through a review. Using conditional field logic means treating the routing fields as protected fields, where changes require admin review and documentation of the downstream impact.
Audit incoming requests periodically to verify they are landing where they should. Monthly is enough for most teams. It takes a few minutes and catches routing failures before they become large issues.
Vote on this in the Wrike community. Product decisions follow documented demand, and the more clearly the problem is articulated, the higher it sits in the priority queue.