Access List and Default Item Access List(DIAL) - FileNet CS

Access List [This is the list which governs the access of a user to specific objects]An access list can control access on a user-by-user basis, the lists would become long and difficult to maintain if they listed all possible users by name.For ease of implementation of t he access control, the library system allows assigning access rights to groups, because groups contain sets of users who have common access requirements.

Because a user may belong to more than one group in a library system, access control is determined by a user's active group, that is, the group in which a user is currently working. Thus, when users change their active group, their access rights to objects also change accordingly. Using groups to control access greatly simplifies security. Suppose, for example, that there are seventy users in a library system, but these users all fall into three work groups: employees, supervisors, and a personnel department. Since there are also three groups with those same names, the access list for a document that corresponds to an employee's personnel record would need only three entries (one for each group), rather than seventy (one for each
individual user). If groups are created to match the way people work in an organization, their use in controlling access can ensure people will read and modify only the appropriate information.

An access list contains information about the users and groups who have been assigned specific access rights to a particular object. In CS Explorer, this information is displayed as Access Control object properties. Each Access Control object contains three pieces of information:
• The name of a user or a group
• The type of name
• The access rights granted

By default, a library system uses the following search pattern when determining a user’s access rights to a particular object and assigns the first access rights that apply:

1. Checks to see if the user is a member of the Administrators group.
2. Checks in the object's access list for an entry under the user name.
3. Checks in the object's access list for an entry under the user's active group.
4. Checks the access rights assigned to the General Users group, if included in the access list.
5. Assigns the user access rights of None.
Notice that this search pattern ensures that active members of the Administrators group always receive Admin access; thereafter, access rights specifically granted to a user take precedence over those granted to a group.

Default Item Access List [This list get sused when the user adds document into CS]Another way a library system can help users control access to their files is by inserting default entries in document access lists so that the user does not have to provide the same set of entries each time he or she adds a document.

You can specify a set of default item access list entries for each user in his or her User object. Then, each time that user adds a document to the library system from any user interface, the access list of the Item object is filled in with those specified defaults. Of course, to cover special cases, users can always change the access list of any documents they add, but they do not have to start from scratch with each document.
In the same way that you add entries to the default item access list in the User object, you can also specify them in Group objects and the System object.

Thus, the access lists of documents do not necessarily have a standard set of default entries. The library system does add default entries to the document's access list as the document is added, but to determine these defaults, the library system will check for entries in the Default Item Access List properties in the following objects and use the first such list with any entries:

1. The User object
2. The Group object for the user's active group
3. The System object

Version Numbering in FileNet P8 CE

Each document version is assigned a number that reflects whether the document is a major or minor version. This number is automatically assigned and changed by the Content Engine whenever a versioning action, such as a checkout, takes place that changes the version status of the document.
The version number is unique in the document version series and is actually comprised of two properties—the major version number and the minor version number. These properties are described in Versioning properties.
The numbering rules are fairly simple:

• A minor version always has some number other than zero as its minor number. Both 0.1 and 4.32 are examples of a minor version. Reservation versions are always assigned a minor number.
• A major version always has an integer other than zero as its major number, and always has a minor number equal to zero; for example, 5.0.

As you can see, these two numbers can be joined into what looks like a single number. Enterprise Manager and application such as Workplace sometimes display these numbers joined together with a decimal divider, with the major number coming before the decimal and the minor number after. In other places like the list of properties in the object property grid, the two properties are listed separately.
If a new document is first checked in as a minor version, its version number becomes 0.1. The next version in this series would be 0.2 if a minor, and would be 1.0 if it is checked in as a major version.
If a new document is first checked in as a major version, its number would be 1.0. The second version in this series would be 2.0 if a major version, and would be 1.1 if it is checked in as a minor version.
A document in the reservation state is always a minor document and has a minor document number. For example, if you check out a document numbered 2.0, the resulting reservation version is numbered 2.1. If you check out a document numbered 2.1, the resulting reservation version is numbered 2.2 (because a reservation is always a minor version).
It is on checkin that users can decide whether to check in the Document as a minor or as major version. A reservation number therefore stays the same if it is checked in as a minor version, and changes if it is checked in as a major version. For example, a reservation numbered 2.1 is still numbered 2.1 if it is checked in as a minor version. If the same reservation numbered 2.1 is checked in as a major version, its number changes to 3.0

