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.
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.
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.
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
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.