Managing fine grain process customization for work items in RTC 4.0.1

From some time I wanted to try the new Project Process Sharing feature called “Fine-grained Customization of Configuration Data”. This feature provides great flexibility in how process consuming project areas can tailor the inherited process configuration data section. The feature main documentation wiki page can be found here.

While more customization possibilities will come in the future, the supported customizations in RTC 4.0.1 documented in the wiki page supported customizations section, already provide a set of cases I usually find working with customers. In this post I am going to model a simple typical scenario and, based on the  Delta Configuration Examples page, document my steps.


Project Process Sharing is a great feature that allows an organization to keep a consistent process specification across different projects. It leverages getting the process definition from a central managed project area, and to pick up process changes automatically. This feature for standardization still allows individual projects to perform some customization of the inherited process to accommodate individual process particularities. A good introductory tutorial can be found here.

Along with permissions and roles, Configuration Data can also be customized in the individual projects. This process data contains, among others, the information for work item types. The granularity of changes management for the process Configuration Data made sometimes difficult to achieve the customization needs for work items; which is usually the most common area of process customization: a complete explanation can be found in the article called Work Item Configuration and Shared Process in Rational Team Concert.

A sample scenario

The scenario I will use for trying the feature, will consider a project area that contains the process “master” definition, and two children project areas that consume the process. To easily illustrate the example, I will use the JKE Banking sample process as the master with two fictitious department project areas.


Following the wiki page information and examples provided, I will model the most typical case of adding an attribute to existing work item type: my project needs an additional attribute for information that is only relevant for us.

After performing the change using the new feature, I will check that no sharing is broken due to this change.

How to use the feature

Extending the children project areas with the desired process customization is currently achieved by directly adding content to the projects’ Process Configuration Source. You will add XML process fragments that define the customized piece of process data. The complete syntax information can be found in the wiki page called Syntax for Configuration Data Delta, but the main elements of the XML process can be summarized as follows (click to enlarge):


Some tips to keep in mind from the previous snippet:

  • The “configuration-data-id” attribute specifies which process configuration section you are customizing. There is a different section for work item types and attributes, workflows, …
  • The “path” element is optional and will allow you to specify an expression to navigate in the process XML to locate the element where we want to add content (similar to an XPath to position in the desired XML process element). If not specified, it is assumed that the the new content will be added as children of the configuration data element itself.
  • add-element” tag denotes that we are adding a XML process fragment. At the time of this writing just adding content was possible.
  • Children of the “addition” element is the relevant XML we want our process to be augmented with

Customizing the projects’ process

Let’s get back to the scenario …

Department X: needs a new attribute

In this scenario, the department is using the process definition from the parent JKE Banking project area, but they need to add a string based attribute to the Defect work item type to reflect departmental tracking information they internally use.

Let’s assume the attribute the department wants would be of type “smallString”, and they want to give it an ID of “”.

First we have to define the chunk of XML process that will add a new attribute to the work item type. This attribute addition is based on defining the attribute itself, and adding it to the proper work item type category, therefore there is some information we have to gather:

  1. Process data element to extend: we have to add content to the xml process element with ID “” which is the one that defines the Work Item Types and Attributes.
  2. Process elements to contribute: for the attribute creation, we’ll need to create our XML element nodes of “attributeDefinition” for the actual attribute type creation, and “customAttribute” to add the attribute to the work item type category (in this example to the Defect work item type category).
  3. Identify the work item type category: the one we will reference is “”, this can be located looking at the Project Process Configuration Source or in the Types and Attributes node of the project configuration wizard:


To this point, we have all the information we need to build a portion of XML that will add the custom attribute (click to enlarge):


Now that we would have the attribute added to the work item, we want to add a presentation for it. The steps to follow are the same as we have done for the attribute type, but with the following considerations:

  1. The process data element to extend is the one with the ID ““.
  2. We want to add the presentation to the Details section, on the Overview tab, This section has the process element ID of ““.


With this information, an XML process fragment that will contribute a presentation to the newly created attribute can be of the form of:


Some important points to consider from this snippet:

  • A “path” element is used to locate the XML process element to which we want to contribute the fragment. This is due to the fact that the “section” element is not a direct child of the configuration data element we are extending (“”).
  • With the “path” navigation we have also located a certain attribute presentation. The fragment then specifies with the “location” attribute that we want our fragment to be added after that attribute presentation in the XML process.

For this attribute and attribute presentation customization to be realized, we have to add the “configuration-data-delta” XML fragments to the Project X Process Configuration Source within “<data>…</data>” elements. The process will look like the following:


See it in action

Creating a Defect work item in the Dept X project area we will see the following:

defectDeptXBut for a complete test of the feature, let’s add a new attribute to the parent JKE Banking project area process, adding a “Customer” string type attribute to the Defect work item, for instance: this would be performed using the standard UI for creating a new custom attribute and adding it to the work item editor presentation.

Checking how it looks like in both children projects will allows us to see the practical benefits of the new feature:

newProcessAs you can see, in Dept Y the new Customer attribute inherited from the parent process appears, while in Dept X, both appear: the inherited one and the custom added with the process fragments.

With this I finish this post, I hope you find this review useful for your first steps with the new feature. Stay tuned to this work item and linked ones for future additions of functionality to this feature!

You can download the process fragment used in this post from here.


3 thoughts on “Managing fine grain process customization for work items in RTC 4.0.1

    • Hi Madhan,

      currently in the attribute presentation you have some options to hide an attribute: if empty, on work item creation, if not chosen link/association exists or in defined states. Having a look at I have found a similar request as yours that may be of your interest (not your same request, you can fill an enhancement exposing your need):

      I have never tried to do that on an extension, but it would at least required that you code your own attribute presentation and supporting logic for it. Anyway its potential complexity and APIs that would require make it more something to ask and expose on 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s