Every marketing and creative team has a version of the same problem. Work arrives by email, by chat message and by a spreadsheet somebody maintains out of goodwill. None of it is described the same way twice, and half of it is missing by the time it reaches whoever will do the work.

The cost rarely appears as a line item. It shows up as rework, as designers chasing requirements, and as a leadership question that takes three days to answer. Adobe Workfront attacks the problem where it starts: intake. Instead of a form that drops text into a shared inbox, it makes the arrival of a request the first structured event in the life of the work.

Table of contents

1. What is a request queue in Adobe Workfront?
2. Why intake design decides what your reporting is worth
3. How a submitted request finds its owner
4. Request queues are not Workfront Planning request forms
5. The role of AI in intake
6. What to plan for: licensing, limits and one-way decisions
7. Conclusion: why intake is the cheapest thing to get right

What is a request queue in Adobe Workfront?

A request queue is not a separate module. It is a project published to the Requests area so that people can submit work to it, and Adobe is specific about the condition: only projects in Current status are visible there — the most common reason a new queue seems to be missing.

Adobe states that a Workfront administrator must create request queues and make them available to users before the functionality can be used. Only one part is mandatory — setting the project up as a request queue; topic groups, queue topics and routing rules are each documented as optional, and each adds classification or automatic assignment. The queue’s audience is a design choice too, from anyone at all down to only the group that owns the project — which is how several departments share one account.

Why intake design decides what your reporting is worth

A request that arrives complete starts immediately; a request that arrives as a sentence starts a conversation, and conversations do not appear in reports. Reporting quality is downstream of intake quality: if the requester never chose a topic, nothing can route on it, and if the form never asked for the channel, no report can group by it.

How a submitted request finds its owner

Topic groups are the menus that classify requests by common features — the Adobe example for an IT queue is an on-site group and a remote group — and they can be layered. Queue topics are the menus inside them; Adobe documents no limit on how many a group or project can hold, and they are a reportable object type.

Routing rules are where intake becomes assignment. Adobe describes them as controlling what Workfront does with an issue submitted to a queue, and defines queue topics as working in conjunction with routing rules to assign incoming work automatically to a user, a job role, a team — or to place it on a project. That last option is underused: a rule can send a request to a different project than the one designated as the request queue, so one front door can feed several delivery teams.

A request is an issue, and that has consequences. In Workfront, issues and requests are used interchangeably, and a request submitted to a queue is recorded as an issue on the project designated as a request queue.

Because a request is an issue, it can be converted into a task or a project once it needs real delivery work. Conversion is not lossless, and Adobe says so plainly: "Workfront removes any approvals that are associated with issues during conversion." The resolving object of the issue is overwritten as well, and there is a five-minute processing limit when converting an issue to a task — one carrying many attached documents can fail until some are removed.

What the structure buys is traceability: the list of submitted requests shows which queue, topic group and queue topic a request came through, and what it became.

Request queues are not Workfront Planning request forms

This distinction costs projects real time. Adobe Workfront Planning has request forms of its own, and the Adobe documentation separates the two mechanisms explicitly: a Planning request form is associated with a record type, and submitting it creates a record, not an issue on a project. Planning is also a separate purchase — an Adobe Workfront package or a standalone product — and Adobe notes that not all capabilities included in the Planning package are available when it is bought standalone.

Choose the wrong mechanism and you build intake in a layer that cannot route work to a delivery team. The family picture — Workfront, Workfront Planning and Workfront Fusion, and how each is purchased — is on our Adobe Workfront page.

The role of AI in intake

Adobe has dated the next step already: beginning in September 2026, AI Assistant is transitioning to CX Coworker, a conversational interface for getting work done. Today’s Workfront AI Assistant offers in-app information and suggestions in a natural-language conversation, and one documented job is finding instructions and reference material for work processes. The Adobe worked example is on this very subject: ask how to create a request queue and it returns the instructions from the Workfront documentation.

Availability is conditional rather than automatic. Adobe requires all of the following before AI Assistant can be enabled for an organization: migration to the Adobe Identity Management System, the Adobe Unified Experience enabled, a Select, Prime or Ultimate Workfront plan, and a signed Adobe Gen AI agreement on file — after which an administrator still enables it for the organization and for the access level. Establishing what you already have is part of our Adobe AI services.

What to plan for: licensing, limits and one-way decisions

Workfront documents access per capability rather than per product, and its tables often show more than one generation of plan and license at once, so scope matters. For routing rules the requirement reads "Adobe Workfront packages: Any" with "Adobe Workfront license: Standard" or "Plan". AI Assistant is stricter: "Adobe Workfront package: Select or higher" and "Adobe Workfront license: Standard".

Several intake decisions are effectively one-way. Once created, routing rules cannot be moved from one project to another, queue topics cannot be moved from one project or template to another, and neither can topic groups. A queue built in the wrong project is rebuilt, not relocated — an argument for settling project structure first.

Conclusion: why intake is the cheapest thing to get right

A request queue looks like the least interesting part of a work management platform. It is in fact the part that decides what gets asked, who it reaches, and whether any of it can be reported on later.

Softwhale designs Workfront intake as a process decision rather than a configuration task: what each queue asks for, how topics and routing rules map onto teams that actually exist, and what happens the moment a request becomes work. Our Adobe Workfront page describes where a project starts. An intake design of this kind is typically a 4–6 week engagement: discovery, the topic and routing model, and one live queue per team before the rollout.