Versioning properties

Several document class properties are important to document versioning. Each document version is either a major version or a minor version and is automatically assigned a major number and a minor number. See Version numbering for more about how the major and minor numbers make up a document version number. See What appears in folders? for details about which version of a document shows up by default in Enterprise Manager and applications such as Workplace XT. See Versioning actions to understand how actions like checking out or promoting a document determine the properties described in this topic.
Content Engine maintains the following read-only properties related to versioning:

• Major version number
• Minor version number
• Version Status
• Current Version
• Reserved

Major version number

A major version is one that

• has been approved as released, or
• was released in the past but has now been superseded by a more recently released version.

Released major versions are typically designed to be available to a wide range of users. Access to superseded major versions is typically more restricted, such as to a select group of authors and reviewers.
Major versions always have a minor number equal to zero. For example, a document with a major version number of 2 and a minor version number of 0, sometimes displayed together with the major number first, as in 2.0, is a major version.
If two-level versioning is used, the major number holds the current major version level of this document version series.
If single level versioning is used, all versions of the version series are major versions. The only exception is that reservations are always given a minor number, which in single-level versioning is therefore always 1. As soon as the reservation is checked in, the minor number goes back to 0 while the major number is incremented by 1.

Minor version number

A minor version is one that has not been approved and released as a major version. The most recently checked in minor version is marked in process. There can be only one in process version in a version series. Older minor versions are marked superseded, and there can be many superseded versions. Access to minor versions is typically restricted to a select group of authors and reviewers. A reservation document (the editable document version created by a checkout) is always a minor document.
A document is a minor version if its minor number is 1 or more (that is, not equal to zero). For example, a document numbered 2.1 has a major version number of 2 and a minor version number of 1 and is therefore a minor version.
If two-level versioning is used, the minor number holds the current minor version level of this document version series. Versions that are major versions (superseded or otherwise) have a minor number of zero. Versions that are minor have some number other than zero for the minor number.
If single-level versioning is used, the minor number is always equal to zero, with the one exception of the reservation as previously described.

Version status

Content Engine provides four versioning states that are automatically applied as a document version series goes through various defined stages. These states are released, in process, reservation, and superseded. Each of these states can be associated with a security template, providing easy control over the permissions granted on the document as it passes into a particular versioning state.

• Released: A major version that is generally made available to all users. Only one version of a document in a given version series can be in the released state at a time.
• In process: A checked in minor version, which is typically made available to a restricted set of authors and reviewers. Sometimes referred to as a draft. Only one document in a version series can be in process at a time. When a reservation document gets checked in and becomes the new in process document, the previous in process document becomes superseded.
• Reservation: A document whose content is currently being edited. A reservation is a full-fledged version and can be saved in the object store indefinitely. Even though you can edit both the properties and content of a reservation, there is nothing unstable about it; it does not act like an unsaved word processing document that is in danger of being lost if it is closed without being explicitly saved to disk. The term reservation is meant to convey that the author who is editing the document has reserved it for his or her own use. There can never be more than one reservation in a version series, because only the current version can be checked out. Reservations are always minor versions. Users can save the content of the reservation document one or more times before checking it in. Do not confuse reservation with Reserved.
• Superseded: A major or minor version that is no longer the most recent version. A major released version becomes superseded when there is a more recent major released version. A minor becomes superseded when there is a more recent minor in process version. There can be many superseded major and minor versions in a version series.

These version states are actually stored as integers and are sometimes displayed as integers by Enterprise Manager and applications such as Workplace:

• Released = 1
• In Process = 2
• Reservation = 3
• Superseded = 4

