This past week I finished off a proof of concept project for a client in Manhattan. While implementing the solution, I ran into another shortcoming of MOSS KPIs (see here for a previous KPI issue and my workaround).
Background: We used SharePoint Designer workflow to model a fairly complex multi-month long business process. As it chugged along, it would update some state information in a list. KPIs use this data to do their mojo.
We decided to create a new site each time a new one of these business processes kicks off. Aside from the workflow itself, these sites host several document libraries, use audience targeting and so forth. Just a bunch of stuff to help with collaboration among the internal employees, traveling employees and the client’s participating business partners.
We also wanted to show some KPIs that monitor the overall health of that specific business process as promoted by the workflow state data and viewed using the KPIs.
Finally, we used KPI list items that do a count on a view on a list in the site (as opposed to pulling from another data source, like excel or SQL).
The Problem: As you can imagine, assuming we were to carry the basic idea forward into a production world, we would want a site template. Provision a new site based off a "business process" template.
The problem is that you can’t seem to get a functioning KPI that way. When I create a new site based on a template with a KPI List and KPI web part, the new site’s KPI data are broken. The new site’s KPI list points at whatever source you defined when you first saved it as a template.
By way of example:
- Create a new site and build it to perfection. This site includes the KPI data.
- Save that as a template.
- Create a new site and base if off the template.
- This new site’s KPI list items’ sources point to the site template, not the current site.
The instantiation process does not correct the URL.
I tried to solve this by specifying a relative URL when defining the KPI list item. However, I couldn’t get any variation of that to work.
I always want to pair up these "problem" blog posts with some kind of solution, but in this case I don’t have a good one. The best I can figure is that you need to go in to the newly provisioned site and fix everything manually. The UI makes this even harder because changing the URL of the source list causes a refresh, so you really have to redefine the whole thing from scratch.
If anyone knows a better way to handle this, please post a comment.
</end>
Paul
I haven’t played with it yet, but could the SharePoint Config Store help here?