Workfront

Q1: My two cents... We always keep the project brief custom form at the project level since it typically applies to the project as a whole.

Q2: We struggle with this as well. We've found for tracking SLAs, keeping deliverable count to one per project is imperative. We have yet to solve for how to generate multiple projects for multiple deliverables in a simple way via one intake form. And we don't have an answer for the brief either. As of now we have a brief for each deliverable. But if its part of a multi-deliverable campaign, having one collective brief would be ideal. 

We struggle with this, but the Creative Brief lives at Request level so it tags along as a Request is converted (by a PM for the most part).  When there are multiple deliverables (often), the Request is converted multiple times, with each Project following a naming convention.  One cannot look at the Request to see what Project resolved it, though, only the most recent converted Project appears.  We had a consultant make a calculated field, but it is very tricky to find, so...

My team is in the process of building the creative brief fields into our intake form in an effort to eliminate offline docs and streamline the intake process. We'll need to test w/some key mktg and product partners but we're hoping this will be an efficiency.

This is how we decided to do it out of the gate 5 years ago. The intake form just kept getting bigger and bigger and more complex with calculated fields and display logic.

Our users have been complaining about having to fill out "too many fields" like forever. So now, we're trying to take a step back and look at what really needs to be in Workfront vs what could/should be contained in a separate (attached) brief. We will also be looking into breaking our single intake form into smaller forms with separate request queues to handle different types of deliverables. 

Not sure if one way is better than another - but we are definitely having issues with users complaining about the # of fields and with them not filling out the forms completely or correctly as a result.

One team I worked with had a process where if multiple deliverables were needed based off one request, we would create a program to put all the projects into. Then convert the first deliverable into a project and duplicate that project as many times as needed. The main downfall is if the form changes on one, it is not reflected on the others.

That's a good thing to call out! The copying is easy/convenient, but if there's changes, you might have to do some work to get it updated everywhere!

We are outlining our processes starting with our video projects. We decided to split the workflow between ideation and production. Ideation is before Workfront, but we can record some of the tasks there once we start a project. Sometimes ideation doesn't lead to anything, so that's why we made that decision. Our video team developed a creative brief and will work on it with the brand manager (requestor). We wanted to have it separate from the custom form so that people not in Workfront could work on it together before submitting. Of course, this may change in the future. We just launched in March, so MVP and iteration is our live right now. 

Great idea for breaking apart the work!

Hey @JHulet !

Just to clarify, it sounds like you have a request form and later attach a creative brief that pulls in some of the data? The calc field is a good way to handle! When I was a customer, our request form matched our project form (for the most part - there were a few questions we didn't need right away that were added on the project form). 

If you're struggling on having users FIND the form, it may be worth setting up a report with all the fields so users can in-line edit. You could apply that to the layout template (if it's applicable to most/all projects) or ensure your users have easy access (pinned, in their favorites, linked in a task, etc.). 

