Skip to main content
Solved

Reports based on saved searches do not reliably or immediately update?

  • April 6, 2026
  • 9 replies
  • 102 views
Rumi Matsuyama
Forum|alt.badge.img+1

I have found that reports based on saved searches are not immediately updating themselves and get stuck with results from a prior report run even though the searches themselves return accurate updated results and I don’t know why this is happening.  

Happened most recently today: 

  • I createe a custom report template based on a saved search several days ago
  • It ran perfectly and the results were correct.  The saved search produced 3 hits and the report had 3 rows
  • My saved search was based on an staff assignments. 
  • I did a bulk upload today that applied staff assignments to additional records
  • I reran the report and expect there to be 79 rows. There’s the same 3 rows as before
  • I ran the saved search. There are 79 contacts as expected 
  • So my report is stuck with the old results from over a week ago (i.e. the result it had when I first and last ran the report). 
  • If there’s a built in lag it seems significant (in this particular case, the upload that updated my saved search result was over an hour ago?)
  • It’s not caching on my end (I re-accessed the report on an entirely different browser and got the same results) 
  • I can force feed reports like this to update themselves by editing the search as follows: deselecting my original saved search, reselecting my (same) saved search, rerunning the report, resaving the report but that seems ridiculous to have to do that??? (and especially inconvenient if others need to use and are relying on the same report.)
  • Usually when this happens and I notice it I can’t wait to see how long it will take to accurately refresh itself (or if it will EVER do so).  With my current project I need to set up dozens of saved searches for  numerous other admins, so this problem is onerous and distressing to me.   
  • It’s not a result of date based filtering. The only filters on this report are Contact Records (where I have indicated the saved search) and Date Contact Created (which I have not touched/am not using)
  • As a test, I plan to recheck one of my  stuck reports tomorrow just to see if it at least refreshes itself overnight.

It’s irritating to have to babysit my reports like this and not to be able to rely on the results (nor confidently tell my clients to rely on these reports). 

Have others noticed this issue?  I will log a bug ticket tomorrow if the search still refuses to refresh itself overnight (maybe even if it does eventually refresh itself actually) but mostly wondered if others have ever noticed this behavior. 
 

Best answer by Andrew Varnerin

Hi all,

I’m a former EA/NGP VAN Developer for reporting features, and currently consulting for Bonterra - wanted to chime in quickly!

I’m sorry for the confusion here, as I believe these issues stem from the way we cache search results for reports, deep inside the codebase. Saved searches tend to grow in runtime, and with usage patterns of reports - rapidly adding filters/columns, sorting, and interactively exploring the data - it put far too great a strain on the system to run them on-they-fly. As a result, we have in place a one-clock-hour caching time for the results of a given search used in reporting:

  1. If a report is run with Search A at 1:01PM, the search results are cached until 2:00pm
    1. If a different report is run that references that search within that timespan, it will use that same cached search results - it won’t extend the cache expiration
    2. Running at 2:00pm will then fetch fresh data (and cache for a full hour)
  2. If a report is run with Search B at 1:59PM, the search results will be cached just for that minute
  3. In both cases, the report data will be up-to-date after accounting for the difference in universe - the contributions report will still pull fresh contributions as long as the contact record was included in the search results at the time it was cached.
  4. In both cases, other usages of the search - running it from My Folders, using as an audience for Targeted Email - would still run “live”, regardless of caching within reports

I think the hourly caching/expiration would line up with meeting schedules and contribute to the confusion. I took a quick look and I think the Restore Default Filters thread is a red herring based on the descriptions here - but would definitely encourage following up on your bug ticket if it is still behaving oddly with this new knowledge!

Unfortunately, this isn’t something that can be changed at the moment, but we’re investigating broader reporting changes this year and I’ll make sure we revisit this part of the experience. I’ll keep an eye out for any easy ways to alleviate the pain too in the interim (like exposing the “fresh as of...” in the UI).

As a workaround, using save-as to save the search as a new search (and therefore new ID in the system) would force a fresh run for the new search - just not the delight we’d like it to be, and would itself then be subject to caching.

 

 

Best,
-Andrew Varnerin

Rumi M

