Don’t let how you’re going to consume data influence how you going to manage data! There are many reasons for keeping subsites, libraries, and lists as containers to organize data. Generally, these relate to security and who’s managing them. The simpler you make it for management means the less that can go wrong. That’s where this post will focus – how to surface or show data contained in subsites within a parent site.

How to Use it

Start with your information architecture plan. That is the relationship of subsites to parent sites and where the data will actually live in the managed versus where you want to show the data. This is your design process.

Eventually you get around to the mechanics of developing it which in this case means configuring the CQWP.

Steps:

1. Start Internet Explorer and type the URL for your organization’s SharePoint server. The Start page will open.
2. Navigate to the site where you want to add the Content Query Web Part.
3. Click the Page tab and select the Edit Page button. The Page ribbon will appear and the page will open in Edit Mode.

Figure 1: The Page Ribbon and Page in Edit Mode

1. Select a zone and click Add a Web Part. The Add Web Parts header will open.
2. Select the Content Rollup folder and then click the Content Query Web Part. The Web Part will be selected.
3. Click Add. The Add Web Parts header will close and the new Web Part will appear in the selected zone.
4. Click the open the tool pane link. The tool pane for the Content Query Web Part will appear.

Figure 2: The Content Query Web Part Tool Pane

1. Click the Query expand control to expand the section, then click the Show items from the following site and all subsites option.
2. In the adjacent URL field enter the URL for the site.
3. Continue to fill out the remainder of the Content Query tool pane as desired.

Click OK. The Content Query Web Part Tool Pane will close and the new Web Part will be visible on the page.

Building the Query

Let’s walk through an example. For an article relating to preschools, the Managed Metadata fields would include related topics, such as “babies,” “childcare,” and “early childhood education.” In your article page layout, you could then have a section with the category tags (in this case, “Preschools”), and another that shows articles with similar or matching tags- your CQWP.

Best practices

One of the best parts about CQWP is the ability to display queried content on a page; however, most people will want to avoid having to create a new CQWP every time they post new content. To prevent that, you want to create a custom Managed Metadata field for each category of content. These Managed Metadata fields will let you link to the term store, which will create a list of categories for the content creators to choose from. You can also add other fields that will allow queries to be more specific and useful, with the PageFieldValue and PageQueryString tokens to your Managed Metadata. An excellent Best Practice for developing a functional CQWP is to work with the content creators to plan the categories they will primarily be using. By generating a list of potential content topics, you will be able to build the CQWP more easily and save everyone time in the long run.

Hidden gotchas

Content Query Web Part (CQWP) will security-trim search results, so users only see items they are entitled to view. Also, if you cast your net too wide, it will be slow. Plan carefully so you don’t create a query that is so large it can bog down your system.