You can set up a Request Queue where users can enter occasional requests that are not planned work on a project.
For more information about how to create a Request Queue, see "Creating a Request Queue."
You can customize the Request Queue by editing the Queue Setup tab of a project.
When adding or modifying features in the Queue Setup area, you impact all future issues and requests that are submitted to the project. The changes you make do not retroactively impact issues or requests already on the project.
To customize the Queue Setup tab of a project, you can edit the following sub-tabs:
- Queue Details. For more information about understanding the information included in the Queue Details tab, see "Understanding the Queue Details Tab."
- Routing Rules. For more information about setting up Routing Rules, see "Creating Routing Rules."
- Queue Topics. For more information about setting up Queue Topics, see "Creating Queue Topics."
- Topic Groups. For more information about setting up Topics Groups, see "Creating Topic Groups."
The Queue Details tab is where you designate a project as a Request Queue. This tab manages information collected on a request form and determines who can access that information.
When setting up the Queue Details tab in a project, consider consulting to the following information:
- Understanding Queue Type
- Understanding Queue Properties
- Understanding New Issue Fields
- Understanding Email Settings
Publish as Help Request Queue:
Selecting this field identifies this project as a Request Queue and all incoming issues are considered Requests. When this field is not selected, the project behaves like a standard project in Workfront and all incoming issues are added on the Issues tab of the project.
Who can add requests to this Queue?
This indicates who has access to the Request Queue.
- Anyone — Allows all active users with a license to submit requests to the queue.
- People with view access to this project — Users with View rights to the project can submit a request to the queue.
- People in this project’s company — Users in the same company as the project can submit requests. The company is shown in parentheses when this option has been selected and the project is associated with the project.
- People in this project’s group — Users in the group selected on the project can submit requests. The group is shown in parentheses.
Share with These Links:
If the Publish as Help Request Queue option is selected, a Direct Access URL and Embed Code become available for the Request Queue. To use either option, a person must be a Workfront user.
The following options enable you to provide direct access to the Request Queue and Request Queue forms to users outside of Workfront. Users must already have access rights to the Request Queue in order to gain direct access. Using either option described here does not automatically grant access to users:
- Direct Access URL: When a user accesses this URL from a browser, the user is taken directly to the request queue within Workfront. Users must first log in to Workfront before gaining access to the request queue.
To provide users with a direct URL to a queue topic or topic group, navigate to the request queue and select the queue topic or topic group that you want users to access. The URL in the browser updates accordingly. Copy the URL from the browser and distribute it to users.
- Embed Code: Use this HTML code to embed the request queue form as an iframe within any HTML page.
If users are not already authenticated to Workfront when they view the page where the code is embedded, the Workfront login dialog box is displayed. After users log in, the Request Queue form is displayed.
NOTE When displaying a Request Queue in an iframe, only the form is displayed. Navigation components and logos are not displayed.
In order for the request queue form to be displayed when using this embed code, you must enable the Allow embedding of Workfront in an iframe setting in your system setup. For more information about enabling embedding of Workfront in an iframe, see "Configuring System Preferences." If this setting is not enabled, the iframe is displayed as blank.
You can adjust various aspects of how the embedded form is displayed, as follows:
Adjust the size of the frame
Modify the "width" and "height" attributes.
By default, the width is "500" and the height is "600"
Direct users to a specific Queue Topic or Topic Group
Add the "path" parameter to the src URL. You can find the path parameter by navigating to the desired Queue Topic or Topic Group in the non-embedded form and inspecting the URL.
Show and allow users to change the pre-configured Topic Group drop-down list
Use the "path" parameter by adding the "showPreSelectedOptions=true" parameter to the src URL.
Detect when the form has been submitted
Add a "message" event listener to your web page's window and checking if event.data.type is requestSubmitted. 'event.data.newIssueID' will be set to the ID of the created issue.
The following are the four global issue types in Workfront:
- Bug Report
- Change Order
These types can only be renamed by a system administrator when issue statuses are created at the system level. Each type selected here will be available on the New Issue form and you can select more than one type. Using more than one type can help organize multiple requests coming in. For more information about configuring request types, see "Configuring Request Types." (this article is yet to be written)
The default duration is the length of time it typically takes to complete an issue. This becomes the default for all incoming issues and can be modified manually. Duration is generally set in hours, days, or weeks. The Default Duration of an issue is the same as the Planned Hours on the issue. The Planned Completion Date of the issue calculates based on this field.
The default for the issue Duration is 1 day or 8 hours. If your system administrator set the Typical Hours per Work Day as less than 8 hours, the Default Duration for issues is still 8 hours. For example, if the Typical Hours per Work Day is set to 7 hours, the Default Duration for issues is 1.14 Days or 8 hours. For more information about how to set up the system Typical Hours per Work Day, see the "Timeline Calculations" section in "Setting Project Preferences."
People from the same company will inherit the same permissions for all requests.
When selected, all requests submitted to the queue show for users in the same company. Users can view these requests in the All Requests tab located within the Requests area. Activating or deactivating this feature impacts all future requests. It does not retroactively impact existing issues.
When someone makes a request, automatically grant...
Automatically grants the type of permission a user has when they submit a request to the queue. Setting permissions here saves time, rather than having to grant permissions for each individual incoming request. Choosing this option impacts all future requests, but does not retroactively impact existing requests.
When an organization uses approval processes with incoming work, the user can associate an approval process with the Request Queue. An approval process is automatically initiated with all incoming items. Approval processes must first be created by the system administrator in order for this field to display.
It comes from Routing Rules that have already been setup on the project. Use this field to attach a Routing Rule or change the route when necessary. Choosing a Routing Rule here applies the same routing to all the issues submitted on this project. For information about creating Routing Rules, see Creating Routing Rules.
Understanding New Issue Fields
Predefined fields are available on the form. By default, 'Issue Name' shows on all forms.
Use the check boxes under Show the following selected fields to all users to select additional fields to display.
Show all selected and unselected fields to
This field defines who sees the unselected as well as the selected fields on the New Issue form.
- All Users (Plan Licenses) - All users who have a Plan license can see the selected as well as the unselected fields.
- People with view access to this project (Plan License) - Those users with a Plan license that also have View rights to this project can see the selected as well as the unselected fields. The rest of the users who can submit requests to this project can see just the selected fields.
- No Users - No users can see the unselected fields. All users who can submit requests to this project can only see the fields selected.
The drop-down list for the custom forms displays all available custom forms for projects and issues. A custom form must be created before it is shown in the list. If there are no custom forms in Workfront, nothing is displayed in the drop-down list. To learn how to create custom forms, please refer to Creating Custom Forms.
This section is linked elsewhere, do not edit the name.
You can allow issues to be added via email. This enables anyone with a valid Workfront account to send requests using email.
You can allow issues to be emailed into a Workfront project only if you designate the project as a Request Queue.
For more information about setting up an email account to allow users to send issues to a project in Workfront, see "Enabling Users to Email an Issue into a Request Queue Project."
To set up the email account associated with a Request Queue, specify the following information in the Email Settings area:
- Allow Issues to be added via email: Select this option to allow issues to be added via email.
- POP username: The full email address (including the domain name) where the POP account is created. For example, firstname.lastname@example.org
NOTE Do not use your personal email address as the POP username. Instead, create a new email address dedicated for only this purpose - to allow users to email issues to this account.
IMPORTANT It is very important that you are using a POP email account. No other email protocol is supported for this setup.
- POP password: The password that corresponds with the user name that you created.
- POP server: The server of the third-party email service where the POP account lives.
For example, pop.gmail.com.
- Enforce SSL/TLS: Select this option if you want the connection to always be secure. Depending on the third-party email service that you are using, this might be a requirement.
- Port Number: If Enforce SSL/TLS is selected, specify 995 as the port number.
- If Enforce SSL/TLS is unselected, leave this field blank.
- Click Test Configuration and ensure that you get a message stating that the configuration was successful.
For more information about setting up the POP account, including specific information to the POP configuration settings, see "Enabling Users to Email an Issue into a Request Queue Project."
THIS ARTICLE IS LINKED IN OTHER PLACES. DO NOT CHANGE NAME OR URL.
When updating POP account information here, also update information in these articles:
Allowing users to reply to email notifications:https://support.workfront.com/hc/en-us/articles/217221137-Allowing-Users-to-Reply-to-Email-Notifications
Configuring Email Notifications: https://workfront.zendesk.com/hc/en-us/articles/217202727
Enabling Users to email an issue into a request queue project: https://support.workfront.com/hc/en-us/articles/217236977