Usability - Productivity - Business - The web - Singapore & Twins

Bring order to your group names

I'm not and admin buff, so I try to keep time spending in administration short. Management of groups for security purposes can be a drag on your administrative time. Since Notes basically let you do whatever you want, I find a lot of organic grown group structures. These are hard to maintain and often confusing. So over the years we refined a group structure, that is easy to understand as well as processable through code. The groups consist of three semantic elements connected by a dot:

&domainname dot metagroup dot purpose

Some examples:



&domainname stands for your domain name or a sensible abbreviation of it.
metagroup can be either sys for system group (e.g. server access) or apps for applications
purpose can be composed out of one or more sub-elements. In the system metagroup it would be either an access role .createdatabase or a servername with an access role x34za.denyaccess. In the application metagroup it always will be the name of the application and the application function. . leave.hr .po.manager etc. Depending on your organization's size you might want to tweak the structure rules for the best fit (<advertisement>if in doubt ask TAO for consulting services</advertisement>). Keep in mind to stick to the maximum length of 64 characters

The structure has a number of advantages:
  1. Using the # in front makes sure the groups are not mixed with user names or mail-group names in the address dialogue
  2. Having the domain (or a sensible abbreviation of it) in front eases the maintenance of ACL of databases and templates that get replicated across domains (e.g. from system integrator to customer)
  3. The structure allows for easy parsing. E.g. a server document must only contain groups that have .sys. in the second position. A ACL can only contain groups that carry the application name in third position. We typically use a registration database where all databases are configured with their "application name" to a acl scanner can find inconsistencies
  4. We typically add a #mycorp.apps.NameOfTheApp.support group with designer rights to every database. The group is empty. When there is a need for troubleshooting a workflow process will add the developer to this group for a specified time frame. This way we avoid the two pitfalls in security: giving developers full admin rights or giving them permanent developer access to production databases
  5. Since group names for applications are well defined you can use the application registration database for some kind of self service, where the business owner of a database grants access to a user by filling in a form and a background agent is updating the Domino directory. You can have as much audit trail and workflow as your auditors need to see.
  6. ACL structures can be fine granular and well defined at the same time. E.g. you can enforce (and scan) rules like: If it is not a mail file, there must not be a person entry. Every database needs a support group with designer access (the structure would determine the exact name). etc.
Update: IBM recommends not to use #, so I replaced it above with &

Posted by on 16 March 2006 | Comments (2) | categories: Show-N-Tell Thursday


  1. posted by Rock on Friday 17 March 2006 AD:
    Stephan - kewl idea! This is similar to the way I name script libraries and other design elements - to bring structure to it. For instance, I have a script library named LS.utilities.BE.6 - here's the breakdown:

    ** LS == it is a LotusScript library
    ** utilities == the purpose/use of the library - in this case it is a general purpose utility library that I use in most of my apps
    ** BE == this is a Back-End script library, meaning that it contains only back-end class calls. This lets me know that the library is safe for use in scheduled agents, web agents, etc.
    ** 6 == this tells me the minimum Notes/Domino version that this library can be used. This library is designed for 6.x and above.

    This naming convention makes it much easier to know how/when/where I can use the script libraries.

    So, I really like your group naming convention because it extends this concept into an area I hadn't previously considered.

    Once again - good job!

  2. posted by jack dausman on Saturday 18 March 2006 AD:
    Stephan: terrific idea for all the system oriented groups (and makes me think about making order for the remaining mess). Is there a reason you don't want to move the admin groups into a secondary directory?

    Thanks, Jack