Expand my Community achievements bar.

Do you have questions about the migration to Adobe Business Platform? Come join our upcoming coffee break and ask away!

Making a request from within a project - how do you handle this?


Level 10

For many projects, we have built requests queues into the project template so that we can connect 2 types of things together. For example, if you are creating an email and need a special photo, the photo request queue is built in, and the request lives with the email project, and not in the generic request queue, disconnected from the primary project where the request is needed.

HOWEVER, there are a bunch of projects that don't have request queues built in, as we haven't had a history of needing to make requests in those particular cases. But, now that everyone has gotten used to it, they are requesting things and since it's not built in, the requests have no custom form, no routing rules, they are basically invisible.

Building in more request queues is problematic. Every time something changes, it's a massive effort to update all those templates and projects with the queues. (Yes I have upvoted the Idea to make Request Queues a standalone thing that can be more easily attached to projects and templates)

I can't remove the Request tab from those projects we don't want people making requests from, as that impacts ALL projects.

I can't quite figure out how to train on this either, that there is no form doesn't really register with people, it looks to them like a normal request.

How do people handle this situation? Would love some advice. My feeling is that so many people are on Fusion where this problem is more easily managed, and I am not on Fusion, so ... hoping to hear what's being done.



Topics help categorize Community content and increase your ability to discover relevant content.

6 Replies


Level 2

How many legacy projects do you need to add the request queue to? I believe I have a solution, but it is a bit of a manual entry.

You can duplicate your new project template with the request queue built in and then remove all the extra data:

  • tasks
  • custom data
  • permissions
  • anything not related to request queues

You can then use that blank template as a sort of "request queue patch" template. When you attach it to an existing project you will get all the topics, routing rules added to the project (but be careful, you should only do this once or you will end up with duplicate topics in your request queues). I have done this before but only on a "on-demand" basis (or you can train Planners to attach it themselves).


Level 10

Exactly - the duplicate queue topics are what kills me. Also, adding the queue to about 12 templates is rough, and then every time someone wants to add another topic, updating them all is a killer. I'm struggling with this from a time management view. It's all do-able, just so time consuming.


Level 10

Hi Jill,


Can you provide a link to the Innovation Lab entry for "more easily attachable request queues" so I can make sure I've upvoted? ;-)


Our solution to this issue is all requests, even scope creep and addendums, always go through the master request queue. Then the request can be converted to a task on an existing project. The upcoming feature to allow custom forms to be shared across objects will make this a tad less clunky and allow better data capture (since we decided not to duplicate project custom forms to task custom forms).

This method was opted for because all our admins are part-time and we have to choose simplification and standardization over ultra-customizing. We can only realistically maintain so much and anything with high maintenance needs couldn't be used.

I had the presence of mind to see the issue of embedding request queues in invividual templates and projects as a huge maintenance issue while we were working with WF on the initial deployment. So we just created one project that serves as our sole request queue. From there, planning teams are required to convert to projects and tasks and needed.

Even this became an issue with requesters (too tedious) so our next step is instead of dozens of requesters, we are going to put 3–4 points of contact in front of WF. Requesters consult with those folks, and only those 3–4 people put in requests.


Level 10

Here is the innovation lab: https://one.workfront.com/s/idea/0870z000000PSKOAA4/detail

Converting a request to a task in a project is an interesting idea, I will ponder on that. Thanks!


Level 10

Hi Jill, Kevin, and Connor,

I'm interested in scoping out how and when me might add Queue Topics, Topic Groups, and/or Routing Rules to our Sync Template solution during our April 1 Template Maintenance Workshop, so if you'd like to join me to do so, invite you to Register.




Level 5

Hi Jill - we're also using embedded request queues in project templates to keep related work together, and I share your pain as it's quite a manual process to make any changes across multiple request queues and multiple project templates. :) Just to throw a related idea to the group: Idea: Abiity to bulk-edit request queues in project templates (workfront.com). I am also interested in Doug's Sync solution. As Connor mentions above, we also have a blank template as a "request queue patch" template that project owners can attach to their projects as needed, but it does take repeated user communication and training.