Report to find folder in document tab

[AC-again]

I am trying to run a report that will tell me if a specific type of folder we add via template is present in a project. We started adding an "Archive" folder to our projects but prior to us editing our template to take care of this, we had older projects that do not have the folder. I want to be able to find these projects to update them with the folder. 

[skyehansen · Accepted solution]

You would need to use an exists statement for this and be reasonably familiar with navigating the API explorer for code names (using the reference and collection tabs). You can read up on exists filters here:

https://experienceleague.adobe.com/docs/workfront/using/reporting/reports/text-mode/create-complex-t...

The API explorer is here:

https://developer.adobe.com/workfront/api-explorer/

Taking the following as a sample of code you would add to a project report:

EXISTS:a:$$OBJCODE=DOCFDR
EXISTS:a:projectID=FIELD:ID
EXISTS:a:$$EXISTSMOD=NOTEXISTS
EXISTS:a:name=Archive
EXISTS:a:name_Mod=cicontains

This code is saying

1. For any folder...

2. ...where the folder's project ID is the same as the ID on your project report (i.e. the project's ID)...

 3. ...there does not exist...

4. and 5. ...folders where the name of the folder contains the word Archive

In plain english, your list of projects will contain only folders without the word "archive" in the name.

I used the api explorer to look up the name for the folder object, as well as the fields I would need from that object (projectID and name). It was helpful to see on the folder object that I would be able to reference the project (project ID), but I am mindful that if you added the folder to a task on the template, the code above might need to be amended to look for a task id which would be an interesting challenge in a project report. 

[Madalyn_Destafney]

Hi Skye! Can you refresh me on why the 'a:' is needed in each line? I wish I was better at EXISTS and AND text mode. What is the difference between what you have and below - it's that if you add another OR set filter they'd be 'b:'?

EXISTS:$$OBJCODE=DOCFDR
EXISTS:projectID=FIELD:ID
EXISTS:$$EXISTSMOD=NOTEXISTS
EXISTS:name=Archive
EXISTS:name_Mod=cicontains

[skyehansen]

I think probably the key difference between the two code blocks would be that one of them works and the other one produces an error.

However, to paraphrase what you're saying: yes -- if you had multiple exists statements side by side, workfront would be able to tell that they were two separate statements. For example, we have a report called "Empty Projects" -- projects with no tasks, issues, and documents. There would be at least 3 filters we would need to employ for this type of report and we want all three filters active at the same time:

* tasks do not exist, plus

* issues do not exist, plus

* documents do not exist

Each one of these filters would be a separate exists filter. Without the :a, :b, :c, Workfront wouldn't be able to "keep the filters separate but together". (wouldn't be able to recognize that we have three filters and we need the intersect of all three)

On the other hand, if you wanted the report to pull up any project with EITHER no tasks, no issues OR no documents, you would be able to keep each exists statement separate by using the OR:1: and OR:2: syntax, and use :a on all three filters if you want (I don't have an opinion on that kind of formatting, but I imagine it's good practice to use different lettering just in case you need to merge the filter sets at a later point).