Custom Controls in IBM Cognos Analytics with AI - Part II

Part II: Inside the Hover Detail Control

From Idea to Production in 16 Hours

In Part One, we showed how AI collaboration made Cognos Analytics custom controls practical to build. This post covers how we built one: a hover control that shows a filtered detail report for any cell in a list or crosstab.

We solved three problems: finding the cell, passing the filter, and making the control reusable.

Problem 1: Knowing Which Cell, the User Means

Cognos does not tell a custom control which cell is under the mouse, so we read the rendered report itself. Using browser inspection, we found that Cognos tags every cell with a specname attribute that names its role.

• Lists: body cells are listColumnBody. The control matches each header (listColumnTitle) to a configured column name, then reads the hovered row's values by position.
• Crosstabs: value cells are crosstabIntersection, and each carries a ctx attribute such as 6::5::2. The middle segment points to the matching row header, which gives us the row's member name.
• Column routing: different columns can open different detail reports. Columns not listed fall back to the default.
• User control: an on/off toggle lets users turn hover detail off, and defaultEnabled sets where it starts.
• Fine tuning: popup size, hover delay, and colors are all settings, not code changes.
• A setting that blocked loading. One report attribute (uiType="withEventPropagation") silently stopped the control from loading in Cognos 12. Removing it fixed the problem.
• Timing. Cognos 12 finishes drawing reports later than 11.x did, so the control waits briefly before looking for cells.
• False alarms. Some errors came from browser developer tools interrupting Cognos, not from the control. Separating platform behavior from real defects saves hours.

One technique covers both report types, and it is anchored to attributes Cognos actually renders, not to guesses about layout.

Problem 2: Passing the Filter in Cognos 12.1

The classic way to pass a value to a report URL (p_Account=value) did not work reliably in Cognos 12.1. The detailed report would open, but unfiltered.

The fix was the promptParameters argument, which takes a small JSON list of parameter names and values:

/bi/?pathRef=/content/.../AccountDetail&prompt=false&action=run
&promptParameters=[{"name":"p_Account","value":{"use":"12345"}}]

The control builds this URL on each hover and loads it in a popup frame. The detailed report runs with Cognos's normal security and data access, so nothing is bypassed.

Problem 3: Build Once, Reuse Everywhere

All behavior lives in a JSON block that a report author passes into the control. Adding hover detail to a new report takes minutes and no code.

{
"cognosServer": "https://yourserver/ibmcognos",
"targetReportPathRef": "/content/folder/DefaultDetail",
"contextMappings": [
{ "sourceColumn": "Account", "targetParameter": "p_Account" }
],
"columnReports": [
{ "sourceColumn": "PI",
"targetReportPathRef": "/content/folder/PIDetail",
"targetParameter": "p_PI" }
],
"defaultEnabled": true
}

What the AI Collaboration Looked Like

The work was a fast loop: build, deploy to Cognos, test, find the root cause, fix. AI sped up every step, but the Cognos expertise decided which answers were right. Three examples:

The Takeaway

The control is ready for production on Cognos Analytics 12.1, and the same approach powers other controls we have built, such as coordinated filters with a single Clear All button. Your Cognos platform can do more than it ships with. The work to unlock that is now hours, not months.