Do you have questions from Experience Makers The Skill Exchange on Apr 13?

[KristinFarwell]

If you have questions, or want to chat more about something you heard in Experience Makers the Skill Exchange event on April 13th, you in the right place!

Let's keep the conversation going - leave a comment below with one of your favorite tips and tricks you heard, or with any unanswered questions. Feel free to tag the speaker of the session if it's specific to their presentation.

Thanks to those who were able to join us, and thank you to our wonderful expert speakers!

I imagine the biggest question is - was this recorded?! The answer is YES. The recording will be available next week to anyone who pre-registered. If you did not register in advance, we hope to post the archived files to Experience League at some point soon. Stay tuned!

[AnthonyIm]

Hi Everyone - for those that have questions or use cases for Calculated Fields, we have a thread going on here: https://one.workfront.com/s/question/0D54X00007Y8fnLSAR/skill-exchange-continue-discussion-on-calcul...

Feel free to join us there as well. 😎

[TracyWood]

Hi Adobe Workfronters! Thank you for joining us today at the Skill Exchange. Appreciating that the true value of any software lies in its use and that takes people, adoption is one of the biggest challenges Sys Admins and champions face.

I've attached the Guide to Adoption Surveys to this post. This guide has been developed to gauge sentiment, identify knowledge gaps, as well as identify opportunities for additional training and enablement.

Remember to reiterate "the why" and "what's in it for me" every step of the way to your end users. Adoption is a continual process that involves listening to feedback, making changes, holding trainings, and breaking habits in favor of new ones. Continue to spread the good Workfront word and listen attentively in return to your end users. The goal is having all users consistently and effectively using Adobe Workfront -- a technology that in of itself continues to iterate, expand, and improve the process of work management on the daily.

Cheering you on!

Tracy & the Adobe Workfront team

[J_Hobbs]

This is great, thanks for sharing @Tracy Wood‚

Here is an idea. It would be helpful if Workfront build a Template Blueprint using this document as a guide.

That way it would be easier for more users to put this guide into play within their organization..

[MattMi3]

I like this idea @Jonathan Hobbs‚.

I've started a separate thread for @Kristin Farwell‚ , @Tracy Wood‚ and I to discuss what that blueprint may look like.

Thank you for sharing this thought.

[Tracy_Parmeter]

Hello, I have a question on the project limit for the number of issues. It was mentioned yesterday that the limit is 10,000 per project. I searched this site for documentation on this and I did see in the Project Limits Overview preview text that it did list this but when I click to open the link to read more I get a "How Embarrassing" error. Did this limit get removed? I ask because I looked in our instance to see what count we were at for issues on some of our request queue projects and we have several over 10,000.

[skyehansen]

I don't know why that link is broken but here's a link that seems to work: https://one.workfront.com/s/document-item?bundleId=the-new-workfront-experience&topicId=Content%2FMa...

[Tracy_Parmeter]

Thank you, Weird because I have a request queue project with over 48000 issues on it and it's still functioning fine.

[skyehansen]

we have one high volume team (like about 10k requests per year) and we broke them out by year so every year they get routed to a different yearly project. The request queue stays empty, it just gets configured to route to whatever the new year's project is.

Our reasoning to them was that we didn't want all their eggs in one basket along with whatever slow load times would come with trying to load X issues at one time. It could be that in the past few years, Workfront has changed the limits, but this isn't something I need to test. Everyone seems happy enough with us chunking out their work like this.

[MoniqueEvans]

Agreed with Skye. Personally, once I got the warning that we were close to the limit I capped the queue and made a new one. Didn't want to take any chances.

[EricaLo]

@Skye Hansen‚ or Monique, are there any resources or documentation on how to move completed requests from our request queue so we avoid ever reaching the 10,000 request limit?

[skyehansen]

My best advice would be to never leave requests in your request queues to begin with, completed or otherwise.

Use this article https://one.workfront.com/s/document-item?bundleId=the-new-workfront-experience&topicId=Content%2FMa... and set up routing rules that route your submitted requests to other projects. Every time you get close to 10K (in our case this shakes out to yearly), just create a new project and edit your routing rule.

This ensures you're not the one having to move large numbers of requests at any time.

[EricaLo]

I'm hesitant to do this because we have some reports that rely on our current queue that I don't want to mess with. Do you know if there's a way to make requests automatically be removed from the request queue and transferred into a designated project when their status changes to "Closed"?

[Heather_Kulbacki]

I've got a ticket in to support to ask some questions about this because we have a request queue with 17,000+ issues in it. Never received any warning or error. Their first response was anything over 10,000 issues "can cause performance issues." We haven't noticed any performance issues yet, but those 17,000+ requests have racked up in just 6 months, so creating a new project for every 10,000 seems like a bit of a pain.

I'm mainly wondering what kind of "performance issues" to expect. If people are having problems submitting new requests, that's a big problem and we'll have to do something. But these issues are converted to projects and not much is really done with them after that other than each issue being closed out when the project closes.

[skyehansen]

This is exactly what Fusion was made for and the scenario is pretty easy to write.

[Heather_Kulbacki]

That's what I was figuring I'd have to do. But hoping I can add it to my "when I have time" list and not squeeze it into my "oh crap, this needs to be done now list"

[Sheri_Whitten]

@Heather Kulbacki‚ did you find any resolution with your support ticket? All our issues are sitting as completed in the Request Queue - but they've all been converted to projects. Are you actually supposed to convert the issue to a project and then route that issue to the project? If that's the case, I can't imagine getting my users to do both steps...

[Heather_Kulbacki]

@Sheri Whitten‚ I'm still waiting to find out what sort of "performance issues" to expect. With that info I can then ask the team that uses that request queue if they've experienced any of those issues... yet.

Since we do have Fusion, I suspect my best bet will be to have Fusion create a new project every few months and move any new issues that come in from the existing request queue to the new project as they come in.

I can't imagine getting users to move them either. If I didn't have Fusion I would probably bulk move issues myself every so often.

[EricaLo]

If I were to route new requests to a new "master" project, then wouldn't every request's "resolving project" field display that master project? We display that resolving project field on our requestors' dashboard so they can easily see if the request has been converted to a project yet, as well as have a quick link to their project once it's active.

[Heather_Kulbacki]

Hi Erica

No, the "resolving project" on an issue is the project that issue was convert to, not the project that issue sits in.

[EricaLo]

Ahhh that makes sense! Thank you for answering my questions. I joined my company's WF admin team after our request queues were set up, so I have no knowledge or experience in how they work.

So let's say I'd like to manually move all requests completed in 2019 to a new Master Project called "2019 Requests," would I just create the project, then bulk select the requests from my current request queue and click "Move to" and select the 2019 Requests project? Would my requestors still be able to access those old requests if needed (like would removing old requests from the request queue affect accessibility/visibility)?