How to approve pending activities

I have a list of boys that have pending service hours. How do I approve them? When I go to each youth individual log the hours are there.
Trying to figure this out, really liked it when it was all just in Scoutbook.

You need to be a Key 3 or Key 3 Delegate to approve the hours.

  • Open IA2 (scoutbook.scouting.org)
  • Select “Activities” from the menu bar on the left to get to your unit’s list of activities.
  • Find the activity you need to update.
  • Click on the pencil in the upper right corner.
  • Add the Scouts and Scouters by clicking on the “Add Person” button in the pop-up.
  • Add any other participants that aren’t Scouts or Scouters in your unit (so, other parents, siblings, etc.) at the bottom of the pop-up, where it says “Non-Registered Youth” and “Non-Registered Adults”.
  • Click on the green “Edit and Finish” button.

At this point, you should see the activity in the individual Scouts’ profiles.

How do we complain to the Scoutbook Advisory Council about this? As described here: https://help.scoutbook.com/knowledge-base/activitylogs/, the Troop Admins and Patrol Admins should have the ability to approve activities. Why was this functionality taken away in the move to IA2? Who was responsible for making that decision? ASMs are the people on the hikes, on the campouts, at the service projects, not the COR.

Our Committee Chair has enough to do, he does not need to spend time reconciling and approving 74 boys’ hiking hours. This needs to be changed back ASAP, otherwise, the approvals will most likely just become rubber stamps.

The physical handbook for Activity Logs says ‘Adult Signature’. Online it should not be limited to the Key 3 like Committee Chair or COR.

We are all volunteers. We have delegated ASM Patrol Admins for a reason, to keep everyone’s workload manageable.

Can you please provide the email addresses of who to complain to about taking away Patrol and Troop Admins’ ability to Approve Activities? Every troop in our council is struggling with this.

2 Likes

I appreciate your frustration, and it’s in the backlog to add more approvers to this. In the meanwhile, your troop has up to SIX adults that are permitted to approve activity logs in IA2:

  • Key 3 members
  • Key 3 delegates
  • Advancement Chair

Additionally, after processing one or two activities, it’ll be clear that it isn’t particularly longer or more difficult to enter activities in IA2 than it was in the old Scoutbook activity logs.

ASMs need to be able to approve these activities. Otherwise it’s far too difficult to get these approved, and that will hold up advancement.

1 Like

As @SteveCagigas noted, that functionality is in the backlog. At the moment, our unit has designated me (as an ASM) to be a Key 3 Delegate, and I screen the activities submitted, then cross-check with the relevant activity-leader adults when necessary in order to approve the time/nights/mileage. Our advancement chair also has similar access.

One thing that has made things marginally easier is creating unit events in advance, then assigning scouts (or allowing them to assign themselves in the Scouting app) to those unit events. That way, it’s just a matter of handling the special case scouts/adults (came late, left early, etc) in the Advanced tab at the bottom.

1 Like

This is not about the difficulty of approving. This is about who is knowledgeable about whether these activities are actually done. Our Advancement Chair, COR, and Committee Chair are not on hikes or campouts with us. Our SM is often deployed. We have 8 patrols of ~10 boys and have Patrol Admin ASMs for a reason. Even as a Key 3 delegate, I do not have first hand knowledge of boys’ activities outside my patrol. So, staring at 93 pending approvals, the only real option is blindly accept and approval them all.

Functionality should not be removed without an express timeline to get it back in. Removed functionality should take priority over anything else. When is it going to be implemented? What in the Backlog is taking Priority over removal of functionality and how do we get input to re-sort the backlog priorities? @SteveCagigas @CharleyHamilton

1 Like

We as users don’t have any direct input or insight into how or what BSA IT decides to prioritize what they’re doing. I’ve complained about that before and suggested a more open development priority/tracking system, thusfar unsuccessfully. Based on other posts by SUAC members, they can agitate for change and particular features, but at the end of the day, BSA IT makes their own decisions about what to do and when to do it. They don’t share that information out to the user base, nor, as I understand it, to the SUAC, until a feature is implemented.

Someone on another thread posted a link to an article which argued that timelines and published feature implementation lists are bad in software development. I think that’s escapist fantasy myself, since not having a target deadline to implement functionality (or even a specific list of functionality that’s being implemented) reads like a recipe for folks to take their business elsewhere. For me, as a structural engineer, that’s akin to saying that we’re going to provide a structural design that implements some subset of the functional requirements, we won’t say which ones, nor when the various requirements we do implement will be released. Also, we may remove functionality from time-to-time without a public timeline to get it replaced. Kinda like having your house or office building in a constant state of renovation, with no building plans provided to the owner/occupant as to what will be done and no word from the contractor on when any particular part will be done. If you’re in a captive market (which BSA volunteers/families kinda are), then a vendor (in this case BSA IT) can get away with a stunt like that. On the other hand, if there’s another vendor who provides a more robust feature set and clearer development/implementation information and timelines, then clients (in this case units) will go elsewhere if they can.

On balance, I think that Scoutbook (and even IA2) have the potential to be great software. I just feel like the desire to avoid publicly committing to a set of functionality to be implemented (even without a published timeline) is a cop-out. It may be a necessary cop-out because development resources may be even more limited than most of us suspect, but I think it breeds complacency when your users have no expectation as to what’s coming. There’s a fine line between disruption/flexibility that leads to better outcomes and that which leads to frustration.

As far as I know, they should have that ability. If they don’t, it’s a bug. So, no one made that decision. I think the bug is in the pulling positions from one system to use in another. Unfortunately, I don’t know when this will be fixed. As was mentioned above, the easiest route may be to convince someone to make you a key 3 delegate or unit advancement chair in the organization security manager.

You have ASMs that know what the Scouts did. They can vouch for that to the people that can update the activity logs until the access issue is addressed.