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
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.
Keep Access Simple and Policy Driven
As a rule, it is a good idea to provide only the minimum level of access that any given role requires do what it needs with the associated content. For example, if your external partners will not be contributing content to the system, do not grant them that permission.
You might think there is no harm in permitting trusted partners to add content if they want, but the greater issue is one of policy adherence: If your policy that defines the External Partners role does not include the option to contribute content, and you enable this permission on that role, you are defining roles that are outside the scope of policy. Later, if there is an access problem in the system, it can be much more difficult find and correct if system managers can’t rely on current configuration to accurately representing written policy.
This excerpt from Picturepark’s Routing Digital Content through the Enterprise is part of a multi-part blog series that features sections of the complete document.
- Users and Flow
- User Groups and Roles
- Content Creation and Acquisition
- Access for Collaboration
- Storage and Archiving
- Real-World Metadata
- Next week: Automated Metadata
A complete copy will be made available as a whitepaper at a later point in time. Please subscribe below for getting notified about new blog posts every month.
Content Creation and Acquisition
At the start of each content flowpath will be a content source. Your initial flowpath sketches can identify nonspecific sources, like “internal staff” or “agency,” but you will eventually want to get more exact with regard to actual content sources, where possible.