Tuesday Tech Bytes

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.

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!

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. 

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!