Create EXISTS filters for complex reporting

EXISTS filters are advanced, text mode filters, which allow us to work around the 2 table/field jump limitation in a standard report builder. Or, they can be used to identify objects in the system that lack a specific relationship condition via NOTEXISTS.

In this video you will learn how to create an EXISTS filter to see “Proof approvals on Current projects” in a proof approvals report.

For a more in-depth walkthrough on how EXISTS function, please see Create complex Text Mode filters using EXISTS statements documentation.

Transcript

Today I’m going to explain to you what an exist filter is, what it can do for you, and how to build one from scratch. We’re going to use the proof approval report. And I’m trying to make a proof approval report that is being filtered by projects that are in the status of current. So these are proof approvals that are on projects that are current.

Seems simple enough, right? But we’re about to run into a few issues. So let me start from scratch here.

Let’s say that I wanted to build this filter in the UI. Unfortunately the proof approval report doesn’t really allow us to go very far. A lot of people filter by approvers, but when we’re trying to actually find it on an object, we run into a lot of problems. The highest level object that we can even go to is the document version. And from there we can get document ID. Not the most helpful if we’re trying to get to projects in the status of current.

So if I switch to text mode, usually we can go a little bit further, but in this case this is actually about as far as we can go. We can go up to the document version table, so one jump, and then we can get a field on that table. If there was no jump limitation, this is the way that it would look. I would go document version, then I would jump up to the document table, then I would go to the project table, then I would go to the status field on the project table, equals current. And to make the text mode work, I would just grab all of this here, and I forgot the S, and I would put mod equals in. So this is an equals filter, so as long as the status is current, everything should work. There is no syntax error, and if I hit save and close, we run into an error. And the reason for this error is because of the table jumps. As I mentioned before, we could go one table jump and then get a field on that, but we can’t do a table jump, table jump, table jump, and then field.

So how do we bridge that gap? How do we get all the way up to the project status equals current? Because we can go up one table jump and then grab a field on that, looking at this, which table should we be on if we want to filter by just project status equals current? It would be the document table. So if we could somehow get to the document table, we could make this all work.

Now, that could be done in a document report. In a document report, we would be able to just set a filter, project status equals current. We could even use the UI. We wouldn’t need text mode, and everything would be great.

We’re going to do the same thing here by using exists. We are going to link prove approvals with documents so that we can go from the document table and just do this simple filter here. So let me show you what that looks like.

OK, so I put all of this with exists colon one before it and having those all together and with the same number or letter. I could do a I could do B I could do five right as long as they’re all the same. Then they’re going to be grouped together as one single exists exists filter.

Now, what I need to do is I need to get to the documents table. And so that’s as simple as putting in the object code equals docu. So this row is finished. Now, the object code. So that is called as the linking object or the destination object. Depends on how far we have to go for the exists filter. And oftentimes the linking object and this in this case, it is linking because we are using it to link us between project and proof approval. We have to go up to the document and then we can go from document to project status equals current.

The linking object code or this object code we can find in the API Explorer by going to the table. This is the document table and getting this code right here. So everything we see on the far right, that is the code that we use for object code.

Now, to link proof approvals to document so that we are on the document table and then we can finish this filter. We do have to have a formula here. It is really simple. It is an equal sign. And on the left hand side, we need some kind of ID, some some field on the documents table. On the right hand side, we need some kind of field or an ID. ID’s are the best because if they match perfectly, we know we have connected the objects. So an ID field on the proof approval will be on the right side. So this is what this will look like on the left hand side. We are going to do documents.

So if we are thinking between proof approval and documents. So let me show you what that looks like. If we start at proof approval. OK, so this is a table. These are the fields on that table. This reference allows us to go up to a different additional tables through to like a key right through through ID. So if we have document version ID on the proof approval, it allows us to connect to the document version table.

You know, to the ID on that document version table. And then same thing here. We have document ID allows us to connect or reference document and it takes us to the document table.

So we want to find a field on the document table that would also be referenceable on the proof approval table. And right here, current version ID is the one that I have used successfully and I really like. So if we do current version ID equals, so we’re done with the left side. Now we want this to equal something on the proof approval side. Now we always put field. Field is a stand in for whatever object we’re currently on. So we’re in a proof approval report. Field equals proof approval. That is the table that we’re on. And what field on the proof approval would equal the current version ID? Proof approval. We could go up to document version and get the ID or we could just grab it here. Document version ID. So as long as the proof approval is on a document version and that ID matches the current version of this document, we can then go from that document and finish that filter and do. This is just the filter part. This is all the linking stuff that gets us to a point where we can just filter on project status.

Okay, I’m going to go ahead and save this and we’re just going to make sure it works. I have four proof approvals. We have proof creator, proof owner, right. Inversions. If we click on this document. Okay. Took us to the document name. We can click on project. We see it’s in a status of current. If we change that to something else. Go back. We would expect that to be gone because now there we go. So it looks like there were actually two fields that were on the two proof approvals that were on that project. That is no longer in current. And so they fell off.

EXISTS Filter Examples

Project Report EXISTS

This uses the task as the linking object, by comparing the projectID found at the task level and matching it to the project level ID field. This allows us to then compare the assignment users on the task to a $$USER.ID wildcard. This results in returning only projects where the viewing user is assigned to a
task, regardless if they are the primary assignee or not.

