Key 3 delegates not receiving Key 3 emails

The emails sent to the Key 3 delegates are not as expected:

Expected: If someone is a Key 3 delegate, that person should receive emails that are intended for the Key 3. An example is the emailed notifications of pending electronic membership application.

Actual: Our Key 3 receives pending electronic membership application emails. The Key 3 delegates do not.

The point is that the Key-3 DELEGATE is not one of the Key-3, by definition.

So, your expectation is inaccurate. The application notices go to the Key-3 only, as it should.

What you are asking for is a Key-3 PLUS Key-3 Delegate function or email. That doesn’t exist.

1 Like

I guess it depends on what the intended/actual function of a Key 3 Delegate is. If a Key 3 Delegate can take action on (e.g. approve) online new youth applications, then it makes sense to notify them that the application has been submitted. On the other hand, if that’s not something that a K3D can do, then notifying them would be superfluous. I see adult applications as a different animal, since they require COR action to approve (or COR + CC if that flag is set), although I think that the COR Delegate can similarly take those actions on behalf of the COR (and reasonably should get the relevant emails if so).

I think in the end, the issue may come down to one of local unit policies, in the sense that if you delegate functionality to a K3D, then that delegate should reasonably have the same access/abilities as the K3 delegating that functionality. If the unit wants to limit how much of the K3 functionality is delegated (i.e. more than the BSA functionality limits it), then it seems like creation and enforcement of relevant unit policies would be the way to go. That way, the desire of some subset of units to be more restrictive than another subset regarding what K3D are permitted to do doesn’t end up restricting things for everyone. In an ideal world, each bit of delegated functionality could be assigned a toggle switch to delegate or not to delegate. However, I can imagine that the programming effort in doing that would be cost-prohibitive (not to mention prone to “spontaneous generation” of bugs).

Separately, I do think that a clear explanation of the K3D functionality would be helpful. I wasn’t able to immediately find an explanation of how each of the functional roles work. It would be good to have a shortcut to any FAQ/wiki on the functional roles from the assignment page (or at least a clearer pointer to the my.scouting help system). Although there are help files describing how to use the Position Manager (e.g. Position Manager (myScouting) - Scoutbook Knowledge Base and Assigning a Key 3 Delegate or other position in my.Scouting (myScouting) - Scoutbook Knowledge Base), they don’t actually explain what each functional role’s capabilities are.

If you noodle around long enough, you can eventually find some information on limitations: lists the following when describing whether Key 3 Delegates can create additional K3D:

Q: Can a Key 3 Delegate grant additional leaders the Key 3 Delegate role?
A: Yes. When a leader is assigned as Key 3 Delegate, he/she will have the ability to update certain information having similar administrative tasks as a Key 3. However, some responsibilities cannot be delegated, such as accepting youth members or adult leaders. NOTE: Additional functional roles will be available as needed and as new tools are developed.

(Emphasis added)

That said, I had to google around to find that document, then dig through looking for what I know the system interface used to be called (Organization Security Manager), so it’s not surprising folks find it hard to be sure what the K3D are supposed to be able to do. It’s also unclear (given that the last document to which I linked is already out of date in terms of nomenclature) whether this restriction is still intended to apply, or even what other restrictions apply.

By the plain language of the name, the “Key 3 delegate” is delegated to handle any matter in that a Key 3 member can generally handle. Exception: does not include functions that are limited to one Key 3 member, such as the COR’s responsibility to approve members on behalf of the CO.

In IT terms, it’s just a way to have another unit admin in Scoutbook.

For more selected permissions, we already have discrete roles to slot people into, such as the New Member Coordinator.

1 Like

I don’t disagree that the name implies full delegation (except, as I noted, for things which are COR-specific). That is why I think that explicitly spelling out the functionality matrix for each functional role is valuable, even if it may change over time. It’s clear from the document from which I quoted that the BSA’s intent, however, is not full delegation of all Key 3 functionality. Why that’s the intent, and what those limits are, is not made clear in the document (at least not in the comparatively cursory reading it got when I dug it up).

There is an Registration Inquiry role - I am it for District and get a few emails a week on things, I assume there is one for Unit also