9 replies

rachel moody
Forum|alt.badge.img+3
  • rachel moody
  • Community Manager
  • April 13, 2026

Hi Rumi! Were you able to get this resolved? It does seem like a bug that needs a support ticket, but let me know if you need help reaching out to support!

Rachel at Bonterra
Rumi Matsuyama
Forum|alt.badge.img+1
  • Rumi Matsuyama
  • Author
  • Active Advisor
  • April 14, 2026

no, ​@rachel moody I’m still seeing it.  In fact, my client complained yesterday that a report update that they were demoing at a training (where applying an activist code to a record should have triggered that record appearing in a report) didn’t happen because of this lag (i.e. the activist code application did add it to the saved search result for that report, but the report was still showing the rows from the original search results before the activist code was applied). 

This is not specific to any clients but something I’ve seen in different report manager reports across different clients.  if there’s a lag, it needs to be clear that this lag exists and to check back in X minutes or hours for the updated results.  Otherwise it’s not merely inconvenient (or in my client’s case, perhaps embarrassing in a public setting) but could really be problematic if a client shares reporting results it believes to be up to the minute when that’s not the case. This again is a problem that I’ve seen when a report is using a dynamic saved search and the report still displays the search results from an earlier time the report was run instead of refreshing, and there doesn’t appear to be a way to force refresh the saved search within the report itself, even though the saved search results when run outside of the report produce the correct updated results. 

I’ll log a bug ticket in any case.

Rumi M
Sally Heaven
Forum|alt.badge.img+2
  • Sally Heaven
  • Active Advisor
  • April 28, 2026

​@Rumi Matsuyama I am not sure if the problem you’re describing is the same as what I just discovered but I’m putting it here in case they’re linked. 

My situation was that I created a Saved Report Template and then scheduled daily delivery. I noticed over time that a date filter I added kept getting dropped from the scheduled report, so I reported this to support. 

After some testing, I noticed that the reason the date filter was getting dropped is because I would sometimes go to the Saved Report, run it, and then delete the date filter so I could see full results. I did not click Save because I was just quickly checking some stuff. However, Report Manager apparently keeps the last run version of a saved template, even if you didn’t actually click Save. Support says this is expected behavior. 

I don’t think it’s expected behavior. I’m not sure if this relates to your situation, but FYI. I’ll also paste my reply to Support here.

I'm surprised that this is expected behavior in EveryAction's Report Manager. My understanding of generally accepted UI is that something that is Saved should actually be immutable unless the admin proactively clicks the button called "Save" or "Save As." For example, when running a Saved Search, I can change the parameters in the Create a List, but if I don't click "Save" or "Save As" then my changes do not stick. (And I don't want them to stick unless I actually click Save intentionally.)

What you describe is more similar to "Autosave" which is behavior that I expect to see in creative programs like Microsoft Word, Google Documents, or the Targeted Email Drag and Drop Editor. 

I looked through the help files on Reporting and could not find any description that this is expected behavior. At a minimum, I would recommend Bonterra adds this to the help files. If I missed it, then please let me know where it is. This is the closest article I could find: https://community.bonterratech.com/reporting-54/how-do-i-manage-export-and-take-actions-on-reports-282?tid=282&fid=54

At a maximum, I would recommend to the product managers that a Saved Report Template should not retain the last state the report was run in unless the admin proactively clicks Save. 

