Groups and roles are as applicable to machine users as they are human users, though you will likely create different groups or roles for each type of user.

Groups combine users based on some attribute of who those users are, such as employees in Marketing or Sales, or partners, customers, etc. Roles combine users based on what users need to do in the system, such as upload content, edit content or manage the system itself.

In the roles paradigm, a given user is typically added to more than one role, collectively defining all rights and duties that user has within the system, regardless of the corporate department to which that user belongs. For example, someone who contributes content to the system might also need to find and share content.

Consider the following example roles:

• Content Contribution
• Content Browsing
• Content Sharing
• Content Editing
• Content Management
• Content Archiving

By adding a user to the three boldfaced roles, she can perform the functions she needs, without being able to edit, manage or archive content. Note that these roles have no bearing on a user’s department or title, or even whether that user is an employee of the company. For this reason, a single role structure can be used to manage employees, freelancers, agencies or anyone else.

In some cases, you might find that your groups or roles align with your personas, which is an added benefit of having personas. Referring back to the “Scott” persona, any user who fits that persona would be added only to the Content Browsing and Content Sharing roles.

What is important to consider when looking at content system components is how each works with groups or roles. Though each component might come from a different software maker, the permissions paradigm they use must be compatible, or else system configuration and maintenance will be much more complicated, if not impossible.

For example, if one component of your entire system uses only user groups that must be mapped to the groups in a global user directory, such as LDAP or Active Directory, you will be unable to adopt a roles-based approach to your greater user management. (Your global user directory is more likely organized by department than content considerations.) This is another reason to befriend someone from your IT team who can guide you during content system evaluations.

Policy-based Content Flowpaths

After thinking about users, roles and groups, think in terms of the path content travels throughout your organization:

• From where or whom does your content come?
• Where does your content need to go for processing, editing, approvals and storage?
• How will your content be used, by whom and from where?

You will likely need to create multiple content flowpaths because situations and needs will differ for different types of content. The granularity with which you create these flowpaths will depend on how they will be used, and by whom. The good news is that you do not need to start with too much detail.

Start by defining a few high-level content types, such as:

• Financial documents
• Product/service content
• Policy documents

The value of starting with broad-strokes categories like these is that they apply in virtually all cases. For example, the above categories are as applicable to a local doctor’s office as they are to Apple and Siemens. In time, you can further refine your core categories, if needed.

Apply the questions above to the lifecycle of your financial documents:

From where or whom do your financial documents come?

Your financial documents might be produced in house, or they might come from an external accounting or other provider. The source of these documents should be considered because that source will need access to your system in order to submit the documents.

Where do your financial documents need to go for processing, editing and storage?

Once submitted, what happens to the documents? Perhaps they are sent for review by managers or your CFO, after which they are sent to your CEO for final approval. Maybe national or institutional regulations mandate that these documents be stored on dedicated storage devices not accessible to most users.

How will your financial documents be used?

What happens to those documents once they are approved? Perhaps they are shared across your organization, sent to media outlets and investors, regulatory bodies and partners, and maybe even published on your website, or shared via social media. Once the financial cycle has ended, the documents might be archived to a special location where they are no longer editable.

In answering these questions, you create a checklist of sorts that you will use for further system, policy and procedure design:

• What types of business systems will you need to manage the flowpath?
• Which users or user groups are required, optional or should be excluded?
• What network or security concerns have you identified?
• What approval processes are required?
• What regulatory adherences and reporting are required?
• What storage requirements are unique to this content type?

Finally, and perhaps most important, is whether you can identify any “holes” in the flowpath.

For example, if policy mandates that your CFO must approve a document before your CEO sees it, what happens if your CFO is unavailable?

If policy mandates that a given financial filing be submitted to a regulatory body within 10 days of the close of a quarter, what mechanisms do you have in place to ensure compliance with this policy?

What happens if one or more of these processes fail?

What happens if the system goes offline or is compromised?

Try to interview those at your organization who have institutional knowledge about the content type and the requirements of the process. These folks can help you account for things you might not think to consider, and they can help you define what should happen when things go wrong.

Then do the same exercise for your other content types.

Where you find yourself thinking “it depends on the type of content,” you need to get more granular about your flowpath definitions. In some cases, an entirely new flowpath will not be required, if you can cleanly isolate differences into branches that are easily defined and configure into your software systems.

For example, you might find that the flowpath for your regulatory filings differs from that of your quarterly investor briefings only in in that the investor briefings are not distributed to the public.

The goal is that you document from where content originates, what happens to it, and what course of action must be taken if something goes wrong.