@DonovanMcNeil - yes there is a registration inquiry role in the unit

1 Like

There is. I hadn’t thought of that. I assumed that role was so that someone could view the official roster, not so that they could be notified of/take action on applications. That hadn’t occurred to me. I wonder if that’s documented somewhere… :wink:

1 Like

Just to be clear, receiving emails about new membership applications was merely an example. I didn’t mean to hinge this discussion on that.

More broadly, the name “Key 3 Delegate” does not match the experience of being in that role. I ask that the functionality match the name or that the name be changed to match the functionality.

What functionality do you not have that you want, specifically?

There are some functions that are simply never, ever going to be given to a Key-3 Delegate. Approval of adult applications, for example. That’s why there’s the functional position called COR-delegate.


Moreover, the Key-3 Delegate’s authority is set by BSA. The Key-3 Delegate will NEVER, EVER be able to do certain things unless you get BSA to change/amend the Rules and Regulations of the Boy Scouts of America and the Registration Guidebook of the Boy Scouts of America.

Scoutbook and cannot give you power as a Key-3 delegate that the BSA says you are not allowed to have.

A lot of this has to do with the BSA not publishing documentation on what the different roles can do.

An example. Our current COR reached out and needs to have me take over for awhile. Our chartered org has 3 units. It wasn’t obvious to met at first that a COR-delegate in one unit doesn’t really make you the COR-delegate for the CO. It’s scope is limited to that unit only. Which is very different than a COR. I was able become COR-delegate in 2 units that I already had positions in, but I needed to apply for a position in the 3rd, he approved, and now it allowed him to set that unit’s COR-delegate to me.

This would have been clearer to accomplish with better documentation.


That is a problem of poor UX design. Good UX shouldn’t need documentation.

Improve the UX is the solution. Part of that means role names that are clear. Last resort could be links next to each role that leads to documentation.

While I agree conceptually with this goal, realistically not everyone will extract the same information from the same nomenclature. That’s one issue with documentation-free systems. Good UI design & implementation (to provide the good UX that was designed) only goes so far. At a certain point, you’ll encounter something that isn’t readily made obvious in the UI or through the UX, or someone whose worldview on things is sufficiently different from that of the UX designers that the UX is largely opaque.

For example, since it seems like the BSA’s intent is that some of what the Key 3 can do will be reserved to the actual Key 3 themselves, but other Key 3 functionality is being delegated, you end up with a nomenclature issue. Key 3 Delegate could imply that all Key 3 functionality is being delegated. However, identifying exactly which bits of the Key 3 capabilities are being withheld is not easily identified in the nomenclature. One approach (just as an example, and likely not the best approach) might be segregating each function for delegation on a buffet-style tickbox list and naming each toggle accordingly. That makes it easier to select clear concise nomenclature. At the same time, knowing the details of what each tickbox “power” does is most precisely handled in documentation.

Regarding the potential opacity of any given UX for some people: nearly every kid I know finds it intuitively obvious how to fiddle through iDevices to get at things. Most adults can muddle along just fine, too. I find the Apple interface utterly alien, and have actually generated hysterical laughter in others watching me trying to use them. Many of the “universal icons” used in product instructions are similarly opaque to me. Omitting documentation (or designing it poorly) leaves users who can’t contort their brains into the right mindset to follow the UX/documentation designer’s thought processes out in the cold, or struggling to figure out what the intent was.

I was being tongue in cheek. :grin: Look at it as a continuum. Generally, we should get as close to the “needs no documentation” end as is feasible.

Agreed, which aligns with an earlier point where I recommend increasing privileges to match what the plain language of the role name. Even if we can dredge up some design document, I can see it making sense for Key 3 members to have a first lieutenant who shares privileges.

As stated above, the exception would be privileges reserved to one of the Key 3, such as the COR’s ability to approve new adult leaders.

I lean against as that is already done with discrete roles, which are generally named rationally. Plus I doubt many are used to an interface like that outside of IT nerds.

Admittedly tough but can be done in a sensible way that makes it rare to need documentation.

1 Like