Tuesday Tech Bytes

[Madalyn_Destafney]

Tuesday Tech Bytes | Part I Tips & Tricks

Hello, WorkFront Community!

You may have seen me around here the past couple years, though I’ve been an enthusiastic WF user for nearly a decade. I’ve partnered with @Jagpreet_Singh_ and SMEs across the Community for a Tuesday Tech Bytes series, where we’ll be posting some juicy ‘bytes’ the next handful of weeks (each SME posting in respective tool of expertise). Join in the fun and keep the discussion going, ask questions and learn from each other! Each Tuesday’s byte for WF will be added to this thread. Jump right to each week's post here:
Tips & Tricks Part II
Best Practices Part I
Best Practices Part II
Integrations Part I
Integrations Part II (JumpSeat)

This and next week’s bytes are focused on some tips & tricks. We have a wide range of WF fluency in the Community, so I'm starting off with three low-hanging Bytes for Beginners:

1. Use Assignment Users instead of Assigned To in Task/Issue Reports

I’ve often seen confusion about task reports not pulling in everything a user is expecting. Many times this is because they are using ‘Assigned To,’ which only brings in the primary assignment, not all assignments on a task/issue. A best practice is to use Assignment Users Name instead of Assigned To Name to bring in all users assigned to tasks/issues.

Use this:

Instead of:

2. Pull Field Name instead of ID When Name isn’t a Native Option
How annoying is it when you want to pull Program name, Portfolio name, etc. in reports and the only filter/column/grouping option you see is for the object’s ID? An easy tweak in text mode saves the day here! Say you want to show Program name in a task report column. Natively, you only have the option for Program ID:

Select that ID option, then change your column to text mode and replace all instances of ‘ID’ with ‘:name’.

So from this: valuefield=project:programID querysort=project:programID valueformat=HTML displayname=Program linkedname=project namekey=view.relatedcolumn namekeyargkey.0=project namekeyargkey.1=programID

To this: valuefield=project:program:name querysort=project:program:name valueformat=HTML displayname=Program linkedname=project namekey=view.relatedcolumn namekeyargkey.0=project namekeyargkey.1=program:name

3. Change Report Grouping Names
WF makes it easy to change a report’s column/header name. This is helpful if you use status, but want users to see it as ‘Phase,’ for example. Go to your column you want to change the header for > Advanced Options > enter what you want the column to read as instead of the native field name:

But, did you know it’s just as easy to change the grouping name? This goes a long way in making cleaner reports. For example, instead of a repetitive and sometimes long grouping name based on the field you’re using, like this:

Go to Groupings > text mode > edit the namekey line:

From this: group.0.namekey=view.relatedcolumn

To this: group.0.name=Project

Which gets you this:

If it’s obvious to users it’s grouped by project, remove the grouping name entirely to show only the result for each grouping, like this: group.0.name=leave this blank

I’m a big fan of clean groupings! 

[Madalyn_Destafney]

Tuesday Tech Bytes | Part II Tips & Tricks

Happy Tuesday! Last week (above), I shared some Bytes for Beginners above. Continuing the Tips & Tricks theme, here are three more helpful bytes. Let’s get into it!

1. Add a Calculated Field to Use Multi-Select Fields in Charts
You cannot group charts with multi-select custom field values (checkboxes, multi-select dropdowns), something I hadn’t realized when I first started getting into reporting. I was bummed until I learned you can create a simple calculated field referencing the multi-select field, living in the same custom form.

Say your multi-select field is called Deliverables Included. Add a calculated field to the form referencing that field (text format):
({DE:Deliverables Included})

This now becomes a groupable field to use in reports because the calculated field isn’t multi-select, it’s viewed as one unit:

NOTE: This is ideal if you don’t have a ton of possible answer combinations. Every answer combination is seen as a different grouping, so if you have email + social and email + web, those will show as two separate groupings in your report even though email is part of both.

2. Open a Proof Directly from a Proof Approval Report
We all love a pending proofs report. Make them more user friendly by including a column with the proof URL to open directly from the report, instead of the default Document Name column in a Proof Approval report, which takes the user to the details page (then the approver has to open the proof from there...annoying, right?).

Remove that extra click by using this column text mode:
displayname=Proof Link
textmode=true
shortview=true
valueexpression=CONCAT("https://[YOURDOMAIN]/document/",{documentVersion}.{document}.{ID},"/proof/",{documentVersion}.{proofID},"/view")
valueformat=HTML