The text values ("Released" and so on) are associated with the integers by the Version Status Lookup Custom Object. You can edit this custom object to change the strings to some other value. You can, for example, change "Released" to "Public version" or "In Process" to "In Progress".
For information about how security policies can be designed to automatically apply these changes of permissions to versions as they change from state to state, see Security policies.

Current version

Current Version is a property that defines which version in a version series is the most recent version, other than the reservation. (The reservation cannot be the current version.) The value of this property is used by events, folder references, and other server or client-based processes that act on the latest version.

Reserved

Reserved is a property that is set on the current version when it is checked out. The term "Reserved" is meant to convey that the current version is no longer available to be checked out. Do not confuse with reservation. When the Reserved property of the current version is set to True, there must also be another version that is the reservation.

FileNet Content Services Concepts - Part 6

Property Manager The components in the library system that store and maintain in a database a library system's objects and properties. These objects and properties identify and describe stored documents and unstored items. They also describe users, groups, searches, and system components. Each library system has its own Property Manager. The Property Manager is roughly equivalent to the database engine, but has a slightly larger conceptual purpose. For example, each of the library systems that happens to share a database engine is said to have its own unique Property Manager.

Property repository A Microsoft SQL Server database or Oracle tablespace that contains the objects and properties for a single library system. The objects and properties identify and describe stored documents and unstored items. They also describe users, groups, searches, and system components.

