Creating Request Forms
|
Availability: Legacy Business, Legacy Enterprise.; Unavailability: Legacy Free, Legacy Professional.; |
|
Availability: Business, Enterprise, Pinnacle.; Unavailability: Free, Team.; |
Important
Users on the old Team Plan, purchased before November 24, 2024, can still create Request Forms in Spaces.
Space admins can create request forms in their spaces. Account admins and owners can create account-level request forms. On Enterprise accounts, this right can be revoked from account admins.
Once a request form is created it can be submitted by any user or (optionally) non-Wrike users.
Space admins can only build request forms in the spaces they're admins for.
-
Navigate to the space where you want to create a request form.
-
Click the gear icon under the space's name to open the space settings.
-
Select the Request Forms tab.
-
Click Create a Request Form if it's the first request form in the space, or + New form if the space already contains forms.
-
Click on your profile picture 1.
-
Select Settings 2 from the drop-down menu.
-
Click Request forms 3 section in the sidebar.
Alternatively, you can also access the request form by clicking the + in the top-right corner of your workspace, selecting the Request option from the drop-down menu, and then clicking the Manage forms option.
Once you've accessed the request form builder, some information is required.
-
Enter a name for your request form 1.
-
(Optional) Provide a description for your form to help users understand what it's for and when to submit it 2.
-
Move to the left-hand panel and specify:
-
Response settings:
-
Select if the form should create a new task or project or create one from a custom item type, blueprint, or an existing item 3.
Note
To create from an existing item select Create task from... or Create project from... in this dropdown, then select the relevant tab in the pop-up, and click on the relevant option there.
-
(Optional) Select a status for the task or folder that will be created after form submission 4.
-
There are several possible sub-scenarios when no status is explicitly set in form settings:
-
When a form creates an item from a template e.g. a Blueprint, or an existing task, the created item preserves the status of the original item, regardless of the default workflow of the save to location.
-
When a form creates an item from a Custom Item Type, the item is created in the first active status of the workflow specified in the Custom Item Type settings, regardless of the default workflow of the save to location.
-
When a form creates an item from scratch, the default workflow of the save to location comes into effect.
-
-
(Optional) Select the folder, project, or space where the items created via the form should be placed 5.
Note
If you do not choose anything at this step, the item created via form submission will be put in the Shared with me folder.
-
(Optional) Select a user to assign the created task or project to 6.
-
(Optional) Set up an approval to be created via the request form 7.
-
(Optional) Reschedule around 8
This feature allows you to easily adjust schedules within request forms. You can reschedule based on the start or end date of a specific task, which may not necessarily be the earliest or latest task in the project or a subtask within a task.
-
(Optional) Add a prefix 9
If you had selected the Create task/project from... option, you can set a prefix for items created via this form and/or reschedule them. When someone submits the form, the answer they provide to the question designated for setting the prefix is added to the title of the newly created subtasks, or if it’s a project — to the titles of all items within it, but not to the main item itself.
-
-
Form sharing:
-
Select who should be able to see the form: everyone in your account, specific users and groups, or nobody in your account. If nobody in your account is selected, you must enable a public link; otherwise, Wrike will not let you publish the changes 10.
-
(Optional) Check the box if you want to enable a public link to the form (for non-Wrike users) and if it should trigger email notifications or contain a CAPTCHA security feature 11.
-
-
-
After creating a request form, you can add more questions to the form by clicking on the + Add button 1.
-
Choose the question type you want to add from the list 2.
-
Enter your question 3 and, depending on the question type, available answers.
-
(Optional) Enter a description 4 to add additional information about the question. This information is visible to requesters but won't appear on the resulting task or project.
-
Toggle Answer required 5 to make a given question mandatory to complete the form.
-
You can make questions and answers in your request form conditional, so users are redirected to different questions based on their answers.
-
You can map responses, telling Wrike how to use certain answers in the created task or project.
Note
You can add clickable links that start with http:// or https:// to questions, helper texts, and headers when setting up or editing existing forms.
-
Publish or Save your request form 6.
-
Click Save to create a draft form that isn't live and you can edit it later. Only admins can see requests that are saved in a draft stage.
-
Click Publish to publish the form. Once a request is published, all users who the request is shared with will be able to access and submit it.
-
Tip
If you'd like to add a clickable link to the question or its description, make sure it starts with http:// or https://.
Whenever a custom field is modified, corresponding options in the request forms are automatically updated. This ensures consistency across all forms, saves time by eliminating the need for manual updates, and streamlines the overall workflow.
Auto-updating takes place when a user:
-
Changes the name of the options stored within the custom field.
-
Changes the order of the options in single select or multi-select custom fields.
-
Adds new options to the custom fields.
-
Deletes the existing options.
For example, when a user utilizes a single select custom field in a request form, they can choose from the available options specified in that custom field.
-
Navigate to the regular or the database custom field which you want to edit.
-
Make the necessary changes to the custom field.
-
Once the custom field is edited, the system will automatically update any request forms that use this custom field.
Custom field settings (Regular field)
Custom field settings (Database field)
Options in the request form (Regular field)
Options in the request form (Database field)
By editing the options in the custom field settings, the changes will be automatically reflected in the request form.
Custom field settings (Regular field)
Custom field settings (Database field)
Request form options (Regular field)
Options in the request form (Database field)
The auto-update is triggered for all option changes until any options with added actions are modified (renamed or deleted).
This means you'll receive a warning notification. When this happens, you have a couple of choices: manually update the conditional logic to fit the new custom field options or click Update these options to automatically erase the removed options along with the actions linked to them.
Warning message for Regular and Database field:
Important
Clicking the Update these options button will clear only those regular options and their linked conditional actions that have been specifically renamed or removed from the custom field. Renamed database options and their linked actions will be retained.
To ensure seamless use of the Update These Options feature, it's important to recognize the distinctions between regular select fields and link-to-database fields. While both types aim to keep your forms up-to-date with the latest option configurations, they operate in distinct ways, especially regarding how options with conditions are handled.
To help you navigate these differences and fully understand the behaviors of each field type, please refer to the comparison table below.
|
Scenario |
Regular Select Fields |
Link to Database Fields |
|---|---|---|
|
Newly added/Deleted Option from CF/DB without Conditions |
Deleted options are removed without any warning. |
Deleted options are removed without any warning. |
|
Deleted Option from CF/DB with Conditions |
Options are kept with an Update these options button. |
Options are kept with an Update these options button for the form editor, but the submitter will not see any removed options. |
|
Combined Deleted Options (Conditions + No Conditions) |
All deleted options are kept with an Update these options button. |
Only deleted options with conditions are kept with an Update these options button for the form editor. The submitter will not see any removed options. |
|
Renamed Option without Conditions |
Options updated without any warning. |
Options updated without any warning. |
|
Renamed Option with Conditions |
Update these options button required; options updated, conditions are lost. |
Options are updated without any warning, and conditions remain linked to renamed options. |
|
Renamed Combined Options (Conditions + No Conditions) |
Update these options button required; options updated, conditions are lost. |
Options are updated without any warning, and conditions remain linked to renamed options. |
When creating request forms, you can set date constraints for date-type questions to ensure that selected dates are a certain number of days or more after the form submission date. This means users filling out the form can only pick dates (e.g., due dates) that meet the criteria specified by the form creator.
For example, if you set a constraint of 5 days, and a user submits a form on January 1st, they will only be able to select dates from January 6th onwards.