Best Way to Transition to a New Request Queue

[ljorr16]

We started with Workfront about a year and a half ago, without implementing queue topics/topic groups or routing rules. Now, in an effort to simplify requests for users (and take advantage of some of the automation with routing rules), we are adding queue topics. What is the best way to transition to this revised method? Should we create a new Queue and direct all requests after a certain date to use that new form? Then sunset the former queue when those projects are all complete? Open to any and all ideas! Thanks in advance!

[Erika_Antkowiak]

Hi @ljorr16! We have always used the request queues on our end, and as you get more familiar and comfortable with Workfront you will adjust your request queues more than once (you learn more, you change more). We have made changes to request queues and custom forms throughout the years and I recommend keeping your original request queue if you can. 

I do recommend pulling a log report to show requests submitted via that request queue to see where they are in the process (make sure to add status as a column). Depending on what your queue topics are you may want additional columns on your report. For example, if the queue topics are going to help identify which program a project should be added to you may want to add "program" as a column. Let me know if this helps or if you have any additional questions. I'm happy to help in any way I can!

[ljorr16]

That report is a great idea!! Easy way to track where things are. 

Would you recommend making the changes to the current queue? We are going from one long form based on lots of trigger questions and display logic to adding queue topics and groups, and adding smaller custom forms based on the topic suggested.

Right now I'm working it in the sandbox so trying to figure out next steps once we're ready for go live.

Thank you!

[Erika_Antkowiak]

Testing your options in the Sandbox is key (great choice)! We have always found value in using our strong base we created with our original queues. If you create a new queue you do run into the issue of users not having the correct bookmarked link, getting an error message, etc. We opt out of all that and build (or deconstruct what we already have). Our goal is to always minimize the disruption to users.

We usually plan to make changes to a queue Friday afternoon to allow users to submit everything they need to submit before that timeframe. We pair that with an email communication (1 per week) to remind users of the deadline to submit requests to the queue, when the new one will be available, how they can reach it, how to fill it out, etc. The communications could be anywhere from 3 weeks before to 2 weeks before the change depending on what you feel your users need. 

As you are making the changes to your new queue or starting anew, be aware of these risks:

• Historical Data - data can be loss if you delete fields without providing a new place for your data to go
• Existing Requests/Projects - pull a report to get a pulse of existing requests/projects submitted using the original queue to make sure that as changes are made they remain unchanged; export one to make sure you have a point in time look

I hope this helps. Let me know if you have any additional questions. I consider roll outs to be one of my specialties. 

Best,
E

[Kasey-Gagne]

We recently transitioned to an entirely new request queue and what I did was create a "redirect custom form" (which says "This form no longer exists, please click here to submit the new form..blah blah", hyperlink that text with the new request queue link, and attach it to the old request form. We kept it for about 30+ days until everyone was aware and had their bookmarks updated, etc, then deactivated it. I hope this helps! 😀

[ljorr16]

This is a great and simple idea!

[Maria_JoseMa1]

On a related topic, does anyone know what this "You will loose information if you remove the Custom Form " message really mean?

In my inherited Queue, each Queue Topic has the same Form attached.

I intend to remove them and have them added to the Queue Details for all Topics.

I did some testing in the SB and I don't seem to be missing any information by proceeding with this change.

Has anyone experienced it?

Thanks

[Erika_Antkowiak]

Hi @Maria_JoseMa1! Any time you see that message it means you could potentially lose your data on requests, projects, etc. depending on where you are seeing it. In this case, if you try to remove those original forms without creating a place for the past data that was collected using those original forms first it could cause loss of historical data. I would recommend creating the new custom forms that you are wanting to add to the queue details for all topics before removing the original ones. I would also recommend using any existing custom form fields from the original form on the new form where it makes sense. And last but not least - add the new custom form you create to existing projects, requests, etc. and ensure no information is lost in SB before removing the original forms. As you are making changes to your instance I recommend waiting to delete the actual forms, fields, etc. (from the system not from projects, requests, etc.) at least a few months.Let me know if this helps or if you have any additional questions. I'm always happy to help!

Best,
E