There's a lot of features on AKO that can be quite useful to an organization. Knowledge centers, and other features can provide for mass, or targeted communication and sharing of documents.

Setting up and maintaining your AKO groups can be confusing and difficult if not properly planned. What I want to discuss here is my theories for logical use of AKO groups.

First let me define the AKO group. A group is basically a listing of people and groups that can be used to assign permissions to AKO features (such as knowledge centers, discussion forums, etc.)
example:
I have a group called "1st squad" and a group called "2nd PLT". "1st squad" group has 10 Soldiers in it and "2nd PLT" has none. I can add the "1st squad" group to the "2nd PLT" group. By doing so everyone in 1st squad now has all the permissions that 2nd PLT has. If the membership of the squad changes, so changes their membership in the PLT.

Now I could just add people to the 2nd PLT group and be done with it, but that will ultimately limit the choices I have for assigning permissions.

Theory concept #1: Assign individual users (Soldiers) to the lowest organizational level practical. Assign lower organizational elements to the parent organization by the group rather than the user.

The purpose behind this is to add a Soldier to as few features as possible. There's no need to add him to the company, battalion, or brigade if he's already there by virtue of his squad membership. This also simplifies removal of the Soldier from the groups. For each individual user you add to a group, you must individually remove him when he no longer needs the permissions. If all of his permissions are by a lower level group, removing him from that group removes him from all those permissions.

Theory concept #2: Assign permissions by group only.
If I have to assign a Soldier to 3 different groups and 3 different knowledge centers for 3 levels of command, I've just created a lot of work. Instead, I can assign knowledge center (or page, forum, etc.) permissions to groups.

Example:
A squad has a group, and knowledge center. Knowledge center has the squad group set in it's permissions.
The platoon has it's own group which contains each squad group, a discussion forum, and a knowledge center.
The company has it's group containing each platoon, knowledge center, and web page.
The battalion has the same stuff as the company.

So in this situation where knowledge center, web page, and forum permissions are all assigned to groups, we can add joe.snuffy to the squad group and he automatically (by virtue of his group membership) has permissions to all of these features. He would not however have permissions to another squad, platoon, or company. Removing him from that one group, will remove his permissions to everything that was granted by virtue of that group membership.

Theory concept #3: Specific positions as groups.

While slightly counter-intuitive, it's a very good idea to make a group that is designed for only one person. The major advantage is when a Soldier in a certain position requires permissions to AKO features, but the assignment to that position is subject to change.

example:
A platoon leader is the administrator of his platoon group, has access to the training records knowledge center for his platoon, and is also in the company's "platoon leaders" group so the CO can mass e-mail all of his subordinate officers. By assigning permissions to a group instead of the individual, we only have to move him out of one group when he PCSs, and we only have to put his replacement in one group.

This can also be useful for Soldiers with additional duties who may have permissions apart from their normal organizational structure.