1. Site Organization Overview

A summary of the content types and where they may be located

The OpenEngagement CMS comes with one DMS Area and one KMS Area. The DMS Area comes with initially no further content and therefore no site structure. Firms must define their site structure. To use the OpenEngagement DMS, the CMS must, in its root, have at least one DMS Area.

The OpenEngagement DMS uses a hierarchical, or tree, structure to organize each site. This is similar to the directory structure used to store files with the Windows and UNIX operating systems, and is a very intuitive and flexible means of organizing content. The tree structure also allows the very simple and powerful security system used by the OpenEngagement DMS.

Although firms are generally free to organize sites as is convenient to them, there are restrictions relating to which content types may be placed within other types, as indicated in the following table:

Type	May Contain
Area	Areas, Entities, Sections
Entity	Entities, Sections
Section	Engagements, Pages, Files, Images, Links

Within the DMS, Engagements, Pages, Files, Images, Links (known collectively as Documents or Items) may appear only in Sections. In the KMS, however, there are also Pages, Files, Images and Links, but not Engagements. Within the DMS, users must create some sections in order to create Documents, but how many Sections users create is at their discretion.

The CMS root may contain: DMS Areas, KMS Areas, Smart Folders and Pages.

2. Table Views

Describes the Table Views given in the View tabs for Areas, Entities and Sections.

The Documents tabs of Areas, Entities and Sections provide a table, sometimes referred to as a report, which lists all documents within these objects. Initially, the table will list all documents from that location in the tree down, but users may use the filter provided above the table to filter which documents are listed. Users may fill in one or more fields here and then click the Filter button. If users desire more control over what is listed, they may instead use the Search tab. The number of documents shown per page within the table is controlled by setting the batch size in the OpenEngagement configuration.

The Entities tab provides a similar table and filter, though this tab will list only Entities, while the Documents tab will list Engagements, Pages, Files, Images and Links.

The Documents tab for the Area will list all Documents within the Entities and Sections within the Area, which will be potentially a very large number. But, by applying filters, a user can usually get the number of Documents shown to be small enough to be useful. This page may be used for the purpose of navigating to a specific Document or may be used to generate a report. The set of Documents listed will vary from user to user, as each user may have permissions to view a different set of Documents.

Which columns are shown in the tables, maybe changed by setting the View, which is a drop-down box above the filter. Users with sufficient permissions may define a set of views for the site. Each view defines a set of columns, their titles, and their order within the table. Any user with permission to view a table is able to set the view to any one of the views defined for the site. Setting the view affects only the current user. The OpenEngagement DMS ships with two views by default: Summary and All Columns. Firms may define as many additional views as they wish.

A different icon is used for the different document types. As well, padlocks and checkmarks are used to indicate the status of the document. A checkmark indicates the document is currently signed out, either by the current user or another user. A padlock indicates the document is set read-only, again, either by the current user or another user.

The tables in the Documents tab for Areas and Entities will have a single column for Entity. However, it is possible for a document to be within an Entity that is itself a sub-Entity of another Entity. In this case the document is actually within two Entities. In fact, Entities may be nested many levels deep. The Entity column in the table will show the lowest level Entity that the document is within.

As users move down the tree, the number of fields in the filters and the number of columns in the tables will be reduced. For example, if the current user is in a Section, there is no need to show the Area in the table, since all documents are within the current Section and therefore within the same Area. For the same reason, there is no need to filter by Area.

It is possible to sort by a column in ascending or descending order, within the tables by clicking once or twice on the column heading. The sort order of the tables will be saved. That is, if you sort a table by, say, year, the next time you view a table, it will be initially sorted by year, and all tables you view from that point on, unless you specifically sort them by another column, will be sorted by year. If you then sort a table by, say, state, then all tables from that point on, until you specifically sort them by another column, will be sorted by state.

Each field in the filters has a drop down, which can be accessed by hitting the down arrow if it is not already appearing. This lists all possible values for that field that will produce results.

When viewing the Documents tab for an Area, if the Area has any sub-Areas, the filter will include a checkbox to include / not include the sub areas. This will control whether or not the table lists any documents which are in sub-Areas. A similar checkbox appear in the filter on the Documents tab for an Entity, where that Entity has sub-Entities.

Below the tables in the Documents tabs, depending on the permissions of the current user, are the Rename, Delete & Change State buttons. To see these, the current user must have the Manager role or Site Manager role for the current location. Since it is possible for users to have a greater number of roles as they traverse down the tree, it is possible for users to see these buttons at some low levels but not at the higher levels.

The actions associated with these buttons are described in detail in this documentation.

3. Site Structure - Example 1

