Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Is it possible to replicate same page or document in multiple locations in a site?

  Asked By: Rachelle    Date: Jan 30    Category: Sharepoint    Views: 3153

I have products that are sold under two or more different business units, and I need to be able to replicate the product page to each business unit's location in the site, yet remain able to edit it from any of its locations.

What if any, is the best way to accomplish this?



2 Answers Found

Answer #1    Answered By: Mariel Ferrell     Answered On: Jan 30

A key concept for SharePoint is the concept of taxonomy, or site  organization. One of the big benefits of SharePoint is that it's possible to organize information in more than one way. I like to give people this example:

Say you have a folder in your "My Documents" folder on your hard drive, and it's called "Projects". Inside your "Projects" folder, you have a bunch of folders, each named for a name of a project. Inside each of those folders you have all the documents relating to a project, such as a project plan, status reports, etc. One day, your co-worker says, "Hey, I need the project plan for Project XYZ." You're in a hurry so you give her access to view your "My Documents" folder over the network. Pretty soon you have her calling, "Hey! Where's your 'Project Plans' folder?" She's asking that because on her computer, she doesn't have a folder for each project; instead, she has a folder for each type of document.

This example is just to show that there are multiple  ways of sorting or grouping the same information. What if it were possible to view the same information, but grouped in different ways? What if you could see all your project documents at once, but your coworker could view all the project plans at once? The key is that where a document  sits logically describes it in some way, but that's not the only way to describe it. It could also be "tagged" so that all the items tagged with the same tag can be grouped together.

In SharePoint, this is done with something called Site Columns. A site column is a piece of metadata that can be used to describe your page. The thing to wrap your mind around is the fact that on a file system, where a file sits is what gives it meaning, (i.e. "It's in my Projects folder so it's a project.") In SharePoint, you can have a single "Product" page, but you could simply tag it as being carried by one or more locations. The location  of the product  becomes metadata describing the product.

So, instead of having a web site for each location, and having a product page  inside that unit's site, think of this scenario: you've got a site for each unit, but you've also got a common site for all your product pages. You tag each product page with the unit or units that carry that product. On your unit site's homepage, you use a web part called the Content Query Web Part to retrieve all the pages in your "Products" site that have been tagged with that unit's name.

This can be a big change from how traditional web sites are built, but if you can start thinking in this way, your sites become very flexible, and you can start showing different kinds of views of the same information - views which might be pertinent to different kinds of people (such as employees vs. consumers vs. business  partners, etc.)

Answer #2    Answered By: Santana Osborn     Answered On: Jan 30

I agree with Becky's description on an approach to this problem. I usually refer to this type of content in terms of having a "physical location" where you actually created it within SharePoint, and virtual "publishing locations" where you've instructed it to show up by using meta-data. I will add that, when I've implemented similar solutions, it usually snowballs into affecting a few other things. Specifically:

When user's search for content, and a result comes back. Should it link them to the actual storage location  of the content, or should it have a link to each "published" location and hide the physical location completely? You may need to customize the search results XSLT to make this change.
If you need to factor the "published" locations into the navigation of the site, you might need to roll a custom SiteMapProvider that looks at the meta-data to build the navigation using the virtual "published" locations instead of the physical location of the content.
What level you go to really depends on how important it is to hide the actual location of the content from the end user.