IBM Report Builder is a powerful tool for turning raw data into meaningful insights—but getting the most out of it often requires more than just knowing the basics. Whether you’re new to report creation or an experienced user looking to streamline your workflow, the right tips and tricks can make a noticeable difference in both efficiency and report quality. In this article, we’ll explore practical techniques to help you build clearer, faster, and more effective reports in IBM Report Builder, from optimizing queries and layouts to avoiding common pitfalls and improving performance.

This article will be regularly updated to provide you with more tips in the future, if you find anything missing or something that doesn’t work in your environment as described in this article, do not hesitate to contact us at info@softacus.com.  

When starting a project in IBM Engineering Lifecycle Management (ELM), users and administrators naturally focus on process configuration - artifact types, attributes, data types and enumeration values and link types. One critical aspect that is often overlooked—but has long-term consequences for reporting and data quality—is the early definition of URI addresses for project properties.

1.) DOORS Next Properties URI 

Why URIs Matter in IBM ELM

Requirements project templates are the bread and butter of effective requirements management as they provide an outline of the requirements needed to execute a project, including purpose, scope, features, tasks, deliverables, and milestones. Utilizing them can also lead to an increased trust from the stakeholders, as there is less of a chance of a mistake happening when requirements are outlined and clear to the people working on the project.

If properties are created multiple times with the same or similar display names but different URIs, ELM treats them as entirely separate fields—even if, from a user perspective, they appear identical.

The Cost of Not Planning Ahead

Not defining and reusing the URIs in various projects and components (if the properties match) can lead to a various issues, including:

• Duplicated properties in reports - Report Builder “Choose data” tab can include the same property several times making it harder for the user to choose the correct properties for the report. Duplicated properties are usually marked with exclamation marks - there is an information about from which project the property was gathered, but in case of the same project, but different components this might be quite tricky to select the correct one.

2.) Duplicated properties in Report Builder 

• Incomplete or misleading analytics - data spread across multiple URIs cannot be easily aggregated, resulting in charts and metrics that underrepresent the true state of the project. 

• Increased reporting complexity - report authors must handle multiple properties manually, adding filters or unions that complicate queries and reduce maintainability. 

• Costly clean-up later - merging and cleaning up the properties after artifacts already exist is time-consuming and often disruptive to end users. At the same time there might be a baseline already existing where you cannot do anything with already existing properties. 

Defining Property URIs Early: A Best Practice

Configure once, report consistently, and avoid duplication before it starts. This is especially important in large programs or regulated environments, where cross-project reporting and historical trend analysis are essential. 

Configure once, report consistently, and avoid duplication before it starts. This is especially important in large programs or regulated environments, where cross-project reporting and historical trend analysis are essential. 

If you already worked in DOORS Next, you discovered that every artifact you create in a module automatically gets its own “base” artifact - artifact created in a module folder that can be used in other specifications and thus the user can reuse the same artifact several times and synchronize the changes in specifications for the specific artifact in all of them.

In DOORS Next, this is not a problem - when you open a module, you see only one “copy” of this artifact. The same is with a folder and other modules containing the same artifact. But how does the reporting handle that?

In reporting every object is considered as a separated artifact, it doesn't matter if content, ID or any other attribute is the same, the only thing which matters is the URI of the object which is unique even for every copy of the reused artifact.

Imagine the situation where you created 10 system requirements in an empty project and you would like to check if the reporting is working, so you go to the report builder, select the option to create a report and simply select your project and System Requirement from the list of available artifact types. You don’t care about the attributes, so you simply go directly to run report step and run the report, but in the table you received 20 (or even 30 or more if the requirements are being reused in several specifications) system requirements instead of 10. Where did I make a mistake? Is the report builder working correctly? Finding the answers to these questions can be frustrating and time consuming, but the simple answer is - don’t worry, everything works well and you just need to separate your base artifacts from the module ones. How to do it? There are two options that you can use and we will show you both of them!

Using Trace Relationships

The first option you can use in order to filter out module/base artifacts is to use the relationships between the module and artifact type. Again there is a difference between this relationship in DOORS Next and Report Builder, because in DOORS Next this relationship doesn’t act like a normal OSLC relationship between two objects. All you can see in your DOORS Next project/components and modules is the attribute called Used in modules - which is again, not a classic attribute showing you the link/modules where the artifact is reused, but only an icon showing you if the artifact is being reused in other modules that the user can hover over and see also a clickable name to the module(s) (if artifact is reused).