EXISTS:A:$$OBJCODE=TASK
EXISTS:A:assignmentsUsersMM:ID=$$USER.ID
EXISTS:A:assignmentsUsersMM:ID_Mod=in
EXISTS:A:projectID=FIELD:ID

This uses the issue (optask) as the linking object, by also comparing the projectID found at the issue (optask) level and matching that to the project level ID field. This then checks to see if any of those issues (optasks) have an entry date within the span specified. In this case it would return any project that has
not had an issue (optask) logged in a rolling past 30 days, due to the NOTEXISTS.

EXISTS:A:$$EXISTSMOD=NOTEXISTS
EXISTS:A:$$OBJCODE=OPTASK
EXISTS:A:entryDate=$$TODAY
EXISTS:A:entryDate_Mod=between
EXISTS:A:entryDate_Range=$$TODAY-30d
EXISTS:A:projectID=FIELD:ID

Template Report EXISTS

This filter will show all templates that have not been used to either create a project or have been attached to a project in the past year. One caveat is that in order to figure out whether or not a template was used as an attachment, it is dependent on that template having tasks in it.

EXISTS:A:$$EXISTSMOD=NOTEXISTS
EXISTS:A:$$OBJCODE=TASK
EXISTS:A:entryDate=$$TODAY-1y
EXISTS:A:entryDate_Mod=gte
EXISTS:A:templateTask:templateID=FIELD:ID
EXISTS:B:$$EXISTSMOD=NOTEXISTS
EXISTS:B:$$OBJCODE=PROJ
EXISTS:B:entryDate=$$TODAY-1y
EXISTS:B:entryDate_Mod=gte
EXISTS:B:templateID=FIELD:ID

Task Report EXISTS

This uses the User table as the linking object, connecting by the assignments taskID and the tasks ID. This then checks the teams collection of IDs to the user Team IDs, returning the task if any of the assignees are on the same team as the viewing user.

EXISTS:1:$$OBJCODE=USER
EXISTS:1:teams:ID=$$USER.teamIDs
EXISTS:1:userAssignments:taskID=FIELD:ID

User Report EXISTS

This will return all users who have not posted an update in the past 3 weeks. This uses the note object to bridge the gap and compares the ownerID to a users ID. Then returns that user if no notes owned by them have an entry date greater than 3 weeks ago.

EXISTS:A:$$OBJCODE=NOTE
EXISTS:A:$$EXISTSMOD=NOTEXISTS
EXISTS:A:ownerID=FIELD:ID
EXISTS:A:entryDate=$$TODAY-3w
EXISTS:A:entryDate_Mod=gt

This will return all users who have not logged hours in the last week. This uses an extremely similar method to the example above, but instead uses the hour owner info and hour entry date to base what users it returns.

EXISTS:A:$$EXISTSMOD=NOTEXISTS
EXISTS:A:$$OBJCODE=HOUR
EXISTS:A:entryDate=$$TODAY-1w
EXISTS:A:entryDate_Mod=gte
EXISTS:A:ownerID=FIELD:ID

In a user report, show a list of users that matches a project’s People’s tab.

EXISTS:1:$$OBJCODE=PRTU
EXISTS:1:projectID=<projectID>
EXISTS:1:userID=FIELD:ID

Category (Custom Form) Report EXISTS

This text will give you a list of all project forms that have not been used on a project at all, ever. This should be used in conjunction with specifying the object type of the form we are focused on. So in this case the focus is PROJ, so we should include the callouts in the objTypes lines. This could be used
for other object types by changing the object code related parts. This checks the collection of projects attached forms, to the listed forms and returns if there is no match.

EXISTS:A:$$OBJCODE=PROJ
EXISTS:A:$$EXISTSMOD=NOTEXISTS
EXISTS:A:objectCategories:categoryID=FIELD:ID
objTypes=PROJ
objTypes_Mod=in

Parameter (Custom Field) Report EXISTS

This returns any custom field that is not currently attached to a custom form in the system.

EXISTS:A:$$EXISTSMOD=NOTEXISTS
EXISTS:A:$$OBJCODE=CTGYPA
EXISTS:A:parameterID=FIELD:ID

Report Report EXISTS

This will return any report using a specific value in its filters.

EXISTS:1:$$OBJCODE=UIFT
EXISTS:1:ID=FIELD:filterID
EXISTS:1:preference:value=<value here>
EXISTS:1:preference:value_Mod=cicontains

This will return any report that is attached to any dashboard.

EXISTS:A:$$OBJCODE=PRTBSC
EXISTS:A:internalSectionID=FIELD:ID
EXISTS:A:portalTab:ID_Mod=notblank

Proof Approval Report EXISTS

This would return proof approvals only on projects in a status of Current. This uses the Document object to bridge the gap from proof approval to project by checking the currentVersionID to the documentVersionID, from there we jump to the projects status.

EXISTS:1:$$OBJCODE=DOCU
EXISTS:1:currentVersionID=FIELD:documentVersionID
EXISTS:1:project:status=CUR
EXISTS:1:project:status_Mod=in
recommendation-more-help
c9fbcf61-6d19-481e-a9ab-f54a0ae0ee8a