Take it a step further by adding a column for the project name where the proof lives:
displayname=Project
link.valuefield=documentVersion:document:project:name
link.valueformat=HTML
textmode=true
valuefield=documentVersion:document:project:name
valueformat=HTML

3. Level Up your $$USER.ID Task Reports
Make task reports using $$USER.ID more helpful by adding in the filters below.

Remove Tasks User Has Marked ‘Done with My Part’:

The ability for users to complete their part on tasks assigned to multiple people is really handy. BUT, on default this doesn’t remove tasks they’ve marked as done with their part from task reports with $$USER.ID. A task shows as incomplete until all users on the task have marked their part done (or someone marks it done on behalf of everyone). Add this text mode to your filters to NOT show tasks they’ve marked their part done:
EXISTS:1:$$OBJCODE=ASSGN
EXISTS:1:assignedToID=$$USER.ID
EXISTS:1:status=DN
EXISTS:1:status_Mod=notin
EXISTS:1:taskID=FIELD:ID

Include Tasks Assigned to Team(s) They’re On:
Add Task >> Team ID = $$USER.teamIDs to capture tasks assigned to a team the user is on (if they don’t typically get reassigned to an individual) for a more comprehensive view instead of just $$USER.ID.

[Madalyn_Destafney]

Tuesday Tech Bytes | Part I Best Practices

I'm back with more bytes! This and next week's focus is on best practices. I have a handful of bytes for instance health below. Check back here next week for bytes around user experience. Feel free to comment with more juicy bytes of your own, this topic is endless!

1. Deactivating Beyond Just the User...
Keeping up with user deactivation is obvious - hello, you don't want precious (paid) licenses used up by deactivated users! Do your instance a favor by going beyond just deactivating the user. Make yourself a dashboard to help identify other objects that may need deactivation or updating based on the deactivated user, like:
- Open projects with deactivated project owners
- Open tasks/issues assigned to deactivated users
- Pending proofs in Current projects with deactivated approvers
- Active templates owned by deactivated users or shared only with the deactivated user (either deactivate the template or share with others accordingly)
- Timesheet/issue/task/project approvals pending from deactivated users
- Active template tasks assigned to deactivated users
Do you utilize group admins? Have them add this to their group maintenance.

2. Leverage Wildcards to Reduce Reporting Bloat
We all know the value of using $$USER.ID (not every user needs their own task report, pending proof report, etc.). $$USER.ID isn't the only option! Don't forget about the several other helpful wildcard options. Check them out here, they may prompt some ideas.

3. Avoid Open Text Custom Form Fields
Not only can open text fields lead to human error, but they can also create a reporting nightmare. As much as possible, when you have a field with known answers, use checkbox/radio buttons/dropdown fields instead. Cost center, project type, request type, region, etc. For example, a user could answer that a project type is 'web page,' 'website page,' 'web,' etc. Set yourself up for clean reporting by providing the appropriate option(s) for users to select.

