Why Can't You Add Some Custom Attributes as Columns in Intercom's Report Drilldowns?

Because Intercom's report drilldowns only let you add columns from a fixed list of fields per dataset, and that list doesn't automatically grow to match every custom attribute you've created. Sean Meade, an Intercom support lead, confirmed this directly on the community forum: "Not every attribute shows up in reports because reports only support a limited set of fields today, and that list can vary depending on the report you're looking at." It isn't a permissions issue, a setting you missed, or a bug. It's a product limitation Intercom has acknowledged and hasn't fully closed.

The gap isn't even limited to attributes you built yourself. Intercom's own guide to building a custom report gives a standard, non-custom example: "Email domain is a default contact attribute in Intercom and appears on contact profiles, but it is not available as a filter or breakdown option in custom reports." If a field Intercom ships out of the box can be excluded from reporting, a custom attribute your team added last quarter is not guaranteed a slot either.

What's locked, and what isn't

Intercom's reporting metrics & attributes reference lays out the actual shape of the system: each dataset (Conversations, Tickets, Calls, and so on) ships with its own fixed set of standard attributes, sorted into categories like conversation state and channel, timestamps, teammate and team activity, and people and company basics. That's the menu you're building reports from, and notably, that reference page doesn't mention custom attributes at all. Intercom hasn't published a rule for which custom attributes clear the bar into a given dataset's column list and which don't; what's documented is only the boundary, not the mechanism behind it. In practice, a custom field can sit on the contact or conversation record and still never surface in the "add column" or "view by" picker, and Intercom's own material doesn't say why some fields make the cut and others don't.

There's a second, related wall worth knowing about even though it's not the same problem: if you do get an attribute into a report's breakdown and that attribute has more than 10,000 distinct values, Intercom's troubleshooting guide says the chart fails outright with an error, not a truncated or grouped result. High-cardinality fields (a free-text company ID, say) can be visible in the picker and still unusable as a grouping once your data grows into it.

Where this shows up in practice

Take a usage-based billing product that tags every Intercom conversation with a renewal_risk custom attribute (low, medium, high), so the account team can see which support threads touch accounts close to churning. The attribute lives on every contact record and is already used in Workflows to route conversations.

The support lead there wanted a report breaking conversation volume down by renewal_risk, to show which risk tier was generating the most tickets that month. renewal_risk wasn't in the "add column" list when the report opened, so she asked Intercom's account team directly. The answer: that field isn't in the current set for the Conversations report, there's no timeline to add it, and the best option today is exporting the raw dataset and building the breakdown outside Intercom.

That's not a missing checkbox. renewal_risk exists on every contact, it drives routing logic elsewhere in the product, and it still isn't one of the fields the Conversations report can group by. It's the same answer Sean Meade gave the forum thread above: a fixed field list, and export as the workaround.

The export workaround, and its own edges

Intercom's suggested fix is real and it works, up to a point. CSV export covers "full attribute coverage" across the metrics and attributes Intercom documents, which is a wider net than the report drilldown's column picker. That's genuinely useful: the support lead above can export raw conversation data with renewal_risk attached and pivot it in a spreadsheet.

It comes with its own limits, though:

• Message content is excluded. The export is metadata (IDs, timestamps, attributes, metrics), not conversation text. For that you need the Conversations API or a cloud storage export.
• 10,000 rows per direct download. Larger pulls get emailed instead, with up to an hour of processing.
• Two years of history. Older conversations aren't in the export at all.
• Two separate permissions required, chart drill-in access and CSV export access, so it's not something every teammate can do on their own.

For a one-off monthly pivot, that's a fine trade. For a team that wants renewal_risk, plan tier, and CSAT sliced together every week, it turns into someone's recurring spreadsheet job, rebuilt by hand each time the underlying data changes.

Three ways the export pivot breaks down

The export path holds up as long as one person is willing to own the pivot and the question stays inside Intercom's own data:

• The attribute you actually want to slice by lives somewhere else, a Salesforce field, a Slack thread, a Linear priority, and joining it to Intercom's export means a second export and a manual VLOOKUP.
• Nobody owns the recurring pull, so the report quietly stops updating a few months after the person who built it moves on.
• The question shifts from "how many conversations" to "which accounts," and the two-year window or the 10,000-row cap starts cutting off exactly the older or larger dataset you need.

That's the point where a fixed report schema stops being a UI quirk and starts being an actual ceiling on what you can ask. This is the category we build for. Modem reads Intercom conversations through the Intercom integration alongside Slack, GitHub, and whatever else your team already runs, and it doesn't box attributes into a curated per-dataset field list, because it isn't building a chart from Intercom's own reporting engine, it's building a context graph from the conversations themselves. A tag like renewal_risk, a company's plan tier, and a person's role all end up queryable together, without waiting for Intercom to add a field to a picker. Modem is our product, so read that suggestion knowing where it's coming from. If tags are the whole system you need, how to track feature requests in Intercom covers running that setup well inside Intercom's native tools, no export required.

If the friction you're hitting is closer to Intercom's object model than its reporting engine (tickets and conversations behaving like separate things when you try to report on them together), that's a different fixed boundary, covered in why Intercom splits tickets and conversations into separate objects.

Matching the fix to the question

If your reporting question is "how many conversations have this one tag," the drilldown probably already supports it; check the field list before assuming it's missing. If the field you need isn't there and the report is a once-a-month check, export and pivot, budgeting for the row cap and the two-year window. Reach for something built to sit on top of Intercom's data, rather than inside its reporting schema, once the pivot needs a second data source or a person to keep re-running it by hand.