How to get a Reviewer to see all Proofs on requests? I have a Reviewer person who is internal and there is no reason she shouldn't have complete access to a certain project but I can't quite figure out how to get it.

[JillAc]

• Our video department refuses to work with Projects, so each video is a Request with a Proof attached to it (and a custom form that details the request). If there is an ongoing project (ie produce an ABC video new version once per week) they keep the ABC Request open and add a new Proof to it every week for approval. One request may have 100 video proofs in it, for example.
• Gracie is a Review license, and has been an approver on all of 100 videos but she doesn't have access to see the list of Proofs, and also doesn't see the Request in her view unless she does a search on the video name, then it maybe comes up for her, maybe not.
• Some of the Proofs are archived because they are a few months old
• The owner of the Request Queue can see all the videos in the Documents tab, no problem. So can I (Admin view)
• How can Gracie see the list of all the videos in any request, at any time? What access do I need to give to her for this? Or is the real solution (which admittedly I haven't tried yet) to create a Proof Report Dahsboard for Gracie that shows the Proofs? I'm just baffled by people who don't have full licenses.

Thanks for any advice on how to go about this.

[skyehansen · Accepted solution]

Give Gracie view access to the project that all these requests are housed in. For all requests lodged after you give her access, you will notice she automatically gets view access to those, and therefore view access to any file uploaded to those requests.

For all past requests, it sounds like she may not have access to some of those. Bulk select all the requests currently in the project and click on the share button to give her view access to the requests (which will coincidentally allow her to see the files).

You seem to be using "files" and "proofs" interchangeably. I would probably give Gracie a dashboard with two reports: one that lists all the requests and the other that lists all the video files. Definitely, if you have recently watched Jason's Collections session at Leap, feel free to combine the two, and make a report that lists files in each request (see pg 61 of the 2020 session).

The only value to giving Gracie a proof report is if she needs specifics around the proofs (decisions made, when they were made, what's outstanding). Giving her a proof report so that she can see the files is a bit, I dunno, beside the point(?), and I feel a docu report would be better, but that's just me and goodness knows I love the fastest answer possible.

Lastly, log in as Gracie when you have a free moment. This will cut down on a lot of your bafflement about people who don't have full licenses. Have a great weekend!

[JillAc]

Wow thank you! The only thing I got right was to login as Gracie! Yes I’m interchanging files and proofs, oops. I’m mentally blocked when it comes to requests/issues. Something about the structure eludes me.

[skyehansen]

yeah, requests and issues is a tough one because they are the exact same object but have slightly different rules. People use the term interchangeably as well (like calling everything a request so they don't have to imply something is a problem)

So everywhere you look WF has treated them like one object but then when you access or publish a request queue suddenly you unlock extra functions. Either way I would err on the side of:

• if the "publish as a help request queue" checkbox is checked on your project, call it a request. This has the most structure tied to it because you can actually affect the permissions the requestor has.
• If the checkbox is not checked, you can call it whatever you want, but have fewer expectations on functionality. People use this to apply some structure to ANY project by restricting the kind of issues someone can submit. Requestors get manage access to anything they submit.
• Most people call it an issue when it's completely freeform with no automation or forms attached... this is basically the wild west.

Other than this, they are kept in the same place (requests tab in a project) and structurally are similar (smallest object, no sub tasks, made for ad hoc, unplanned work).

[JillAc]

To follow up on this. THANK YOU SKYE for taking the time to write this out. For me, the key was “Sharing” which I don’t do often and never occurs to me! Turns out that Gracie, since she’s not licensed, is not part of the Default Group that I gave access to the Video Request project. Once I shared it with her, it all showed up. I made the Dashboard for her for easy access and the only problem is that there are 400 requests in that project and only the first 200 show up which are Closed and I can’t get New/In Progress to show on top which are the current/active requests that she is most like to want, but she might want to browse through the completed ones hunting for a video she can use. Any idea how to re-order these, or are you going to advise me to break the report into 2 parts (Active & Closed) and put them on the dashboard that way?

[skyehansen]

Hooray, I'm glad poor Gracie can now see everything. In your request report, if one of the columns is entry date, she probably would just as soon you sort by that (in descending order) so that all the fresh ones pop on top. Just click on that column when you are editing the report, and select the Sort By checkbox.

My work style is different from other people, but if I were Gracie I would prefer 2 reports: one for new/in progress and one for complete. This way they can always be separated from each other. Other people prefer them co-mingled and still others prefer a report prompt where they get to pick what they want from day to day. There is no right answer, but Gracie will know what she likes best and hopefully let you know.

[JillAc]

Ok poor Gracie just received 1000 emails when I shared all the documents and proofs with her. Oops. But now she has the world at her fingertips and our social media videos will be vastly improved. üòä