4. Unsharing Questionable Reports
You know those lingering reports you've been debating to delete - perhaps they're shared with active users but haven't had recent views. But you also don't want to try to pin down someone that can give you an answer if ok to delete (of if you do, sometimes all of a sudden users find it valuable when they haven't looked at it for a year). Since reports don't go to the recycle bin, an easy trial is to simply unshare the report(s) and track when you did so (perhaps add an unshare date to the report description for your reference) - if no one misses it after a timeframe you see fit, delete it!

[Lyndsy-Denk]

I love the unshare approach. It's a delicate way to test what is and isn't used in a system, especially if you're a new admin who has inherited an instance.

[Madalyn_Destafney]

Tuesday Tech Bytes | Part II Best Practices

Hello, Community! Continuing with best practices bytes, today’s Tuesday Tech Bytes focuses on user experience. A negative user experience results in poor adoption – and of course, low adoption means your org is not getting the most out of WorkFront it can. Then what’s the point, right? There are key sometimes-overlooked features in WF that when used to their potential, can really help drive adoption through a good user experience:

1. Layout Templates: I cannot stress the importance of layout templates enough, especially for new users. If users have a layout template with a ton of fields irrelevant to them, everything just becomes clutter and leads to confusion. When using layout templates, go beyond just setting the main menu and adding a dashboard to their homepage. Assess your lists (views/filters/groupings), custom terminology, all the fields shown in object overviews, etc. Remove anything irrelevant for the user – a clean layout is key. Learn about layout templates here.
2. Native Integrations: Utilize relevant, native integrations. Some of these are installed at a user level instead of an instance level. Be sure your users know what’s available, these are low-hanging fruit that can go a long way in a positive user experience. For example, does your org use Teams? Educate users about the native WF plugin for Teams – up to them if they don’t opt to use it, but you don’t know what you don’t know… If you missed the customer panel about native integrations with yours truly, catch up on it here!
3. Custom Views/Filters/Groupings: WorkFront comes with several default filters/views/groupings options for each object – don’t overlook the value of custom filters/views/groupings as well. Including custom form fields for users to see pertinent information as quickly as possible really helps users be nimble in WF. Learn more here.
4. Assess New WF Features: Just because something is new, doesn't make it meaningful. Not every new feature is suitable for every instance; don't roll something out just because it's available. As an admin, really assess each new feature to see if it adds value for the way your org uses WF. 

[Madalyn_Destafney]

Tuesday Tech Bytes | Part I Integrations

Happy Tech Tuesday!

Fusion has gained immense popularity over the past couple years, with its robust capabilities in connecting WorkFront to other systems. Fusion also comes with a (hefty) price tag, so don’t overlook tools that integrate with WorkFront at no cost like Adobe Creative Cloud, Jira, Box and more – check them all out here.

Not seeing an integration you need and you don’t have Fusion? Create custom integrations using WorkFront’s open API. Check out the API Explorer for available objects, how to use it, and more here.

A couple tips as you assess integrations:

• Keep your users’ use of the tool in mind. Just because something can integrate, doesn’t mean it’s valuable to your org/WF instance. Does having the  integration make for a smooth user experience? Does it help users be more efficient and productive? Keep the user experience top of mind.
• One size may not fit all. For example, only a certain group of you users may benefit from the Creative Cloud integrations. Perhaps only some users or a single team may benefit from the Jira integration, for example (I’ve implemented it for a web team within a marketing department that regularly worked with IT, who used Jira, and that team’s project manager needed a way to assign work to IT in Jira through WF). The more you understand how your users operate, the more value you can provide by recommending and training them on relevant integrations. They don't know what they don't know...

Did you miss the June 2023 event discussing native integrations (yours truly is on the panel!)? Check it out here.

Next week in Integrations bytes part II, I’ll be sharing my experience/tips for using the Jumpseat integration!

[Madalyn_Destafney · Accepted solution]

Tuesday Tech Bytes: Integrations Part II (JumpSeat)

Welcome to my final Tuesday Tech Byte!
I mentioned in last week's byte directly below that I’d be diving into JumpSeat today if you haven’t considered this for your instance yet. I used it with a previous org I was consulting with and I'm a big fan. 

JumpSeat is a license-based software that works with any web-based application for custom user guidance/education within the application you’re using it for. Last year, JumpSeat became a native integration option with WorkFront! It's hiding out under Setup > System.

Key Things to Note:

• You must have a JumpSeat account and user licenses – having a WF account alone doesn’t give you access to JumpSeat. Users won't need to log into JumpSeat AND WF, that’s what the integration handles. Once they’re in WF, and are a JumpSeat user, they will see the JumpSeat elements you've configured.
• It’s not an all-or-nothing integration. You can choose which WF users/groups see anything JumpSeat-related in your instance. There are some JumpSeat elements that all JumpSeat users see, like hotspots, and some that can be specific to WF users (guides, paths).
• You’ll have the ability to create your own custom content or purchase guides created by JumpSeat that you can tweak as needed, or a mix of both.
• Choose the functionality you want: Step-by-step guides allow users to click around in WF while they learn as they go with popups/guidance, paths can be assigned to people with multiple guides to be completed in a certain order (hello, new user onboarding!), hotspots let you point out and explain new features or UI updates, and the list goes on.
• There are some places in WF that require a little more finagling than I had expected, but it wasn't unmanageable. WF loves modal windows and that's where configuring things in JumpSeat can get tricky. Fair warning. 

Key Benefits:

• Less time for admins creating training content: Instead of the library of PDFs you may have for training that you constantly have to update, you can train users IN WorkFront as they use it in real time.
• Faster user adoption: Users learning a tool IN the tool instead of referencing separate documents has obvious upsides. Get the stats here.
• Robust reporting: You can track user engagement/activity with your guides, where drop-off occurs, growth, etc. Learn more here.

Learn about configuring the JumpSeat integration here.