Raise HECK, a Bonterra partner and certified Super User
    Rumi Matsuyama
    Forum|alt.badge.img+1
    • Rumi Matsuyama
    • Author
    • Active Advisor
    • April 28, 2026

    ​@Sally Heaven  your description is a different issue, but the new report updates around this have been a bit confusing to me also at times, and obviously has led to some unintended results like this!

    If you “restore default filters” before you leave the report, does help (though I totally understand it might be hard to remember to do that every time?).  

     

    Rumi M
    Sally Heaven
    Forum|alt.badge.img+2
    • Sally Heaven
    • Active Advisor
    • May 5, 2026

    Gotcha ​@Rumi Matsuyama! I just think that generally accepted user experience and expectations for software is that a framework like a report with filters should require a save as for a filter change to persist. This is one of those things where the EveryAction experience is different so admins will need to learn this quirk of EveryAction. I don’t think that’s ideal so I provided that feedback to EA support in hopes that it reaches the product management team. 

    Did you get a response to your bug ticket?

    Raise HECK, a Bonterra partner and certified Super User
      Sally Heaven
      Forum|alt.badge.img+2
      • Sally Heaven
      • Active Advisor
      • May 5, 2026

      I just noticed something else weird, ​@Rumi Matsuyama, which is that I just edited one of my Saved Searches and clicked Save. Then I re-ran the saved search and my edit did not persist. I’m not sure if that’s related to your issue but I’m going to log a support case about this. 

      Raise HECK, a Bonterra partner and certified Super User
        Rumi Matsuyama
        Forum|alt.badge.img+1
        • Rumi Matsuyama
        • Author
        • Active Advisor
        • May 5, 2026

        ​@Sally Heaven  I totally agree that the notion of having to “restore default filters” rather than the prior workflow of it clearing your filter changes automatically if you didn’t save the changes seems to be having unintended results (even though the change itself seems very deliberate -- maybe others asked for this behavior?  but yes I am finding it super confusing too). 

        I hadn’t seen the issue you reported with saved searches and that seems concerning! 

        I did report the bug on a bug ticket and basically I think I need to try to record it happening in a loom the next time it happens.  The unfortunate thing is that it’s difficult to retroactively reproduce -- it doesn’t always happen and it eventually does refresh (so that if I report it, it’s unlikely support will be able to see the issue by the time they are able to answer the ticket).  It’s like that Michigan J Frog cartoon. 

         

        Rumi M
          Andrew Varnerin

          Hi all,

          I’m a former EA/NGP VAN Developer for reporting features, and currently consulting for Bonterra - wanted to chime in quickly!

          I’m sorry for the confusion here, as I believe these issues stem from the way we cache search results for reports, deep inside the codebase. Saved searches tend to grow in runtime, and with usage patterns of reports - rapidly adding filters/columns, sorting, and interactively exploring the data - it put far too great a strain on the system to run them on-they-fly. As a result, we have in place a one-clock-hour caching time for the results of a given search used in reporting:

          1. If a report is run with Search A at 1:01PM, the search results are cached until 2:00pm
            1. If a different report is run that references that search within that timespan, it will use that same cached search results - it won’t extend the cache expiration
            2. Running at 2:00pm will then fetch fresh data (and cache for a full hour)
          2. If a report is run with Search B at 1:59PM, the search results will be cached just for that minute
          3. In both cases, the report data will be up-to-date after accounting for the difference in universe - the contributions report will still pull fresh contributions as long as the contact record was included in the search results at the time it was cached.
          4. In both cases, other usages of the search - running it from My Folders, using as an audience for Targeted Email - would still run “live”, regardless of caching within reports

          I think the hourly caching/expiration would line up with meeting schedules and contribute to the confusion. I took a quick look and I think the Restore Default Filters thread is a red herring based on the descriptions here - but would definitely encourage following up on your bug ticket if it is still behaving oddly with this new knowledge!

          Unfortunately, this isn’t something that can be changed at the moment, but we’re investigating broader reporting changes this year and I’ll make sure we revisit this part of the experience. I’ll keep an eye out for any easy ways to alleviate the pain too in the interim (like exposing the “fresh as of...” in the UI).

          As a workaround, using save-as to save the search as a new search (and therefore new ID in the system) would force a fresh run for the new search - just not the delight we’d like it to be, and would itself then be subject to caching.

           

           

          Best,
          -Andrew Varnerin

          Andrew Varnerin
          Rumi Matsuyama
          Forum|alt.badge.img+1
          • Rumi Matsuyama
          • Author
          • Active Advisor
          • May 12, 2026

          ​@Andrew Varnerin Oh How I Miss YOU!!!

          I’m so glad to have an answer that makes sense now.

          I think if there’s caching, there’s caching but labeling it as such would make a big difference. “Fresh as of...” and an indication of when to check back would be better than it essentially silently failing on you IMHO

          Rumi

          Rumi M
            Terms & ConditionsAccessibility statement