3.) Artifact Used in Attribute

For the same purpose you can use the section “Where Artifact Used” in the selected artifact panel, on the right side of the UI (if artifact is selected). In this section the users can directly see the module ID and Name (with clickable link) of the module(s) that are containing the selected artifact. 

4.) Where Artifact Used section

This “invisible” relationship can be used in report builder to actually gather only base or module artifacts. All you need to do is to: 

1. Select the artifact type from the “Choose an artifact” section (if you want module artifacts, best would be to select the module artifact type, e.g. System Specification) 
2. In the “Trace relationships and add artifacts” section find and add relationship “Uses” (if you selected module artifact type before) or “Used by” (if you selected textual artifact type) 

By default the relationship ship should be set to “required” which means that report will return only the module artifacts in the result. 

5.) Module artifact type uses textual artifact type relationship 

6.) Textual artifact type used in module artifact type relationship 

With this option, the users are able to set up the conditions for the module artifact type and thus, to specify (select) the specification (module) from which they would like to gather the requirements for the report - see the next section.

If you would like to report against the base artifacts instead of module ones, you can set the relationship field to “Does not exist”. In this case the user have to select textual artifact type in the “Choose an artifact” section, since starting with module artifact type and setting “Uses” relationship to “Does not exist” will basically ignore the textual artifacts and will not allow the users to first of all create any conditions for the textual artifact type, to display any of the attributes for this type and most important, the results will not include any textual requirements.

7.) Textual artifact type used in module artifact type "does not exist" relationship 

Using Conditions for Artifact URL

The second option doesn’t require the user to set up the trace relationships in between the module and textual artifact types, but instead it will use the URL of an artifact. In DOORS Next, the base artifact and module artifact URL vary, which allows the users of Report Builder to simply separate the base from module artifacts in their reports, using very simple conditions. Before we dive into the example, please keep in mind that with this option (if you are not using trace relationships between module-textual artifacts) you won’t be able to filter for a specific module/specification, since we will use only textual artifact type in here and also, if your artifacts are being reused, you can still discover, that your results are not accurate as you need them to be. 

So, for this way of filtering, it’s pretty straight forward - in Choose an artifact section, you can select the textual artifact type you want to have in the result (if needed you can add also other textual artifact types in trace relationships and add artifacts section) and afterwards, in the “Add condition” section, you can create a condition for textual artifact type’s URL. Why for the URL? Because as mentioned at the beginning the URLs of the base and module artifacts vary in a specific way - usually the URLs are starting with two letters, and those two letters are usually different for module and base artifacts, see example below:

To get the URL of the artifact you can easily right click on the artifact and select the option “Share Link to Artifact…”. The first two letter after “/resource/” are the letters that are different for base and module artifact, so you can use them as the filtering in the report builder condition, see example below:

Once done, you can save and run your report to check if the results are matching with the data you have in your DOORS Next Project.

Mastering IBM Report Builder goes far beyond creating basic reports—it’s about leveraging advanced techniques to turn raw data into meaningful, actionable insights. By applying the tips and tricks discussed in this article, you can significantly enhance both the efficiency and impact of your reports.

As reporting needs evolve, continuous experimentation and refinement are key. IBM Report Builder offers a flexible and powerful platform, and staying curious about its advanced capabilities will help you build reports that are not only accurate, but also scalable and easy to maintain. Whether you’re supporting business decision-making or technical analysis, these advanced practices can help you unlock the full potential of your reporting environment.

Mastering IBM Report Builder goes far beyond creating basic reports—it’s about leveraging advanced techniques to turn raw data into meaningful, actionable insights. By applying the tips and tricks discussed in this article, you can significantly enhance both the efficiency and impact of your reports.

We, in Softacus, are experts when it comes to consulting and service delivery of IBM software products and solutions in your business. We help our clients to improve visibility and transparency when licensing and managing commercial software, providing measurable value while increasing efficiency and accountability and we are providing services in different areas (see Softacus Services).

The IBM ELM extensions developed by Softacus are free of charge for the customers who ordered IBM ELM licenses via Softacus or for the customers who ordered any of our services. If you are interested in any of our IBM ELM extensions, you found a bug or you have any enhancement request, please let us know at info@softacus.com.