Create a Request Queue

Go to the project that you want to set up as a Request Queue.

(Optional) Click Project Details in the left panel and add a Description to the project in the Overview area. This information displays on all new requests.

Click Queue Details in the left panel. You might need to click Show More, then Queue Details.

This opens the Queue Details section.

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 when they add a new request:

  Who can enter requests

  Description

  Anyone

  Any Workfront user with an active account can view this request queue and add requests to it

  People with view access to this project

  Users with View permissions to the project can view and add requests to this queue

  People in this project’s company

  Users who belong to the company associated with this project can view and add requests to this queue. If there is a company associated with the project, the name of the company is listed in parentheses after this setting.

  People in this project’s group

  Users who belong to the group associated with this project can view and add requests to this queue. If there is a group associated with the project, the name of the group is listed in parentheses after this setting, in gray font.

• Use the following options to provide direct access to the Request Queue and the forms associated with it to users outside of Workfront or to Workfront users using an embedded external page.

For information about embedding a request queue in a dashboard as an external page, see Embed a request queue in a dashboard.

Users must first have permissions to the Request Queue in order to gain direct access. Using either option described here does not automatically grant access to users.

TIP

Users must first log in to Workfront before gaining access to the request queue when they access the Request Queue page from another application.

• Direct Access URL: When a user accesses this URL from a browser, the user is taken directly to the New Request section in the Requests area and this request is selected by default for them.

  

  NOTE

  You can display a Request Queue in a dashboard as an external page. In this case, the request queue is preselected, but you can select any other request queue from the Request Type field. Users submitting the request can select another Request Type. Topic Groups and Queue Topics also display.

• 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 request form displays, the request name is preselected and dimmed. User cannot change the Request type. Navigation components of the Requests area do not display.

  In order for the request queue form to be displayed when using this embed code, your Workfront administrator must enable the “Allow embedding of Workfront in an iframe” setting in your system Setup area.

  For more information about enabling embedding of Workfront in an iframe, see Configure system security 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:

  Functionality

  Solution

  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.

• Request Types: In the Queue Properties section, select from the following options:

• Bug Report

• Change Order

• Issue

• Request

This is a required field and you must select at least one option.

The Workfront administrator can rename the default request types. For more information about renaming the request types, see Customize default issue types.

NOTE

When users access the request queue from the Requests area, the Request Types display as a selection only if the Request Type is selected in both the Queue Details and the Queue Topic pages.

For information about setting up the Queue Topics area of a project, see Create Queue Topics.

Each type selected here will be available on the form (you can select more than one). Selecting more than one type can help organize multiple requests coming in.
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.

• Default Duration: Enter a number for the Duration, then select from the drop-down menu one of the following duration units:

  • Days
  • Hours
  • Minutes
  • Weeks

The default duration is the length of time it typically takes to complete an issue submitted to this request queue. This becomes the default for all incoming issues and can be modified manually.
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.
If left unchanged, the default for the issue Duration is 1 day or 8 hours.
If your Workfront administrator set the Typical Hours per Work Day as less than 8 hours in the Setup area, the Default Duration for issues is still 8 hours.
For example, if the Typical Hours per Work Day is set to 7 hours i the Setup area of Workfront, 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 the article Configure system-wide 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 section , 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. Click the Access button to select from the following permissions levels:

  • View Access
  • Contribute Access. This is the default selection and the name of the Access button.
  • Manage Access

  For information about the Workfront permissions model, see Overview of sharing permissions on objects.
  Setting permissions here saves time, rather than having to grant permissions individually, for each incoming request. Choosing this option impacts all future requests, but does not retroactively impact existing requests.

• Default Approval: Click the drop-down menu to select an approval process for 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 Workfront administrator must define system-level approval processes before you can associate them with request queues. Users with administrative access to Approval processes can also create group-specific approval processes.

  IMPORTANT

  If the group of the project changes, the group-specific approval process attached to existing issues becomes a single-use approval process. For more information about how changes to the group of the project or changes in the approval process affect approval settings, see How group and approval process changes affect assigned approval processes.

  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 Create Queue Topics.

  Consider the following when adding approval processes to request queues:

  • Only active issue approval processes display in the list.
  • System-wide and group-specific issue approval processes display in the list. An approval process associated with a group other than that of the project does not display in the list.

• Default Route: Click the drop-down menu to select a routing rule for this request queue. Routing rules 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 display in the Queue Details section and before you can associate them with 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 Create Routing Rules.

• New Issue Fields: In the Show the following selected fields to all users section, select the fields that you want to be visible to all users who submit a request to the project or add an issue to this project or to the project’s tasks.

  NOTE

  • When you enable any of the Assigned to, Job Role, or the Team fields, they are always renamed to Assignments in the request form when users submit the request. You can only specify the type of assignment in the Queue Details area.

  • If you selected Assigned To in the Queue Details area, you can enter only users in the Assignments field on the request form. In this case, you cannot enter job roles or a team.

• Documents: Select this option to display the Documents section in the new request form, then select where the document uploading section should be positioned. Select from the following:

  After custom forms

  The Documents section displays at the bottom of the request form.

  Before custom forms

  The Documents section displays between the Workfront fields and the custom fields of the request form.

  

• Show all selected and unselected fields to: Select which users should see all the fields on the new request form. The following options control the access to the fields on the form.

  Which users can see all fields on the request form

  Description

  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. This is the default selection.

• Custom Forms: Select a custom form to associate with the Request Queue from the drop-down menu. You can select multiple forms, then drag and drop them in the order you would like them to display in the request form.
  Only issue custom forms are available to select from this drop-down menu. All issues submitted to this request queue, added to the project or to its tasks will have the selected forms associated with them.
  You must create issue custom forms before you can see them displayed in the Queue Details section.
  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, see Create Queue Topics.

  

Continue selecting information for the settings in the Email Queue Settings area, to allow users to email requests to the request queue project.

For more information, see Enable 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.

(Optional) To enhance the Request Queue functionality, build additional sub-sections for your queue, as well as rules to route the incoming requests to the correct team, assignee or project.

• For information about creating sub-sections for the Request Queue, see the following articles

• Create Queue Topics

• Create Topic Groups.

  For information about routing the requests to the appropriate assignee, team, and appropriate project, see Create Routing Rules.