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

Workflow and Document Access

An interesting question arose in a discussion with a Korean customer this week. In that discussion I learned, that workflows are subject to a lot of cultural influences. Cultural influences come from the region as well as from the corporate culture. A typical requirement in workflow applications in AP: A user must not see other workflow documents (vs. the more European: doesn't want to/doesn't need to). A "must not" requirement mandates the use of reader fields (with all its performance ramifications) while a "doesn't want to/doesn't need to" requirement can be fulfilled with clever navigation (more on this in a later article). For good performance it is smart to use clever navigation in both cases.
When documents are protected by Reader Names, you typically find 3 types of entries in these reader fields: Full Names, Group Names and Roles. A Full Name (e.g. "Roger Rabbit/Toons/Warner Inc" mostly stems from the users directly involved in the workflow like the requester and the approvers, while groups and roles typically denote departments and/or business functions like warner.apps.controlling or [Audit] (I like structured group names). When a user moves on to a new department or role (e.g. from engineering to collection) (s)he would not be member of the respective groups and only will see workflow documents with direct involvement (The full name in a reader field). Depending on corporate culture that might or might not be acceptable. So what are the options to remove access for the user to these documents? What needs to be done is to make the entry in the reader field look different from the full name of that user. These options come to mind:
  1. The organization is using OU to specify the department of the users. The adminp/CA process is used to change the OU of the user moving to a new role. In this case the workflow database needs to be set not to touch names, reader or author fields. This is an advanced property in the ACL. The user name changes, the entry in the workflow database doesn't -< read access is removed.
    Caveat: Of course NO name change would be reflected in the database thereafter, so after changing your family name in marriage your workflow documents would "disappear"
  2. The organization is not using OU or the adminp for other reasons *must* update the workflow database. In this case the content of the Reader field needs to be changed. Ideally the change of role would be governed by a capable tool, so starting of the update agent can be automated. The agent would go through the workflow database and change the name of the user by prefix or appending an entry (like an OU): Roger Rabbit/Toons/Warner Inc -> Roger Rabbit/RoleChange/Toons/Warner Inc.
    Caveat: You need to be very clear with the auditors about such an agent. Altering a workflow document might violate corporate governance standards. It is therefore a good idea to separate the fields storing the business logic from the "access mechanic".... Which leads to the next option.
  3. You need to change the application slightly. The field that computes the read access based on business logic would actually be a names field. You have another names field "DocReadersRemoved" that is computed when composed as "". The DocReaders fields would be computed and have the formula @Trim(@Unique(@Replace(DocReadersCandidate;DocReadersRemoved;""))). An update agent, similar to the previous case would only update the DocReadersRemoved field and refresh the DocReaders field. This way no business data needs to be manipulated. If that process is properly documented it can be considered "Audit save".
In any case I highly recommend to limit the number of reader and author fields per document to exactly one each: DocReaders, DocAuthors (you could use DXLMagic to do the changes). These fields most likely would be computed and pull in their values from Names fields that contain the business logic. One good tip: Always include a special role in the Author field (e.g. [Joshua] if you know). That role doesn't need to exist in the ACL, actually it shouldn't during normal operation. If the database needs to be investigated for whatever reason you add the role to the ACL and the investigator.

Posted by on 12 February 2009 | Comments (3) | categories: Show-N-Tell Thursday


  1. posted by David Leedy on Thursday 12 February 2009 AD:
    Why do you recomment limiting a document to only 1 readers and 1 authors field? I do a lot with readers fields in an application. 9-10 years ago I followed this (for the most part) and had multiple values in a single readers field. Then I moved to using more readers fields with single values. This was easier to work with and I never noticed any problems.
    My one database might now have 500,000 documents each with maybe 5 or 6 different readers fields on it. And actually I'm about to convert many of those fields to Author...
  2. posted by Pierre Lalonde on Thursday 12 February 2009 AD:
    This is interesting. For our software solution (kiwi.hoop) we use a Lotus Notes Application to define Roles, Workgroup, Organizational structure and other object used as pointer in the process definitions.

    This way we could manage all kind or resources movement within the organization and assure to secure and transfer everyone's requests depending on the scenario.

    Go take a look at our Website and try the kiwi.hoop demo (this part have just been added to the site).

    Email me if you'd like to discuss about how we did it.
  3. posted by Stephan H. Wissel on Friday 13 February 2009 AD:
    As you have experienced, there is no *technical* reason. Multiple Author and Reader fields work as well and dealing with one value at a time makes a lot of things easier.
    However there is a *maintenance* reason. In my application I deal also with multiple fields, but they are all of type Names. I then combine them into two name fields DocAuthorsCandidate and DocReadersCandidate.
    In a standardized subform I then remove from this fields the value from AccessRemovedNames (another Names field). Per corporate policy: Person fields of business documents can't be altered outside the business process. The field AccessRemovedNames is owned by the DocumentAccessManagement business process (in form of an agent).
    This way I can remove access to a document easily (there is a defined field for that). We use the approach since we have business requirement where a manager taking over a new role must not see the documents of his old role (don't ask).
    Also: We use views categorized by that one field in all databases, so once a developer understands the way in one application she understands all of them. Makes maintenance and troubleshooting so much easier.
    What we experienced: since we use @Unique on the values and make sure we don't have duplicates over the 2 fields (if you are in Author you don't need to be in reader as long as there is at least one value) we see better performance in databases with 800k of documents.
    I guess I should publish a sample database to explain more of it.
    Emoticon smile.gif stw