Multiple deliverables - this is a HUGE debate (we've talked about it a couple of times in the Admin Chat for Marketing & Creative). Some of it comes down to reporting. For me, we were reporting on our total number of deliverables/projects, so each thing had to be it's own project. If it was a LARGE campaign, we'd have the requester put in a request for the overall campaign and copy the project for all of the sub-projects. The original project would often serve for the overall creative direction and we could add cross-project predecessors to access all the deliverables and see their progress. There's no right or wrong way, but I'd factor in your processes and reporting.

Good question! Scope creep is a real thing. Following!

Hey Ross! I know this is a big question for a lot of folks, especially those of us that implemented large custom forms with tons of logic.  I personally had separate Word docs for each of my custom forms, so that we could make those revisions, but I know that @LeslieSpier used an Excel spreadsheet to track what existed, and then make changes. I feel like the best example of this was from the great and powerful @MoniqueEvans! She shared her complex spreadsheet with all the questions and logic, but she said that it made it easier to make those changes and track what was going to be "hidden" via a section. Hopefully other folks have ideas on this too!

In general, I'm a big fan of:

1. Document the existing state. I often use Word because it offers the track changes function. I can insert flow charts and tables to organize my information.
2. Mark up your proposed changes.
3. Build a test in your preview or sandbox environment.
4. Build it in Workfront production.
5. Consider rolling out to a small group first to work out the kinks, then expanding use.

When it comes to custom forms and big changes, I almost always opt to build a new form. Keep in mind that:

• You can reuse fields in more than one form, but if you make changes to that field it will also change in the other forms. Sometimes it makes sense to make a new but similar field, but I try to avoid it because it could segment any data you report on from that field.
• You'll need to make a decision: Do you need to retroactively apply your custom form and populate the data accordingly? It's a lot of work. Often my stakeholders opt to just phase out the old form by letting projects with that form naturally reach completion. Within a few months we have all projects on the new form.
• Take inventory of the implications on your reporting. You'll need to plan for fixing all your reports.

I've attached a template map I use for my request queues. There is a section for mapping out the custom forms I'll need. Grab that table and go to town on planning your change.

@LB103 Have you thought about utilizing display logic for the different deliverables so that fields only appear based on the deliverable selected? Rather than adding additional forms, since that is a manual process. 

yes, but each form has a lot of questions because there are so many teams involved.

Some of our internal clients have been trained to provide a separate creative brief for the types of work they frequently request, and the information is valuable to have in-hand as the new work kicks off, though often there are changes to the information as a result of the kickoff, and then even more changes to the scope as the project progresses, making it challenge to ensure all are on the same page! Some of our custom forms include several of the questions from our creative brief form so we have the benefit of additional context, though that assumes the requestor is providing good quality detail (and not copy/pasting from elsewhere). We'd love to conduct a new creative brief refresher training for our WF users, once we've reviewed input from others on this thread!

I'm curious as to why your designers won't click into the Project Details section - is it because they aren't sure where to go, it's an extra click, there's too much scrolling because not all fields are relevant? Have you thought about creating a report that has only the necessary custom form fields as columns so that it's a bit easier to read or find (if attached to dashboards, custom tabs, layout templates, default landing pages, etc.)

We have issues with this part, also. The Designers do click into the Details, and we leverage separate forms that are just creative brief details or dashboards in that same way; however, they still often comment that the layout of information in both areas is very excel-ish and there are a lot of extra clicks regardless. They frequently ask for a more updated/user friendly interface that suits creative-minded people in a better way. As an admin and a very visual person myself, I would love to have more control over how the information displays and the interface also. Thank you! 

Hey Brenda!  The struggle on this one is real and common!  I had this challenge as well, and at first, our Project Managers were accommodating when Stakeholders would attach docs, but eventually, we had to hold the line.  Part of it was because we couldn't have stakeholders uploading a file after the project kick-off with their new requirements.  Usually that would change the entire scope and timeline of a project, so we had to hold firm.  We ended up having (many) meetings with stakeholders to capture anything that they had listed in their separate docs (Word, PPT, or Excel) and include a reference in the creative brief custom form, and set the expectation that everything must be completed prior to kick-off, and then requirements are locked.  If changes are needed, I required a Change Request be completed so that the Project Creative Brief field could be updated.  For our users, being able to just rely on what was in their Project Creative Brief made all the difference for their work sanity.  Curious how others handle this challenge though!

Have you seen the Introducing the End User Communications Cookbook - Adobe Experience League Community - 607439? There are some great tactics and tools to consider in this resource.

Educating users well is a practice in my opinion. I'd love to do more, but there is only one of me as a parttime admin, so I scale my efforts by:

• Posting a short tip every other week. Often these tips build on each other to make them digestible. For example, I'm have a series about predecessors. Tip 1 is a cheat sheet on predecessor types, Tip 2 is setting cross-project predecessors, Tip 3 is setting a delay, etc. 
• Announcing release features and changes. I don't emphasize everything; just what I think is relevant for my stakeholders.
• Posting alerts in Microsoft Teams when there is a major system issue to let users know that, no, it's not just you and, yes, someone is paying attention to the integrity of the system.
• Hosting office hours to have casual conversations with users about pain points, questions, or general nerdiness. I get lots of ideas for tips, maintenance, and optimizations.

All the above tactics aim to support change management because, first and foremost, managing change is about fostering trust. Specifically for change, I:

• Create projects to track admin work so stakeholders can watch progress and contribute as needed. These projects include tasks to plan for change: interviewing and testing with key stakeholders, communicating that change is coming/almost here/has arrived, assessing how the change is going once in place. The bigger the project, the more change there is to manage.
• Publish a dashboard that lists all the admin work that's happening, including regular maintenance, releases, and optimizations.
• Connect with managers then, if necessary, join standing team meetings to talk about what's changing and address questions.
• Document processes and locate that documentation in a transparent and searchable location.
• Build reports and dashboards to manage change. Old habits die hard, so these reports can help monitor behavior and make it easier to hold users accountable and, if necessary, fix in bulk. Eventually you can stop using these reports as users adopt the new ways of working.
• Scale the change. When it comes to creative briefs for us, we currently create PowerPoint decks and they live outside Workfront. To change this, I'm planning to propose these phases to roll out over months:
  • Phase 1: Get into the habit of uploading the brief to the Documents area of the project. Bonus points for storing the file in SharePoint and linking to it.
  • Phase 2: Build a custom form for programs for a high level brief.
  • Phase 3: Build a custom form for projects to get more specific.

This is great, and we are trying to do the same.  The Strategists want to create their Creative Brief in different formats.  Excel, Powerpoint, Word, etc.  They are loth to follow a common format.  So, The WF "Opportunity Summary" (a combined Creative Brief, Go To Market, Media Plan, etc.) is a big section in Request with too much display logic and they have to fill it out.  That's the Intake process, and the Strategist is free to attach whatever they want, or whatever they present to the internal Client.  Workfront adherents can print a pretty nice, detailed .pdf directly from the Request section (custom form) but it can be too dry to present.  

Everyone wants to do their own thing. Unfortunately for these types of colleagues of mine, our company is ISO certified and things like a creative brief need to be standardized for compliance reasons. "Compliance" and "regulation" are sometimes helpful tools in bringing people into alignment without making an actual human the bad guy.

I write a quarterly Update.  It's a page or so long and I just add the new edition to the ever-growing original.  That way it lives at one place and engaged users can pin it.  It goes out as a .pdf attached to an Announcement.  Every new user is introduced to it as a reference for how "we" use Workfront.  It usually contains some gentle reminders of our own best practices, so Managers can point out misuse to individual contributors. 

I have a Slack channel where I make announcements. I also hold office hours/trainings as needed. My goal is to create a center of excellence on a Teams site so it can be searched back more than 90 days. We're using a free instance of Slack. 

I love what others have shared below, so I'll just add to that! Continuous education for your users can be a full-time job, but I realize that as a Workfront Admin you have a handful of other duties to manage on top of just training and enablement.

• Identify the channel(s) that your users most frequent - whether that be a SharePoint page, Slack/MS Teams, Workfront, email, etc. and then offer recurring (important!) tips through that channel. It could be a weekly tip or video, a monthly newsletter, a quarterly blog - whatever works best, but make sure that you are consistent in your timing so users know when to expect it. This may require you doing something for 3-4 months and then asking for feedback to see how the content is being received. 
• Mentorship opportunities - if you have users who are wanting to take on extra work to earn promotions or find ways to develop their leadership skills and they have expertise in Workfront, ask if they would be interested in offering help or mentorship opportunities to new users. This is a great way to delegate work to users who want to take ownership and build their resume! 

Where do you want to see the tier data? (Project name, project details, etc.?)

Would it be possible to have one queue with the tiers as queue topics? That might help with the labeling?

The tier data will mostly be referenced in reports. 
We use complicated queue topics and topic groups to route requests to the right PMs. Adding another layer of complexity does not seem like a good idea.

A Request can be converted many times to multiple Projects, but they need to be named distinctly.  All of the data tags along to every Project. Big downside is that the Request will only show the most recent converted Project.

I had a similar situation with a previous employer and we included the questions from the other teams on a custom form within the request form on Workfront. Example: if the deliverable selected was email, then the email custom form populated and we included questions the email team needed. Then when the project was ready for the email team, we would export the email custom form for handoff.  Having it all in Workfront also helped with reporting across teams. 

I don't think there is a wrong way, but there are tactics that ultimately can simplify people's lives. In your case, it sounds like you have some grander challenges to address before your users are receptive to using a form for creative briefs. Taking a step back to look at all the related processes and how they might work together could be complex, but beneficial in the long run. I've tried to push a creative brief form before and ran into similar pushback: No one wanted to fill in the form. So I had to dig into why and see if I could influence a change in culture. Three years later and there is now chatter about integrating briefs more into Workfront.

Alternately, sometimes you have to build a prototype to help your decision-makers see the potential. It's a gamble because they might not like what they see; they still might not be ready.

I also started inviting certain decision-makers to the Adobe Experience League Events when I saw a related topic because sometimes they'll hear someone else say "This is a best practice" and it flips a switch in their brain to be more receptive.

Do any of your teams share fields? Then the data would pull into the respective forms...

Would also love if anyone is willing to share their creative briefs as examples!

Hi! One thing that has helped us a lot is creating some separate forms that pull in only the necessary Creative Brief information. It is helpful to narrow it down a lot to only was is important for the creative team, so we have a separate form to fill out; however, when there are larger forms where some of that information is already filled out, we could just duplicate some of those fields onto the Creative Brief field so they pull whatever information was entered. We could use calculated fields to properly format some of the things Creative needs to get started into what they'll need to save them some steps. 

This also helps as a sub-step if you can't dedicate the time to narrowing down the larger forms at first. Just make a separate form that duplicates the fields from other places and direct them to only look at/expand that specific brief form in the Details. 

Reporting is definitely a large piece of it but another factor is trying to keep all your information in one place. Once we got teams trained, it was much easier to track all the information and changes in one place/one source of truth vs. having a bunch of different versions of documents or emails floating around. 

We tried to keep the request form as simple as we could and had more questions/info that could be filled out on the project form later - that helped the requesters from getting too fatigued in the original request process! We would often fill out the additional info during the  kick off meeting, or shortly thereafter.

@NicholeVargas @LeslieSpier @CynthiaBoon

Not everyone received the link to join the Coffee Break call today after registering. Is there any way for you to resend the link? 

Thank you!

Jen Mancini

Sorry for the confusion, @JenniferMa10. The Coffee Break is a virtual, text-only event - there is no webinar or call.

To clarify here, the Coffee Break is specifically this thread. All questions, comments, and responses from our experts will occur solely on this thread. Feel free to post your questions/comments in this thread over the next hour and one of our experts will answer as soon as they get a chance!

Hey Stephanie!  I just checked our internal channels, and we haven't heard of a specific issue with the audit logs, but that doesn't mean there isn't one. It might be related to SSO, but I'm not sure. I'm glad you opened a ticket, as Customer Support has way more access to research these types of challenges, so they can definitely get to the bottom of it.  

Hey @brittanylang - I haven't heard of any changes coming to the UI for the custom forms page (particularly ones that would get creatives/designers excited). I had a hard time getting users to go to that page, so I always pulled the data into reports (@CynthiaBoon  says she did too) and used conditional formatting to make it easier to digest. I even went into the text mode and changed the HEX codes to brand colors in some cases  

Thanks for the feedback and all that you guys do, Leslie! We'll continue to work within the realm of what we have available knowing that. Have a great day! 

A big tip that you'll not come across accidentally is using Section Breaks and display logic for Sections rather than individual fields.  So "Is this a Print Project?" and if it is, display a Section with all of your current Print Shop intake form fields.  It takes a minute to figure out how Section breaks work, particularly how to end a Section...

Hey there!  For me, the best approach was to start with a dry erase board (or an online version of that), and have a brainstorming session of "how does a project get started."   Starting with the big questions first, like which department or team will handle the request, and then build logic when the asks are getting more specific.  For example, are they asking for a video, if yes, then all the questions that the video team needs would open, or if they are asking for an event, they will get different questions.  Mapping it in a flowchart, but doing it out loud with reps from some of your creative users will really help getting the form in the order that makes the most sense.  We also got feedback from the stakeholders that would open requests before we fully launched to make sure it made sense to them as well.  The best creative brief custom forms always seemed to come from a collaborative effort for us. 

Thank you! We already have that flowchart in place and we were wondering about the nuances between "skip" and "display". Additionally, it is not quite clear how can we share our form(s) with stakeholders that are not part of Workfront. Is it possible? 

@RLepoudre You can reference native fields in your custom form via calculated custom fields. So if your brief is on the project, you can add a calculated custom field that would pull in the project Budget field. If you type in Budget to your calculation field, it will show as {budget}.

As for auto-populating the Company of the requestor, you can also do that via a calculated custom field on your issue (request) custom form. The calculation would be {enteredBy}.{company}

This is a great request!  We would also love examples of how automation can help this process!  Hopefully some customers are willing to share here.  We also have a "Making the Case for Fusion" event coming on August 27th, so this might be a great question for our speakers as well.

Learn: Making the Case for Workfront Fusion

That's amazing - thank you, Cynthia! Fusion is the BEST. It saves us so much time and risk. 

Have a great day!  

It is possible to insert images into custom forms (check out @CynthiaBoon 's Top 3 video about adding images to custom forms) but depending on the number and size needed, that could get cumbersome. A link may still be your best bet (maybe with an arrow image or something above it to help draw attention to it?) with lots of user training and reiteration to get them used to the process.