The documentation generally refers to a SQL Server database or Oracle tablespace as a property repository only after you have installed the associated library system and applied its initial changes to the database or tablespace. Prior to library system installation, the documentation uses database or tablespace rather than property repository (for example, “To create an Oracle tablespace:").

Property server The server where the library system database engine is installed. Typically, this server is also the initial storage server, but under certain configurations, may be a standalone database server instead.

Storage Manager The library system service that processes operational requests (for example, to check in or check out) and stores version files controlled by the library system.

Storage category To a user, such a category typically describes a type of file (for example, Word Docs, Payroll Records, Memos). To an administrator, storage categories provide a way of controlling load balancing in the various storage repositories. Storage category names are determined by an administrator to reflect the working environment at a particular site. One or more storage categories may be assigned to a storage repository and administrators can change these assignments as load requirements change.[Can be visualize as document class]

Storage repository A storage area (that is, a directory) for specific version files controlled by the library system. Each file is stored according to a storage category, which is assigned when the file is added to the library system as a protected item. A storage repository may be assigned numerous storage categories for a particular installation of a library system.

Storage server Any server where initial or additional services for a library system are installed.

Verity K2 Master Admin The Verity component that governs all Content Search Managers for a library system.

Verity K2 Master Admin Server The server where the CS installer places the Verity K2 Master Admin that governs the Content Search Managers for a given library system.

Archive category Describes a way of handling version files that are moved offline during automatic or manual archiving. Each protected item is given an archive category (for example, Archive To Tape) when it is added to the system. Each archive category is assigned to a specific storage directory called an archive repository.

Archive repository A storage area (that is, a directory) for specific system-controlled version files that are moved offline. The archive repository is where the files are held while awaiting archive storage or destruction outside of the library system. Archive repositories can be described as reclaimable or no reclaimable. Typically, files that are moved offline through a reclaimable archive repository are more easily reclaimed for use at a later time. Each archive repository may be assigned numerous archive categories.

Content Search Manager A software service that contains the program files required to make content searching for version files available with the library system.

Content search repository A named collection of files identifying versions that have been indexed so that users can find those versions based on the actual contents of the version files. You must add at least one of these content search repositories for each Content Search Manager.

FileNet Content Services Concepts - Part 5

Replication Services Overview

Replication Services gives your documents greater availability across your enterprise, automatically and without compromising document integrity. Instead of manually creating and maintaining the necessary user accounts and documents on separate libraries, replication automatically copies the documents and related security to another library system.

Replication Services provides a way to make documents and items in one library system available to other library systems. Replication Services automatically copies documents, items, and their security to additional specified library systems. As documents are checked out, updated, and checked in again, the changes are synchronized across the other libraries.

When a document is replicated, both the file content and the property values for standard properties and existing custom properties of the document are copied into the library systems participating in Replication Services. Users can quickly locate and access a replicated document anywhere in any replicated library. All instances of replicated documents or folders in any library system are periodically synchronized with any alterations to the original document or folder.

However, the synchronization is not immediate. That is, Replication is an asynchronous store-and-forward system. Changes are logged into a queue for processing, and then propagated to the replica libraries. The processing may take place almost immediately, or it may take place only during certain hours of the day, depending on your configuration parameters, the number and type of changes requested, the network load, and the availability of the replica libraries. For example, if a replica library is offline for maintenance (or a power failure), the update cannot be completed until the library is available again.

A replicated document's current status is reflected on all the participating library systems: if checked out, a document will be marked as checked out on all of these library systems. When a new version is checked in, that new version is replicated to all the participating library systems. Replication Services runs independently of the other library system services. Thus, Replication Services can continue running while other library system services are stopped and restarted and can automatically resynchronize with these library system services when they restart. Using Replication Services can have a profound impact on your library system configurations and the hardware and software resources required. Take time to carefully plan your system before you implement replication in your network.

Additional point: You must copy Document Classes and Controlled Vocabulary Lists (CVLs) from one library to another using the import and export tools available in CS Explorer.

FileNet Content Services Concepts - Part 4

Deleting Sessions

In a library system, an active session is the open session that a user is currently working in. There are actually two sessions involved when a user is logged in to a library system via a Content Services client application, such as IDM Desktop or CS Web Admin environment. One is the database connection session, and the second is the Content Services library session.

When a CS client application exits or is killed, the corresponding database connection session is deleted from the database. You can also delete all the database connections at once by stopping and restarting the database. If a database connection session is deleted, then any corresponding active CS library session is said to be an orphan session.

CS library system sessions are tracked by CS Explorer but cannot be removed by it. Neither stopping and restarting the database or CS services will delete an orphan session. Nor will rebooting a workstation where a CS client application is running. To remove these orphan CS library sessions, you can invoke DSSTOP on the server where the library system is resident. Alternatively, you can simply allow the daemon running on the database custodial server to periodically check for suspended sessions. The daemon will remove any orphaned sessions that are more than two days old. To find out what sessions are open in a particular library system and to see whether these sessions are active or suspended, you can check the status of the Sessions object using CS Explorer.

Resetting the Session ID

The library system maintains a unique session ID for each library system session. The session ID is incremented each time a user opens a new session. Over time, it is possible to exceed the limit of approximately 2 billion (231) session IDs.

To avoid an overflow condition, we recommend that you periodically check the value of the Session Number  property in a Session object (the value of this property is the session ID). When the value of the Session Number property approaches 2 billion, you should reset the session ID to 0.

To reset the session ID:

1. Stop the library system and database services.

2. Restart the database services.

3. Using your SQL query tool (SQL Server Query Analyzer for SQL Server or sqlplus for Oracle), reset the session ID to 0.

• For SQL Server enter:

use system_name

go

delete from session

go

update numid set se_id_num=0

go

• For Oracle enter:

delete from system_name.session;

update system_name.numid set se_id_num=0

4. Restart the library system services

FileNet Content Services Concepts - Part 3

Secure Document Delete

With the Secure Document Delete feature you can scrub your sensitive document files to prevent any possibility of recovery via disk recovery tools. Scrubbing means to overwrite its contents with a byte pattern before actually deleting the file.

Scrubbing means that the file's entire content is overwritten by a byte pattern before the file is actually deleted. Secure Document Delete does not delete files from client machines. To ensure secure delete functionality on servers containing library system components, do not install client interfaces (such as IDM Desktop) on those servers.

Neither Replication Services nor Web Services scrub files during add, checkin, and checkout operations. For simple delete operations as may be desired during a “purge” process however, Secure Document Delete is applied on all servers that have this feature turned on.

You can configure the Secure Document Delete feature for each Storage Manager by selecting one of the options described below.

Level	Description
No Secure Deletes	Ordinary delete. Files are not overwritten before being deleted.
One Scrub	Files are overwritten with zeroes once before being deleted. This level corresponds to the Clear definition of the DOD 5220.22-M specification.
Three Scrubs	Files are overwritten once with an arbitrary character, again by the character's complement, and finally by a random character before being deleted. This level corresponds to the Purge or Sanitize definition of the DOD 5220.22-M specification.

The initial and additional (remote) Storage Managers of a library system are each separately configurable with respect to secure deletes. Whether an item (document) is securely deleted depends on the secure-delete setting of all the Storage Managers that govern the storage repositories where the versions of the item are stored.

When an item is added to a library, it is given a Storage Category, which is associated with the storage repository where the versions of the item will be stored. As one storage repository fills up, the system administrator will assign the Storage Category to another storage repository. Thus, over time, different versions of the same item may end up in different storage repositories.

To ensure that an item is securely deleted, make sure it is given a Storage Category all of whose associated storage repositories will only be on servers where the Storage Manager is configured for secure deletes. Beware that if even one of the storage repositories associated with the Storage Category is on a server whose Storage Manager is not configured for secure deletes, then any versions of the item that are stored on that server will not be securely deleted.

Secure Document Delete Limitations

On UNIX platforms, files larger than 2 Gbytes will not be overwritten and must be scrubbed using special tools. On Windows platforms, files will be scrubbed securely up to the full Windows 64-bit limit.

Secure Document Delete does not scrub property data in the database; this remains the job of the database administrator and the database itself. Microsoft SQL Server and Oracle do not scrub database data during row or table deletion.

You cannot obtain Secure Document Delete functionality on compressed disks or files. Do not use defragmentation tools on the disk containing the stored document files. Such tools move the files on the disk without pre-scrubbing them, making secure deletes unsupportable.

Some database metadata (such as file names, Item IDs, Version IDs) are not scrubbed in subtle places. For example, when a search query is performed, even on the server, a temp file is used to store the results. When the query ends, the temp file is deleted (but not securely). Database metadata is generally insecure; even Microsoft SQL Server and Oracle databases cannot do secure metadata deletes.

The Windows pagefile and UNIX swap files may include memory images that need to be paged to disk, and the memory image may include the files you are copying or writing. The Secure Document Delete functionality cannot scrub these files.

Reformatting a hard disk may not overwrite data on the disk. If you reformat a disk containing storage repositories, you should use other tools to scrub the disk clean of file data.

The uninstall command (dsuninst.exe) does not scrub storage or index repository files.  Activities such as the actions of the executable files that perform during installs and upgrades, the use of tools, and utilizing configuration code, do not carry out secure deletes. For example when DLLs are copied to a temp directory, they are not scrubbed when they are removed. Secure Document Delete does not work on Hierarchical Storage Manager extended drives. HSM controls access to files on media and cannot guarantee scrubbing in the process of a move or purge

FileNet Content Services Concepts - Part 2

Library System Security

One of the powerful feature of the library system is the security it provides for your important information. Each time you or any other user adds a document to the library system, you determine the document's descriptive properties and its associated version files and properties that users and groups will be able to access. You provide this information using the document's Access List property. For further security, there is also an Access List property  for all users and groups. Three objects commonly referenced by users and administrators contain an access list: the User object, the Group object, and the Item object. However, access rights to entities without access lists (such as versions) are passed down through “parent” objects (such as the Item object). So, the library system provides a simple way to set up and maintain access control, yet allows this security to be as controlled or permissive as necessary. There are five levels of access rights in a library system:

Access Right	Privileges granted
None	No access. If no other access level is stated in the access list, access rights of None are assumed. An access level of None can also be explicitly stated in an access list.
Viewer	Generally, the ability to view the object properties or to make copies of the associated versions.
Author	(Applies to documents and versions only) Viewer access rights plus the ability to checkout ,check in and copy associated versions and modify property values for the version. In addition, you may be allowed to modify designated custom property values for the document.
Owner	Author access rights plus the ability to delete documents, modify security and modify most properties.
Admin	Owner access rights plus the ability to modify all property values. Active members of the Administrators group are automatically assigned Admin access rights to all properties, even though their names do not appear in any access lists. Users who are not members of the Administrators group can be explicitly assigned an Admin access level to the properties associated with particular objects.

DIAL – Default item access list

Access List Defaults

To ensure that each access list contains initial entries, a library system provides some defaults in the User, Group and Item object. In User and Group object access lists, these defaults are standard entries that are always added, as shown in the following:

Name                           Type                Access Level

(Added By User)         User                 Admin

(User's Name)              User                 Owner

General Users              Group              Viewer

The Added By User value is the user who added the object to the library system. This user and any user with Owner or Admin access rights can modify the values after the User or Group object has been created. The Administrators group always has Admin access rights, even though these rights are not displayed in the access list.

Default Item Access Lists

Another way a library system can help users control access to their files is by inserting default entries in document access lists so that the user does not have to provide the same set of entries each time he or she adds a document. You can specify a set of default item access list entries for each user in his or her User object. Then, each time that user adds a document to the library system from any user interface, the access list of the Item object is filled in with those specified defaults. Of course, to cover special cases, users can always change the access list of any documents they add, but they do not have to start from scratch with each document. In the same way that you add entries to the default item access list in the User object, you can also specify them in Group objects and the System object.

Thus, the access lists of documents do not necessarily have a standard set of default entries. The library system does add default entries to the document's access list as the document is added, but to determine these defaults, the library system will check for entries in the Default Item Access List properties in the following objects and use the first such list with any entries:

1. The User object

2. The Group object for the user's active group

3. The System object

To understand how default item access lists work, consider the following example. At the law firm of Hunter and Bowers, senior lawyer Sarah Black is using IDM Desktop to add an item to a library system. She knows that her system administrator has given her active group (Attorneys) the default item access list (shown below), which will be applied to all documents added by the group's members.

Name                           Type                Access Level

Attorneys                     Group              Author

Managers                     Group              Author

Paralegals                     Group              Viewer

The system administrator has left the Default Item Access List property blank in Sarah's User object because Sarah  always wants the default access list for her active group to be applied. (Likewise, whenever Sarah changes her active group, the library system will apply the default item access list of her new active group.) She also realizes that since the default access list at her active group level does not mention her name specifically, she will receive the program default access rights for any user who adds a document and Owner access rights to the document that she is adding to the library system. And with Owner access rights to the new document, she can modify the entries in the document's access list at a later time if necessary.

FileNet Content Services Concepts - Part 1

The Library System

Content Services (also called the library system) provides server-based enterprise content management (ECM) that can be accessed via a client interface using applications such as FileNet IDM Desktop or FileNet Web Services. An enterprise, especially if it's spread across various sites, may have multiple library systems, depending upon sizing and load balancing considerations.

A typical Content Services installation comprises the following components:

• One or more library systems.

• One or more administrative clients.

• One or more ECM clients (such as IDM Desktop).

• One or more application solutions (such as FileNet Web Services for intranet/internet access).

As you can see in the following illustration, each library system has a set of sub-components that you install and configure to provide the services for your various client-based users.

Each library system acts as an information storehouse.

·         The Property Manager stores and manages object properties (users, groups, system, and custom properties) and metadata describing your catalogued documents.

·         The Storage Manager stores the actual documents and process requests.

·         The Content Search Manager provides document content-based indexing and searching capabilities.

·         CS Replication Services, which allows you to replicate documents across multiple library systems.

You have the option to locate your database on a standalone property server. In this configuration, the initial Storage Manager, Content Search Manager, and Replication Services would be located not on the property server, but on the initial storage server.

Protected Items

When you add a document to a library system, you usually add it as a protected item. It is called “protected” because the library system physically stores the document, thereby protecting it from unauthorized access, inadvertent removal, and more. Protected items can be documents that were created by any application (for example, word-processing documents, financial spreadsheets, images, audio, tables, and so on).

Unprotected Items

A library system also lets you control and manage unprotected items (external documents), which are items that are not physically stored in the library system but are tracked for easy management. This capability is especially useful for items that are stored in special locations, yet still require version tracking or controlled access. Some examples are: magnetic tapes, printed technical manuals, printed engineering drawings, and software source code listings. Although the unprotected items added at most sites represent these kinds of physical objects, unprotected items can also be electronic files that you do not want to store in the library system.

FileNet Content Services Features

Network-wide Search and Retrieval

FileNet Content Services (CS) systems allow documents to be identified using plain language titles and property names, not cumbersome file names. End users can search for documents based on their properties and/or their content. Regardless of the user's location or the file's location, complex path commands with coded document names are never required. Documents are checked out of and checked in to the FileNet CS system for updates and revisions. One simple end user command transparently saves, tracks, and archives any document.

Logical, Not Physical, Storage Pointers

Unlike conventional document management packages that rely on physical file locations, a FileNet CS system does not require users to have any knowledge of where documents are actually stored. In fact, users are shielded from that knowledge, providing an added layer of security for the documents and the network. Document management systems that use physical pointers require constant supervision and cumbersome revision as networks grow and change.Moving files, adding users adding or changing directories means updating every single workstation individually. With a FileNet CS system, such system changes can be handled centrally by the network administrator.

Object-Oriented Approach

A FileNet CS system encapsulates all types of files and objects. Each object is described by properties such as description, security, and administration. Actions are performed against objects using these properties as variables. In this way, an ordinary file becomes an “intelligent” document because, regardless of how or where it is used, the document retains its properties and always knows who is authorized to view it or make edits, where it is to be stored on the network, and how it is to be administered and archived.

Version Control

When a user opens a document for editing, it is designated as checked out. The user is always provided a copy of the particular version of the document, and the original copy of that version remains protected. Other users who try to access a document version that is checked out are notified that it is checked out and by whom. While the document is checked out and being modified, users can view the latest checked-in version of the document. When the user is finished working with a checked out version, he or she can check it in. The FileNet CS system retains the old version and automatically saves the checked in document as a new version. Once checked in, the old and new versions of the document become available for check out to other users. When users access the document, they are free to check out the most current version or go back to older versions as needed.

Multilevel Security

An access control list is created for each document added to a FileNet CS system. This access control is part of the document's properties and is independent of the document's location on the network. In this way, authorized users have access to the information they need, no matter where they or the documents are physically located. Yet all stored documents are well protected, because only the documents that each user is authorized to see will be displayed as the result of a search.

A FileNet CS system controls who can create new versions of any given document, regardless of data type, application used, or storage location. Security levels determine access rights such as Owner, Author, Viewer, or None. The only access to documents is through the FileNet CS system. File names are encrypted and users are prevented from bypassing the FileNet CS system to access files via the network operating system. CS administrators should not share the directories where FileNet file are located.

ECM Administration Tools

FileNet CS systems include a Windows® based administrative tool. ECM administration tasks such as adding new servers, designating new storage locations, or adding new users and groups can be performed at any time, no matter how many users are online. In addition, a web browser-based version of the administrative tool that includes a subset of the windows-based administration tool is available for administrators who want mobile access to library system properties and the ability to start/stop CS servers remotely.

Flexible Open Technology

CS is designed to work with virtually every combination of user interface, application, and  hardware/software. Creation and maintenance of general office documents (including enterprise, departmental, workgroup, and personal documents), legal document management, email, as well as document imaging may all be handled through a common repository. This means that no matter how many platforms or environments are used across the network, all enterprise applications are interoperable. Additionally, any enterprise can take advantage of FileNet IDM Desktop (and, if necessary, CS API programming functions) to build custom enterprise applications as future needs emerge.

Load Balancing and Scalability of Distributed Services

No matter how an organization's workload grows and changes across departments or divisions, the  FileNet CS system's queue management and load balancing features ensure a consistent working environment for end users.