You can set up a Request Queue where users can enter occasional requests that are not planned work on a project. For example, a help desk request queue can be set up to capture all user requests that come to an IT department.
A Request Queue is set up as a project. After the project is designated as a Request Queue, you can make the queue visible under the Requests area of Workfront. When you customize the Request Queue you are also customizing the form users fill out when they submit the requests.
You must have Manage permissions to the project, and you must have Edit access to projects in your Access Level to enable it as a Request Queue.
When you set up a project as a Request Queue, the project status needs to be Current in order to be displayed in the Requests area of Workfront.
To create a Request Queue:
Navigate to the project that you want to set up as a Request Queue.
Click More, then Queue Setup.
On the Queue Details tab, specify the following information:
Publish as Help Request Queue: Select this option to identify this project as a request queue. All incoming issues are considered Requests.
When this option is not selected, the project behaves like a standard project in Workfront and all incoming issues are issues.
Who can add requests to this queue: Select which users have access to add requests to this queue. You can allow the following groups of people to see the Request Queue in their Requests area of the Global Navigation Bar:
- anyone with access to Workfront.
- anyone who has view access to the project.
- anyone in this project's company
- anyone in this project's group.
Share with these links: 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 New Request tab in the Requests area and this request is selected by default for them. Users must first log in to Workfront before gaining access to the request queue.
For information about embedding a request queue into a dashboard, see "Embedding a Request Queue into a Dashboard."
- 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.
For example, if you are using the form on a request queue for an IT project, the following request types can come in to the queue: hardware, software, bug fixes, and issues.
As a system administrator, you can rename the default Request Types. For more information about renaming the Request Types, see "Understanding and Customizing Default Issue Types."
Default Duration: 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 are visible for users in the same company. Users can view these requests in the All Requests tab, located within the Requests area. At the time that this setting is enabled or disabled, it impacts all future requests; it does not retroactively impact information.
When someone makes a request, automatically grant: When a user makes a request to the request queue, the user is automatically granted the level of permission that you choose to that request. Select from the following permissions levels:
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.
Default Approval: Associate an approval process with this request queue. Only Issue Approval Processes are visible in this drop-down menu. All issues submitted to this queue will be associated with this Approval Process. Your System Administrator must configure Issue Approvals before they can be selected on the Request Queue.
If you have multiple Queue Topics associated with a Request Queue, we recommend that you associate Approval Processes with the Queue Topics instead. For more information about creating Queue Topics, see "Creating Queue Topics"
Default Route: Associate a Routing Rule with this request queue. Use Routing Rules to automatically assign new issues submitted to a Request Queue to the correct resource (user, job role, or team), and to the correct project. All issues submitted to this queue will be associated with this Routing Rule. You must configure Routing Rules before they can be selected on the Request Queue.
If you have multiple Queue Topics associated with a Request Queue, we recommend that you associate Routing Rules with the Queue Topics instead. For more information about creating Routing Rules,see "Creating Routing Rules."
Show the following selected fields to all users: Select any fields that you want to be visible to all users.
Show all selected and unselected fields to: Select which users you want to see all the fields on the form. The following options control the access to the fields on the 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.
Custom Forms: Select a custom form to associate with the Request Queue. Only Issue Custom Forms are available to select from this drop-down menu. All issues submitted to the Request Queue will have the selected forms associated with them.
If you have multiple Queue Topics associated with a Request Queue, we recommend that you associate custom forms with the Queue Topics instead. For more information about creating sub-sections for the Request Queue, see "Creating Queue Topics"
If you have multiple custom forms associated with the Request Queue, drag and drop the forms to sort them in the desired order, in the Reorder Forms section.
Allow Issues to be added via email: Select this option to allow requests to be submitted via email.
For more information, including specific information for the POP configuration settings, see "Enabling Users to Email an Issue into a Request Queue Project."
- Click Save.
Your project has now been configured to be a Request Queue and users can now add requests to it.
To enhance the Request Queue functionality, you can build additional sub-sections for your queue, as well as rules to route the incoming requests to the correct team, assignee or project.
For more information about creating sub-sections for the Request Queue, see "Creating Queue Topics"
and "Creating Topic Groups."
For more information about routing the requests to the appropriate assignee, team, and appropriate project, see "Creating Routing Rules."
***THIS ARTICLE IS LINKED IN OTHER PLACES. DO NOT CHANGE NAME OR URL.
The Creating a Request Queue section is linked to other articles, don't rename this section.