[Event Follow-Up] Your dream Workfront report EXISTS! Two Approaches to Mastering EXISTS Statements | Adobe Higher Education
Skip to main content
CynthiaBoon
Adobe Employee
CynthiaBoonAdobe Employee
Adobe Employee
October 28, 2025

[Event Follow-Up] Your dream Workfront report EXISTS! Two Approaches to Mastering EXISTS Statements

  • October 28, 2025
  • 2 Antworten
  • 502 Ansichten

Ready to take your Workfront reports to the next level?  Watch how @skyehansen  & @nathanjo1 offered two perspectives on creating EXISTS statements that can make your reporting dreams come true. 

During this workshop, they shared technical know-how and practical applications to show us how to use EXISTS statements to build smarter reports. 

Did you miss the session? No worries! You'll find links to the workshop recording and slide decks with resources below: 

Don't forget to sign up for their Ask Me Anything session in December. 

And if you’re wondering about when to use EXISTS statements, we had some great analogies shared in the chat: 

  • Think of Workfront as a hierarchy of relationships. I like to think about it like the game "Six Degrees of Kevin Bacon." If the objects are not directly related, then you are "Jumping Tables" - for example, jumping from the Task object to the Portfolio object.
  • Nathan's phone number analogy is so great too, because, what if you need your cousin's phone number. In your phone, your cousin might have a specific name that means something special to you, but on your mom's phone, it is probably called something else. The trick is getting the right name. (And @moniqueevans added a very important part to this analogy.  This is especially important when that cousin has a government name you have NEVER heard in conversation. In this case, a good example is the Parameter object (or how we know and love them - Custom Field). 

We’re always adding new events to the calendar, so please check Events page on Experience League regularly so you don’t miss out! 

 

    2 Antworten

    kautuk_sahni
    Community Manager
    kautuk_sahniCommunity Manager
    Community Manager
    October 29, 2025

    @cynthiaboon Fantastic recap, workshop really clarified some of the trickier aspects of EXISTS statements.

    @skyehansen  & @NathanJo1, in your experience, when optimizing reports that already rely on multiple nested filters, how do you decide whether to introduce an EXISTS statement versus restructuring the report with calculated fields or custom parameters? Have you found any performance or maintenance trade-offs between those approaches?

    Kautuk Sahni
      skyehansen
      Community Advisor
      skyehansenCommunity Advisor
      October 29, 2025

      thanks for your question, Kautuk! I'm sure Nathan can speak more to this than I can but from my observations, having multiple exists filters in a single report can definitely degrade performance (cause the report to load slowly) -- so it can sometimes be a trade-off.

       

      In terms of supplementing with additional fields at strategic points, I only suggest these if they are easy to implement and provide additional return on investment by driving different types of frequently-accessed reporting. For an example of poor ROI: I would be hesitant to create this sort of extra infrastructure specifically to drive one report that was only being accessed by several people, 3 times a year. There's too much of a risk that these users might fail to adopt the report long term, leaving me with debris/clutter on the back end.

        NathanJo1
        Adobe Employee
        NathanJo1Adobe Employee
        Adobe Employee
        October 29, 2025

        I wanted to respond to a question asked by @tibormolnar during the presentation. They asked: "What would I choose as linking table if I wanted to create a Project report which filters on Tasks that exist/notexist in the project? (e.g. show me projects that have any tasks updated this week)"

        First, this is an example where you could just reference the collection of tasks instead of using an EXIST statement. Both options work here. For example, you can reference fields on the tasks collection by using this filter:

        tasks:entryDate=$$TODAYbw
        tasks:entryDate_Mod=between
        tasks:entryDate_Range=$$TODAYew

        So no, EXIST filters are not needed here. However, you can still use an EXIST filter to make this work, and it highlights how the linking line bridges the gap and allows you to build the filter off of the linking object. As you see below, we use the TASK object as our linking object, and we reference fields from the task object (which are on the task object, so no jumps needed).

        To build the linking line, we use FIELD as a standing for the report we are in (PROJECT) and so it is, essentially, task:projectID=project:ID with project being replaced by FIELD and task being assumed since it is our linking object. We then build the rest of the filter as if we are on the TASK object.

        EXISTS:A:$$OBJCODE=TASK
        EXISTS:A:projectID=FIELD:ID
        EXISTS:A:entryDate=$$TODAYbw
        EXISTS:A:entryDate_Mod=between
        EXISTS:A:entryDate_Range=$$TODAYew

         

        Let me know if you have any questions.

          skyehansen
          Community Advisor
          skyehansenCommunity Advisor
          October 30, 2025

          Yep, to add to this, as an interesting counterpoint -- as long as you're searching FOR something, you can get away with using a collection from the POV of looking for tasks in a project report.

          So projects that have tasks created this week -- easily done within a collections filter. But projects with NO tasks created this week -- this would take a NOTEXISTS filter, because the collections filter would simply pull in any project as long as any one of the tasks is not created this week...

            Allgemeine NutzungsbedingungenAccessibility statement

            Loading footer...