Activity Log Missing Scouts

I was running a simple report for an activity that had 5 scouts. 2 of them showed up on the report, all of them show up when I go to edit the activity. How does one even begin to diagnose this problem?

1 Like

@JeffreyCieslak If you could post the BSA member numbers of the Scouts and the date of the activity, we can take a look. (No names, please)

Activity date: April 21

In activity record: (1 adult, 5 scouts)

In report: (1 adult, 1 scout)

@JeffreyCieslak At least one of these Scouts are missing the “Date Joined Scouts BSA” date. The report uses this date to filter out Cub Scout activities.

Okay, somehow I noticed that on Monday before I ask this question, and I filled in start dates for at least two of my Scouts who weren’t showing up on reports. But now when I go back to their profiles, I see that those dates have been eliminated. So what is the procedure for putting in a start date that will stick? I also have many, many complaints about the interface for this system, it seems as though it was designed by somebody who liked to make things look nice but never had to actually use anything. That’s not a comment on anyone personally, that’s just the way it is. I’d really just like to make the reports work, I guess.

The Date Joined Scouts BSA field is directly under the scout’s name in their profile (available either directly in IA2 at or via the Edit Profile button from Scoutbook). Only certain people have the ability to edit profiles, however, since that information was moved to IA2. If you hover over the item, the pop-up says “Editing limited to admins and connected parent/guardians” Check the position that’s selected for you when you’re editing in IA2 under the fleur de lis in the upper right corner.

It saved just fine for me (as a Key 3 Delegate). What’s your registered role in the unit, and do you hold any functional roles (e.g. Key 3 Delegate assigned at my.scouting) or Scoutbook roles (e.g. Unit Admin)? I think there have been cases where having too many roles with overlapping permissions (e.g. Scoutmaster and Key 3 Delegate and Scoutbook Unit Admin) when one position already grants all of the needed access caused issues.

@JeffreyCieslak After adding the “Date Joined Scouts BSA” date, are these Scouts still missing from your report?

If so, could you please provide the reference number at the bottom or your report (ref: PD- a bunch of numbers)?

Okay, this is some kind of bad problem.

I think the original activity is good now. But now I have another activity that I’ve check that is bad, and do I have to look at every activity to make sure the system is reporting it correctly, and then report that to you guys? That seems inefficient. And the fact that there were missing “start dates” on some of my scouts makes me think there are other DB consistency checks that I’m supposed to be doing?

The date of this activity is 5/27/2023
The scouts that are saved in the activity:
(+some adults)

If I run the reports with the “activity log” and “conservation log” flags only, these scouts appear:
ref: PD-20230613180045-817110-238748

If I add the “current members only” flag, only these appear:
ref: PD-20230613175952-285893-572912

@JeffreyCieslak start dates are a manual entry as some councils take months to process applications

1 Like

Well, that seems to be a pretty big problem if things depend on that date. How is it that it is not populated with the date that the record is added to a unit’s roster, at a minimum? A null value is clearly bad, and if we aren’t going to burden councils with adding it when the record is updated, there really ought to be some default value.

I still have the pending question about why the report changes when I change the “current member” flag.

Which roster? The official roster at my.scouting is only updated when the application is processed and completed. The roster in Scoutbook is considered unofficial, and has historically permitted unit admins to add youth “early” in order to circumvent the sometimes long delay for application processing. However, there are pitfalls with doing that if there are any mismatches between what’s entered there and what’s eventually entered by the registrar based on the application can result in duplicate accounts being created.

If the date is set to when added to the Scoutbook roster, does adding them to the my.scouting (official) roster reset that date? What about Scouts who transfer (i.e. their Date Joined Scouts BSA doesn’t match with the date added to the official roster)? Scouts who have a break in membership (e.g. leave and return)? The various cases can get pretty complex, making the logic similarly complex.

It’s actually (historically) been easier to identify null values – since it can be flagged in a Roster Builder report (snapshot below) or the OA Eligibility Report – than to identify wrong values (since the user has to scrutinize the value and compare it to some other record). It seems like leaving it empty is both the minimum chance of generating a coding error and the easiest thing to identify as needing action to “correct”.

A system that leaves all error checking to the user is not useful.

I shouldn’t have to run a report to for me to know that my reports are going to be incorrect.

This is why careful database design and implementation is difficult, and important. You can’t just throw tables together and think everything is going to work out.

(If the fact that there are two rosters at all doesn’t send a cold shiver down your spine, we probably can’t even be having this part of the discussion.)

THIS STILL DOESN’T ANSWER THE PROBLEM WITH THE “Current members only” FLAG. I’m not here to complain about the entire system (though that seems to be some significant portion of the problem), I really just want to know a) how to make my reports work, and b) how to tell that they will be valid in the future.

The other problem is the official roster starts everyone on the first of the month. If a Cub Scout camps early in the.month then joins a troop, if the registration date were used as the Date Joined Scouts BSA, the camping night would be credited to the wrong program for reports such as the OA Eligibility report.

I disagree. Incorrect data that is almost right is very hard to notice. Leaving it completely blank makes it much more obvious.


If we’re going to require the date to be there for some reports to work, and we’re not going to require entry of the correct date, then we probably should come up with an “obvious” not-null date. 01/01/1901, for instance. 02/08/1910 (founding date) might be a good one, too.

“Your reports will fail silently because you, dear unsophisticated user, must do sanity checks on unknown records in at least one of two separate databases” is no way to run a railroad.

I’m done discussing the database inanity. I would like my reports to work in a sane way. How would one go about that?


This isn’t going to happen. It would require every report that needs the date joined Scouts BSA to be updated to ignore the obviously wrong date. There would be no difference in the report output with an obviously wrong date vs. no date. The whole point of the behavior today is to alert the user that Scoutbook does not have sufficient data to properly report. We have already explained why we can’t enter the “correct” date joined date. This is a one time update that units need to make to the records of their Scouts and should just become standard operating procedure when a new Scout joins.

1 Like

Enter the dates joined Scouts BSA each time a Scout joins. Period.


@Matt.Johnson - that is exactly what i have done… and once entered you are good.


AGAIN, my issue: This is my (second, as of yesterday) question in this thread, but the behavior today is slightly different:
Activity on 5/27/2023. (It would be nice if, somewhere in the activity, there were some kind of ID associated with it so that it can be easily identified by me, and communicated to you. But whatever.)

If I run the reports with the “activity log” and “conservation log” flags only, these scouts appear (THIS IS CORRECT, 4 scouts):
135275129 (join date: 03/02/2020)
14652783 (10/01/2022)
135938927 (05/15/2023)
135184709 (03/28/2022) (This is new today, wasn’t showing here yesterday)
ref: PD-20230614135939-114914-231411

If I add the “current members only” flag, only these appear (THIS IS INCORRECT, 2 scouts):
ref: PD-20230614140925-960334-247410

So, I’m surmising that in addition to the existing, “valid” start dates, there is another flag that someone is supposed to know to check when they run reports? Or what?

I don’t think there is some other flag. The friendly SUAC will help determine if it is a real bug.

The add in used to have a “data checker” feature they would flag missing things like district. Was this feature removed? Scouts BSA join date missing would be / would have been a good addition @GaryFeutz .