Though output channels can be as diverse as Twitter, a video distribution service, or product catalog production, what is common when routing content to output channels is the workflow considerations through which content must traverse before it is published.

Unlike moving content between internal business systems, moving content from, say, your PIM to your Facebook account, can move markets, perhaps unintentionally.

Before getting into the content considerations of publishing to channels, consider some of the more common output channels:

• Social media (Twitter, Instagram, Facebook, etc.)
• Video distribution (Brightcove, YouTube, Vimeo, Kaltura, etc.)
• Microsites (custom developed additions to corporate or partner website properties)
• Printed production services (books, catalogs, brochures, fliers, etc.)

The requirements and considerations of these diverse channels can greatly affect how content should be managed before it is published through them.

An extreme and obvious example is that an announcement crafted for Twitter is not suitable for publication into book form. But there are many less obvious examples that should be governed by policy and common sense.

The goal is to ensure that what gets published is:
Complete and correct

• Suitable for the chosen output channel
• Approved for publication by an authorized source
• Ready for publication

Content is complete and correct

At the core of all content publishing is making sure the content is complete and correct. As a concept, this is pretty fundamental. The concern is when you have hundreds of people making publishing decisions, and you have millions of pieces of content, it is important that “complete and correct” be clearly indicated in the content system.

Ideally, statuses like this should be so obvious that anyone can see them, without having to know where to look or what to look for. There are certain things you do not want to rely on user training to make known, and publication status is one of those things.

Metadata controls make changing status easy enough, but also make sure that the status itself is clearly visible to anyone who views the content record. It is not enough for a small field to be set to “Do Not Publish,” if that field is not obvious.

In most cases, a status like this will require approval from a content authority. Keep in mind, this is not necessarily the same authority who will approve the content for publication. At this point, your concern is only whether the content is correct and complete, even if it should not be published for another year.

Content is suitable for the chosen output channel

The next consideration is whether the content is suitable for the chosen output channel. Obvious considerations are that you do not send a spreadsheet to YouTube. But even within suitable content types there can be unsuitable content.

Image formats are one such consideration: After a designer creates the movie poster for your next blockbuster film, there will likely be a very large Photoshop master file. This is not the content version you would share to social media. Instead, you would share a (much) smaller PNG or JPEG version of the master. If your content system can create this for you, all the better; if not, someone will need to create it manually, or an upstream integrated system must create it.

Even when a given format could be published via the selected channel, you might not want that to happen.

For example, when you publish a PowerPoint slide deck, you provide an editable file. Anyone can download that file, edit it, and perhaps upload or share it again. You might like what they added, but you might not. Instead, publishing a slide deck as a PDF file can ensure the content is distributed in a non-editable or less easily edited format. No matter where it is reshared, you will be more certain that is it the content you originally published.

Define within your content management policies which content formats are suitable for which output channel you will use. If a suitable format is unavailable, make clear to the user how to inquire about getting the content in a suitable format. This might be as simple as a directive in the content record that reads, “To get this content in other formats, contact …”

To improve the user experience further, make clear in your content systems which formats are available. Even better, provide an “easy” sharing option through which users can think in terms of “I want to share this to Facebook” rather than “I need this in JPG format.”

Content has been approved for publication by an authorized source

Unlike a content editor/approver, who might look for typos or other mistakes, some authorized source must conclude that a given piece of content may be published. A given tweet might be less than 140 characters and contain no errors, but that does not mean the content of the tweet should be released.

In some cases, the content approver will be the same person as the publication authority; but this should be clearly defined for each content type.

Further, your content system should make publication impossible until the required approvals have come in. This can be made possible by providing a metadata field (such as a checkbox) that is accessible only to authorized approvers. When the box is checked, the system and its users know the approval was real. If the box is unchecked, the system knows to not route the content to any output channel.

Improve the user experience by making it clear to users why a given piece of content cannot be published. This will help them understand the rules, and it will reduce support requests asking why they cannot publish something. Consider shielding sensitive, non-approved content from such users via permissions.

Keep in mind that resourceful users might discover that they can download and publish content manually, even when the “publish” controls in the content system do not permit them to do so. This would possible when the user has download rights even for content that is not approved for publication. This is a very likely scenario. If users do not understand the policy, they might think they are merely overcoming a glitch in the system by circumventing it.

Content is ready for publication

Content can be complete and correct, available in a suitable format, approved for publication and still not be ready for publication. A press release that is under embargo is one example; next week’s quarterly results report is another.

By making “ready for publication” its own attribute, you can save approval authorities from withholding approvals. For example, someone charged with approving that quarterly report might fear that if she approves it, it will go out too soon. Instead, she will make a note for herself to approve it next week, and then be out sick on the day it is needed.

But if the “ready for publication” policy is clear, and clearly indicated on the content record, such as showing an embargo date, the approver knows that her approval is conditional upon all required considerations being met.

Considerations like “ready” are typically rules based. While the indication can be communicated via a metadata field, as is the case with the approval, the authority of the “ready” status might be a rule that the content system can evaluate.

For example:

The content must be marked complete and correct by a user in the Editor role AND
The content must be available in a format suitable for publication AND
The content must be approved by a user in the Manager role AND
The Embargo Date field must be empty or include a date in the past.

When all these conditions are met, the content system marks the content “ready for publication.”

You will likely have different rules that apply to different content types. This is yet another reason why thinking of content in terms of content types make content management easier.