Root
     DMS Area (Area)
          Client ABC (Entity)
               Tax (Section) (Harry - Preparer; Sarah - Reader)
                    Engagement tax2001 (Engagement)
                    Engagement tax2002 (Engagement) (Sarah - Preparer)
               Internal-Audits (Section)
                    Engagement Internal-Audit 2001 (Engagement)
                    Engagement Internal-Audit 2002 (Engagement)
          Client DEF (Entity)
               Tax (Section)
                    Engagement tax2003 (Engagement)

Example 1 shows a straightforward organization, where the site has a single Area, in which are placed the Entities, each representing one client of the firm. There are no sub-Entities; the Entities contain only Sections, which contain Engagements. The main organizational tool used here is Sections. In this case the firm has used two Sections, one for Tax, which appears in both Entities, and one for Internal Audits, which appears only in one Entity. A realistic setup may look very much like this, only with many Entities.

The local roles are shown here in red. A realistic site structure would likely have many more local roles assignments than are shown here. These are provided simply as an example of how roles are inherited by users at lower levels of the tree.

Harry has been given the Preparer Role for the Tax Section within Client ABC. This will give him that role for all Engagements below that point, which in this example are the two Engagements: Engagement tax2001 and Engagement tax2002

Sarah has been given the local Reader role for Tax Section within Client ABC, and the local Preparer role for Engagement tax2002. This means, on Engagement tax2001 she has Reader permissions, and on Engagement tax2002 has both Reader and Preparer permissions. In this example, Reader permissions are strictly a subset of Preparer permissions, so it’s equivalent to having only Reader permissions on Engagement tax2001 and Preparer permissions on Engagement tax2002.

In this example, both Harry and Sarah have the Preparer role on Engagement tax2002.

As with Example 1, the type of each object is shown in parenthesis, and the local roles are shown in red. And as with Example 1, this is realistic organization, though an actual firm would have more Entities and more local roles assignments.

In Example 2, there is one Area off the root, but this Area has three sub-Areas to represent the three regions the firm works with: North America, South America and Europe. It is also quite possible to group them by type of client, for example, as Not-for-profit and For-profit, or Public and Private Companies, or by language.

Harry has been given the Entity Manager role for the South America Area. This will give him that role from that point down, giving him that role for the Entities: Group C, Client C-A, Group D, Client D-A, and ClientD-B.

In most sites, many more local roles would usually be assigned, though it is possible for firms to rely largely on site-wide roles. Each Entity should have at least one Entity Manager and each Document should have at least one Engagement Manager or Site Manager.

In the Entity Client A-A, there are several documents related to the Entity itself, and not to any specific Engagement within the Entity. These documents, two Links, one Page and one File, are put in a Section created for this purpose. One is a contact list, kept in an Excel file and uploaded to a File object.

5. Creating Content and Assigning Local Roles

In general, after creating the initial users, Managers or Site Managers will create Areas and Entities, and then assign local roles to these. They may, for example, give one firm partner and one firm manager each an Entity Manager role for each Entity. This may be somewhat cumbersome when manually creating the initial Entity objects, but will be easy from that point on. The OpenEngagement DMS will also have tools for bulk creation of Entities (for firms with and firms without CW Time) in a future version.

The Managers and Entity Managers may then also create Sections -- though likely most Sections used in the site will be created automatically when the Entities are created -- and assign one or more users the Engagement Manager role to the various Entities and Sections. Usually, the Engagement Manager role should be given to at least one user at either the Area, Entity, Section or Document level.

Only Engagement Managers, Site Managers and Managers may create Engagements. Most firms will not wish to give the Site Manager or Manager role to many users, so most Documents should be created by Engagement Managers. To allow this, each Section should usually have at least one Engagement Manager, assigned at the Section level or a higher level. This user may then create Documents and assign additional users local Engagement Manager roles on those Documents if desired. In the case of very small firms, though, it may be the case that few users are actually given Entity Manager or Engagement Manger roles. It may be that a couple people are given the Site Manager or Manager role, and they create most of the Entities and Engagements. With larger firms, many users may be given just the Entity Manager and/or just the Engagement Manager roles quite often.

Once the Documents are created and the Engagement Managers, Site Managers and Managers are assigned, they will then assign local Preparer, Reviewer and Reader Roles to each Document. There need not be anyone assigned to these roles, since, in theory, the Engagement Manager can do all the preparation, and review single-handedly. But, in general, there will be at least one Preparer and one Reviewer, and, in fact, most firms will have only Preparer, Reviewer and Reader role on most engagements.

Users will be given Reader roles based on the necessity of them viewing an Engagement in order to Prepare or Review another engagement, likely for the same Entity. For example, if a user is given the Preparer role for a given Engagement, they may also be given the Reader role for the Engagements for the prior one or two years. Most often, users would not be given a Reader role until an Engagement is in the Completed or Archived state, but this is not necessary.

Personal tools

Sections

Document Actions

Site Organization

1. Site Organization Overview

2. Table Views

3. Site Structure - Example 1

4. Site Structure - Example 2

5. Creating Content and Assigning Local Roles