Lag time between updating medical form dates and appearance on RSVP reports

A previous user had reported this, but the thread is closed.

A committee member updated several medical form dates this morning, but the updates are not showing in the RSVP report for an upcoming event.

It has been five or six hours since the updates went in.

One example is a Scout with BSA ID 134470493. I checked his Scoutbook Plus Youth Profile, and his medical form date shows as 4/29/2024. However, on the RSVP report for a trip departing in a week, his date still shows as 4/20/2023.

Thanks in advance for any help you can give!

@ScouterRob - that is interesting as I updated my health report date and it was instantly in the RSVP report from that calendar event


I confirmed Scout mentioned above had the new date in his profile.

So just went in, and changed the dates, and changed them back, and it showed up automatically also.

Could this be tied to a user?

Committee member reports she used the mass entry feature for the updates. Might this be causing some disconnect?

@ScouterRob - that coulc be as i do nkt recall that a plain committee member had those rights.

Ok, peeling the onion back more…

She is a Key 3 Delegate in Functional Positions. And has been for a long time. She has this functional role for exactly this purpose of managing all unit medical records.

In SB, we gave her Unit Admin permissions also.

She has made hundreds of updates over her years in this role.

@ScouterRob - that makes sense so being able to do that is within those functional roles. Odd though it had not taken. But a double check is always good. I have found that sometimes an additional click on the save will refresh that update. The cache thing is in play for these updates.

Not sure I understand that…

The updates did populate into the Scoutbook Plus (aka Internet Advancement) profiles. But those updates do not get pulled and presented in the RSVP report.

I’ll have another look shortly to see if this corrected overnight.

Happy Fathers Day to all!

@ScouterRob - Happy Fathers Day… What i meant was that while the data was present in IA, the report had not refreshed its data pull. It may have cached the prior data.

Ok, understood.

Which platform is caching that data? IA or my browser?

My gut says IA.

Unfortunately, IA caches things locally, so kinda both. Usually forcing a browser refresh forces the updated data to be pulled. However, it sounded like you already tried a forced browser refresh, and it didn’t work? Or did I misunderstand one of the earlier posts?


I pulled the report, then cleared my cache, then pulled a new report, and it all updated.

Do we really pull a report from a database (of record) that uses outdated data from a user’s own machine?

We have to be better than that.

Please tell me you see the inherent flaw in the way this works?

And please tell me this is one that should be corrected :stuck_out_tongue_winking_eye:


I was curious about that myself, to be honest, but as a unit volunteer, I obviously don’t have any insight into what’s going on in the code. I’ve just seen similar sorts of behavior with my own unit, and figured it might be the problem here (or at least one thing that could be ruled out).

Strictly speculating here, I wonder if what’s actually cached is a portion of the database and an age cookie (or the like). If the cookie says the locally cached dataset is “too old”, the system serves fresh data from the SB servers (taking more time to load, particularly for larger datasets). If not, it assumes the data is “fresh enough” and generates the report based on the local cached data.

ETA: I could see theoretically adding to the cached data in chunks with newer data for the new chunks getting downloaded and cached locally, reducing the total amount of data being transferred at any given time. Then, the “old but still nominally fresh” data is used – together with the recently downloaded “new chunk” – to assemble the requested report locally. I can see that as a method to minimize continuing demands on the server for repeated report/data requests in a short timeframe.

Thanks for the read.

If I understand, we use a static caching regime for these reports?

Again this does not make sense for leaders trying to pull real-time (dynamic) data.

Each time I pull a new report, I should see the actual data in the database of record.

Would you agree?

@ScouterRob - there is a cost related to real-time dynamic data the reflects against performance, processing and bandwidth. I know for where I work there are baselines for customer hardware and bandwidth required for real-time data. If you want to report and display dynamic real-time data then anticipate delay in presenting your results. The best way to think if it is that real-time market data and live streaming news will be effected by the pipeline and you local device.

Got it, thanks.

And this makes sense for certain data elements that do not change (much)… names, DOBs, parent info, addresses, etc.

Certain data sets get updated much more… For example, with a unit our size (50+ Scouts, plus their parents and leaders), the sets of medical info and swim classification data see daily changes, especially in advance of summer…

How do we request that these data chunks be dynamic?

@ScouterRob - I would gather that this is a report you are running in high frequency ? The only course I can think of for requesting a web design change is through the local council to send that through to national

We have asked the developers to look into this. Reports should not be using locally cached data.


I do not expect any local council support. Our tech saavy isn’t very saavy, if you know what I mean.

We run the reports in the lead up to outings…

In the current case, we depart in a week for a week-long beach outing. So, we need Part C’s, which requires a little more lead time for parents to arrange.

As the leader, I run an RSVP report starting about two months out. I send this to our medicals person, who starts working with delinquents. And I then run the report about weekly to monitor progress… (so the caching mechanism explains why I did not notice much proress.)

This past week, I raised concern over outdated medicals. The committee member responded she had made updates. But, when she ran her own report, she saw the uodates she made had not registered. (I do not know the forensics on her report draw frequency.)

Clearing and re-running gives us the fresh look, but your average user should not have to do this.

If anything, we as an organization should be making it easier for leaders to work these administrative details, instead of having them learn to implement work arounds to exercise due diligence when taking other people’s kids into the woods.

Preaching to the choir, I’m sure.

Case in point, you are all volunteers who give your time to help leaders navigate the sometimes-poor IT tools we have.

Thank you.

Meanwhile, the C-suite in Irving are taking home incomes that put them in the top 5% of Americans.

And they wonder why people aren’t joining.

Yours in Scouting!