Suggestions on comprehensive Workfront Documentation for my Admin Team

[JonH8675309]

I'm looking to create documentation to act as a knowledge base for administrators that is specific to my instance of Workfront. We are starting from scratch so I'm open to ideas or any existing documentation from others have built this for their instance from an Admin perspective.

You don't need to share your documentation but if you have a template you'd be willing to share that could be used by others that would be a great place to start. I was considering going to the setup section and going from top to bottom and listing out how we have customized for each item. If there was something already out that that is intuitive or formatted for this work I'd like to avoid reinventing the wheel if possible.

Thanks much.

[skyehansen · Accepted solution]

hey Jon,

I know there are a few admins out there who have recently mentioned inheriting an instance so I think it's a great time to revisit this type of question with a new crowd.

I'm wondering if you can also share what knowledge base currently exists there (if any). It's ok if there's nothing existing (it's not unusual) but I would probably have a different answer or different advice if you weren't working in a vaccuum.

If nothing exists, or if nothing intuitive exists... I think documenting your setup area is a great first step. We keep this info right in Workfront as a workfront project (i.e. each listing in the setup area is a task in the project, and any configurations we discover, are listed in the task description). Of course, going through the setup area is also a good way to start discovering the potential cleanup areas (layout templates, roles, access levels, teams and groups that have no active users in them anymore). Links to other areas, like miro boards, sharepoint, etc. can be stored in the project/task's documents area.

Side note: the objects in the setup area are ALSO a good way to add documentation to the system. Regular users are unable to see description fields for roles, custom forms, access levels, layout templates etc -- even statuses -- anything they can't see is a place where I can document why the object exists. Anything I build, I try and document as soon as I build it. Example -- Reasons we build out teams are for notifications, routing, sharing, or reporting -- all team descriptions should have reason codes built into their description. I've had consultants ask me if I have anything documented, and I just point out that everything that has a description is documented and they just have to run a report on whatever they are curious about.

The other topic I tend to document are the workfront builds that are in play. Personally, I document the stakeholders and why it was built -- so I know who to check in with, and what they value. But this is also a place where I document the key structural elements in play -- what portfolios, programs, templates, roles, teams, forms... everything they use in their build to make their work in workfront. This way when any random user asks you a question, within a few minutes, you -- in theory -- should be able to locate their build through their homegroup, team, role or layout template names (anything attached to their user profile, basically) by searching your "build projects", and go through the elements of their build as a refresher to how they work in the system.  Knowing what your stakeholders value will give you more insight on what KPIs they are looking at or some flags on what they are likely to adopt.

[ScottMo1]

Hi Jon,

We are challenged with the same topic.   But, we have created a manual in Word.   We started with all the Settings, gave a brief description of our set-ups and why we did it.   We use Workfront to run our entire manufacturing business, so we have many custom forms, fields and reporting.   We have spent the time documenting these in our Workfront Manual.

The challenge we have, is the many updates from Adobe, so we spend more time updating the Workfront Manual (which right now is a bit out of date).    It is almost a full time job to keep up with the Adobe changes, our changes, and any reports or filters that the users create and share with their teams.

Happy to share any further insights if you are interested.

Scott

[WibkeKu]

In addition to the manual @ScottMo1 mentioned that was created in Word we have also created Excel sheets to show more details for the settings in order to have a better overview if we need to get into the nitty gritty. The Excel sheets are referenced in the manual and help keep it a bit cleaner.

[Lyndsy-Denk]

Here's an older thread where I share a couple templates I created from my own governance documentation. My knowledge base comes in a couple different forms:

Governance documentation (a.k.a. The Nerdy Details)

I have many documents beyond the two linked in the above thread; basically one for each object type or area of Workfront. These fall into three categories:

1. System documentation
2. Specific object documentation, such as request queues, custom forms, and project templates
3. Tech support and process documentation

In general, my documentation includes:

• Summary/If You Read Nothing Else
• Here's how we use and manage this area/function (also called "Here's how you don't break the system")
• Sometimes a map of the data or construction

This documentation has plenty of detail and includes tables, outlines, definitions, hyperlinks to other documents and references, comments with random thoughts, appendices for data dumps or freewriting of ideas. Often I start with a hot mess and then organize the content to make more sense. The secret is to stick with it and revisit at least annually. I link to my documentation in the projects and tasks I schedule for system maintenance and auditing.

User guidance (a.k.a. What You Need to Know)

Check out the Introducing the End User Communications Cookbook - Adobe Experience League Community - 607439. It features two of my approaches:

• SharePoint site with Microsoft Team community
• Roadmap with release notes dashboard

These areas reinforce and explain our governance to various user audiences. I make mine bite sized and visibily appealing in hopes that people actually read.

[KatherineLa]

As someone adopting/merging an instance into mine right now, this one is near and dear to my heart. The Setup section is a great place to start, and you've got some excellent suggestions there already. I'll skip that part and go into other reports that I'm using to quickly get a grasp on other moving pieces. 

Overall I've got a large config dashboard that shows me the status of a collection of key data domains in each instance. 

For people, I've got one for groups, and one for teams within groups that has columns like this. Key filters look for active groups or teams that have no active members in them for quick cleanup.

If you use the Company object extensively, I've got another that exposes any key fields on it's custom form that are used later in KPI data and highlights anything where key inputs are missing. Saves me troubleshooting time early.

For Templates, help yourself see configuration issues quickly like this - 

Every request queue makes an appearance:

Custom forms, and custom form fields also have their own dashboards for quick reference. 

I use these reports with my leadership teams as a sort of proxy that lets them see the world as I see it in setup but also doesn't give them the access to edit anything they shouldn't too. Happy to share the text mode behind some of the columns if needed.