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:
https://filestore.scouting.org/filestore/idg/MyScouting_Tools_FAQs.pdf 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.
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.