I recently had a call with a customer who had a pretty common requirement. Their content editors work on files on a team site, and they want to have a way to have that content exist on the team site and on their main intranet site as well. Currently the content editors are making the changes in two different places, and they want to streamline this process for efficiency’s sake. They do not want to have to give everyone in the company access to the files where they are being worked on in the team site, and they are hesitant about allowing these content editors to actually edit the intranet site itself.

How can this be accomplished in SharePoint 2013 and Office 365? There are several different options available, with varying degrees of setup complexity, which I will describe in this article, with associated resource links for each.

SharePoint Content Deployment feature

This is a feature that you can activate. You would have a content site collection which is where users author files, and then the target site collection where you want the content deployed to. Out of the box, this is pretty limited in that it will deploy an entire site collection or all the sites under a certain site collection. This is a job that you would schedule to run at certain times. Content Deployment also entails quite a bit of configuration on the server side by your server administrator. Depending on your method of authentication and whether you have HTTPS, this can be fairly complicated. As far as the end users are concerned, they are editing and working on content in one location, and it automatically gets pushed to the other location at the interval you’ve determined. This is a great blog post that I came across that describes the process including an approval portion in the middle. This feature is not available in Office 365. Most of the content on Microsoft’s site and on blogs is written for SharePoint 2010, because in 2013, cross-site publishing is a new feature for achieving this same type of result.

http://www.denisstadler.com/sharepoint-2010/sharepoint-2010-publishing-feature/a-simple-web-content-management-how-to-authoring-approval-publishing/

Cross-site publishing

The concept of cross-site publishing allows you to have an authoring site collection and a target site collection just like content deployment. Unlike content deployment, a great functionality is that it utilizes your managed metadata structure. The people who are authoring content are adding items to a simple list and categorizing them. In the target site collection, navigation is automatically generated based on your managed metadata structure, and the items that the authors wrote will end up displaying on the page of whichever category that they assigned that item. One negative that jumps out at me is that although this feature makes heavy use of the Content Search web part which is awesome, this web part has limited out-of-box display choices. You would almost definitely need to elicit the help of a branding person in order to get that content to display in a pretty way. You can deem a list or library where you author content as a catalog, and then define what field you are going to use to categorize each item in that list or library. This feature makes it nice and simple for the content authors, because they just to a list of there their announcements or articles are, whatever the content is, enter their data, and as long as they categorize it correctly, it will display in the right place in the target site collection. They don’t ever have to edit actual pages in a page library. Benjamin Niaulin wrote a great post which simplifies this whole process and walks you through setting up some simple cross-site publishing for company announcements. http://en.share-gate.com/blog/migrate-sharepoint-2013-what-is-product-catalog

This is a great post letting you know when to use content deployment versus cross-site publishing: http://blogs.technet.com/b/tothesharepoint/archive/2013/07/23/3585007.aspx

The Content Organizer

As we go through each of these options, they exponentially easier to use and set up. The content organizer is a great way to automatically route documents based on conditions and rules that you set up. This is another way to allow people to author content and not necessarily directly edit the location where the content will end up where it is consumed by the content readers. Unfortunately, content organizer rules cannot apply to pages in a page library, though. They cannot be used for list items, either. The content has to be a file in a library. Another negative is that there isn’t really a good way to see what’s been happening, from a reporting standpoint. There’s no way to look at a library and be able to tell which files have been sent to that other location, especially if they’re just sending a copy. If you had a large number of files, you’d end up having to somehow compare the set of files in the source location to the files that are in the destination location.

There are a three main ways these content organizer rules can be used:

1. Users can have a single drop-off location where they upload or save documents, and then from there, documents automatically get sorted and placed in the correct library and folder according to metadata and the rules you’ve defined.
2. Users can use a custom send to location which will appear on the Files tab in the ribbon when a document is selected. This Send To drop-down box will give them options as to where they would like to send the file, such as an archive or an intranet site where the content could be read by a broader audience. When these Send To locations are defined on the server, the administrator chooses one of three actions for that file. The options are to Copy, Move, or Move and leave a link.
3. Information management policies can be created, which will automatically move files to the destination location based on a certain date field. For example, when the date of the last file modification plus one year arrives, the file could automatically be moved to an archive location.

Here are some reference links on the content organizer:

http://office.microsoft.com/en-us/sharepoint-server-help/configure-the-content-organizer-to-route-documents-HA102772938.aspx

https://www.youtube.com/watch?v=JLNVwhy7JiU&index=33&list=PLkxSkUuLZ3fTmkn0BP8L0nPtSz3TzETl0

Custom “Send To” Location

The custom send to location is similar to #2 in the content organizer rules above, but even easier. Also, it does not require access to Central Administration or even Site Settings to get it configured. This is functionality that you can set up that allows one library one specific location to send a copy of files to. This only exists for files in a library, and not list items. When the user selects to send a file to this location, they are prompted to choose whether they want the original file author to be prompted to send future updates to the copy of the file, each time it is checked in. They also have the option to allow it to create an alert on that document so that they will know when it changes and potentially needs to have an update sent out to the copy. An example use case of this would be an HR department that has a library on their private team site where they collaborate on documents. They also have an intranet site that everyone in the company can read content. When a file is ready to go public, they would use this Send To location.

After the copy has been sent, the original file location will have a button in the Files tab of the ribbon called Manage Copies, so that they can see a list of where current copies of that file are, and send out updates if needed. The destination location even has a column called Copy Source, where you can view the URL of the location where the file came from.

Publishing Pages Approval

With the simple goal being that the content authors shouldn’t have to author or update identical content in multiple places, there’s good old publishing page approval and out-of-box workflows that could be used. When you create a publishing site, one of the templates is Publishing Site with Workflow (hint for sub-site: choose Use unique permissions in order for it to work correctly). Using this type of site for publishing allows you to have a strict process in place around the editing and publishing of content on the intranet pages.

Again, with this original requirement at the top, how could this functionality be used to accomplish what they want? Content editors would be able to directly edit pages on the intranet site, but when they do this, each page would have to go through an approval workflow before the changes could be approved to go “public”. But what about the fact that they need to be able to get to this content from their team site as well? The Content Search web part is very powerful. One of the things it allows us to do, is display content from one place in your farm… in another place in the farm. The content from the library on the intranet site could be displayed in a web part on the team site. They’re editing it in one place, the intranet site, but they can get to it from a couple of places. If they did the opposite, if they only edited the files on the private collaboration site and tried to display them on the intranet site, they would have to give everyone in the company access to that library’s content on their private site. This was not an option.

As you can see, there are many different options, with varying pros and cons. There are several factors to consider when deciding which route to go. Some factors are: What is the content we’re dealing with? Items? Pages? Library files? Can content editors be allowed to work on the intranet pages directly? What is the quantity of content we’re dealing with? Does there need to be visibility into which content has been published, by whom and when? To get started, I definitely recommend testing out each of these options, and experiencing them from the content author perspective and the end user (content reader) perspective, in order to make an informed decision.