Once content is in the system, it must be managed to ensure it can be accessed by those who need it, and to ensure it cannot be accessed by users and systems that should not see it.

Among the most common aspects of content management are:

• Controlling access
• Storage and archiving
• Collaborative communication
• Adding real-world metadata
• Validating and improving automated metadata
• Creating semantic links

Controlling access

The most common types of access are:

• See the content (browse, find and preview)
• Edit the content (make changes or add new versions)
• Access the content (share, download, print)
• Manage the content (move it or delete it, change access permissions)

Each content system differs in how it offers controls over content. Some systems enable you to define unique access to each piece of content, while others require that you assign controls to containers in which content is stored, or to permissions templates to which the content is assigned.

There are advantages to both methods.

When you can adjust access permissions for a given piece of content directly, this is very easy to understand—you give access to those users or machines you want to have access. If someone says she needs access to a given piece of content, you can simply connect to the system and add that user.

The drawback to this method of permissions management is sustainability: If you have 100 pieces of content and 10 users, this is relatively easy to manage. But if you have a million pieces of content and 100,000 users, this method of control would be unmanageable.

Instead, enterprise content systems tend to rely on associating user (or machine) groups or roles to containers or templates that can be applied en mass. This approach applies a layer of abstraction that makes management easier: Instead of potentially millions and millions of permissions matrix possibilities, you map a given set of templates to a given set of user roles.

In order for this control method to work, you not only need a system that is based on user groups or roles, as previously discussed; but you need to define policy for each content type that defines who should be able to do what with that content, and when.

In turn, you configure containers or templates to reflect that policy. When a given template is assigned to a given piece of content, the content inherits the permissions defined by the template. If the template is updated, those changes are reflected for all content associated with the template. A million pieces of content can be updated with a single change, which is the primary value of this approach. Another advantage is that you can more easily imagine the access assigned to a given piece of content just by knowing to which template is has been assigned.

In most content systems, permissions are applied either additively or exclusively. Some systems offer both approaches.

In an additive system, a given user’s access is defined by the combination of templates and rules applied to a given piece of content. For example, being part of the Marketing group might not grant a given user access to financial documents; but if that same user was also part of the Senior Managers group, and that group does have access to financial documents, then that marketing user would have access too.

In an exclusive system, typically only one template or container is active at a time on any given piece of content. The permissions defined by that template are in effect for associated content, no matter how many different roles a user plays in the organization.

As a rule, a system that is roles based should also feature an additive permissions model to provide the greatest flexibility.

Some additive systems also enable you to create templates or containers that impose exclusive permissions, when applied. So, for example, if there were a NO PUBLIC ACCESS template configured to behave exclusively, it would override any public access granted by other templates applied to the content.

Exclusive templates can be important time savers when configuring permissions, and they can also serve as safety nets to ensure content is not available when it should not be. Good examples are press releases or new product information that is under embargo, or content for which licenses have been lost or that should be archived. Without the option of an exclusive template, a content manager would have to manually review the entirety of templates associated with the content and remove those that granted access. This is a lot of extra work, and it can result in unintended consequences.

Worth noting is that when content is shared for, say, social media access or editing by an external user, a “tokenized” permission is added. This permission override is what makes the content accessible to others who are not working from within the content system. In the case of a request to edit, the permission might be temporary; in the case of a share to social media, the tokenized permission might be left in place indefinitely.