MCMS has additional roles not covered in this article. These roles provide layers of security for business users as well as workflow. They may also provide levels of security for external users and collaborative portals.

MCMS roles include Author, Editor, Moderator, Channel Manager, Resource Manager, and Template Designer. These roles largely determine how business users contribute content and are important in determining both who can post what where and the workflow involved in making content public. Authors can create, edit, and submit pages into the workflow process. They can also delete pages they own. When posting content, they are constrained to using templates from template galleries to which they have rights and to using resources from resource galleries to which they have rights. Editors have all the rights of authors, with several important additions. They can approve and decline postings, make edits, and submit and delete postings regardless of ownership. They must also have rights to the template and resource galleries for postings that they are approving or declining. Moderators have all of the rights of editors, with several important additions. They approve all structural changes to a site, including new postings, channels, and posting publishing parameters.

Channel Managers are mini-Administrators. They have all the same rights as an Administrator from the point in the Channels, Resource Galleries, and Template Galleries structures that they have been given permission. This has the practical consequence of putting control of business user rights in the hands of a business user who knows who should have access to what, rather than an Administrator who is usually an IT or IS employee with little sense of the business needs of the groups that MCMS serves. In other words, the Web master bottleneck is to a content management system as a network engineer bottleneck is to Channel Manager.

Resource Managers create, replace, and delete resources from resource galleries to which they have rights.

Template Designers have a wide variety of rights that cross several boundaries. They can create channels, resource galleries, and template galleries. They create, edit—including check out, debug, and check-in—and delete templates they own. They assign rights to groups for all MCMS containers (for example, channels, resource galleries, etc.) and they can act as Author, Editor, Moderator, and Resource Manager where they have been given rights. This amount of power is necessary to successfully develop, test, and implement templates.

MCMS Security
Each of the roles described above has a specific set of rights that require no configuration from developers or administrators. Once a user or group has been assigned to a rights group, and the rights group has been granted rights to an MCMS container, the users in that rights group can perform the actions described above.

For example, say you create an Editor rights group call Internet Editors. Then you assign MyDomain\JohnDoe and MyDomain\JaneDoe to that rights group. Finally, you grant the rights group permission to your Internet channel and all subchannels, your Internet resource galleries and all subgalleries, and your Internet template gallery and all subgalleries. This means that John Doe and Jane Doe can perform all of the functions described above for those channels. You can't take away or add functionality without assigning them to a different rights group for a different role.

Note that even though roles groups are groups, it is beneficial to assign security groups (NT groups or AD groups) to rights groups rather than individual users. In this way you can simply change the membership in the security group as employees come and go without needing to edit the right group.

MCMS Workflow
MCMS has a very straightforward workflow with a few minor wrinkles that you should know about. The basic workflow involves an Author creating a posting, an Editor approving the posting, and a Moderator making the final approval for the posting. This is all very serial and simple. Now I'll explain the wrinkles. Moderators only approve structure changes—new postings, posting publication changes, etc. They don't approve edits and deletions of existing postings. If there is no Moderator assigned to a channel, a posting is published as soon as an Editor approves it. This is true vice versa; if there is no Editor, a submitted posting goes right to a Moderator for approval. In addition, if there is no Editor a posting edited by an Author would become published as soon as it is submitted. If there is no Editor or Moderator assigned to a channel, the posting is published immediately upon Author submission.

The workflow model can be extended as there are event sinks that can be programmed against. These event sinks include pre- and postevent sinks. The extensions can be as simple as sending an e-mail notification of workflow events to executing an arbitrary process that can be coded in .NET, which means pretty much anything.

Parallel and multistep serial workflows are two places that require a bit of kludge. For instance, you might need a supervisor and the legal department to review a posting prior to publication. Neither can be a moderator, as they both need to approve everything, even if it is a content change. This can be solved using hidden channels. Essentially, the posting is submitted by an author, moved to a hidden channel, approved by the first Editor group, and then moved back to the publication channel for approval by the second Editor group.

Parallel either-or workflows are handled directly by MCMS, but parallel multiple approver workflows also need to be extended. This can be handled using custom properties—assigning a set of user and tracking whether each has approved or declined.

Given these roles groups and workflows, you can build collaborative portals by capturing defined external users (for example, partners or members) in your AD and then mapping them into appropriate role groups. This way, they can work in secure areas of your Web site and implement appropriate workflow for the content they are tasked to maintain. Additionally, external guest users can be allowed to author content that they are charged for posting. The posting is reviewed for appropriateness and is not approved until it is acceptable and is paid for. This works well for job listings and other similar functionality.