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.

• Share with these links: The following options enable you 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 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 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.

  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 can change the Request Type. Navigation components of the Requests 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, 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 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: Select from the default options below.

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

  • Bug Report

  • Change Order

  • Issue

  • Request

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

  NOTE

  Request Types display as a selection in the Requests area only if the Request Type is selected in both the Queue Details and the Queue Topic pages. For information about setting up the Queue Details 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: 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 Workfront 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 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. Select from the following permissions levels:

  • View Access
  • Contribute Access. This is the default selection.
  • 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 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 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 approval processes display in the list.
  • System-wide and group-specific 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: 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 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 any fields that you want to be visible to all users who submit a request to the project or add an issue to the project or the tasks.

  TIP

  New Issue Fields selected in the Queue Details section are also associated with any new issue added to the project .

  When you enable any of the Assigned to, Job Role, or the Team fields, they are always renamed to Assignments in the request form, but you can only specify the type of assignment selected here.

  NOTE

  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: If you select to display the Documents section in the new request form, 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 you want to 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.

• 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. 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 about creating sub-sections for the Request Queue, see Create 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.

  TIP

  Custom forms added to the Queue Details section are also associated with any new issue added to the project .

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 articles Create Queue Topics and Create Topic Groups.
• For information about routing the requests to the appropriate assignee, team, and appropriate project, see Create Routing Rules.