Dynamic Content Blocks vs. Data Resources: Why the Model Changed

[Dan_Kane]

If you've been building dashboards in ServiceNow for a few years, you've probably built something clever with Dynamic Content Blocks: Custom filter behavior. Context-aware headers. Interactive logic driven by Jelly and JavaScript.

And for a while, that was just how it was done — at least in Core UI. It worked. People shipped it. Some of those dashboards are still running.

But the underlying model had problems — ones that only showed up later, usually when someone else inherited the dashboard and had no idea what it was doing.

The migration story is messier — and some of that confusion was avoidable, and on us.

---

Three eras, three surfaces

Before getting into the architectural comparison, it helps to be clear about where each capability actually lives — because these aren't interchangeable tools competing for the same space. They belong to different generations of the platform.

Dynamic Content Blocks are a Core UI feature. They live in legacy Responsive Canvas dashboards — the same environment as classic Performance Analytics widgets and reports. They are not part of Next Experience and do not appear in UI Builder or Platform Analytics experience dashboards.

The Platform Analytics experience (PAe) in-line editor is the primary interface for building dashboards and data visualizations in the current platform. This is where most dashboard authors live and where most migration effort lands. It is not a workspace. It is not UI Builder. It is a purpose-built analytics authoring surface — and critically, it has no mechanism for Dynamic Content Block logic. That was a deliberate product decision, not an oversight.

Technical Dashboards are a separate authoring surface within PAe, built in UI Builder. They support Data Resources and the full Next Experience component model. From a consumer's perspective — the person viewing the dashboard — there is no visible difference between a dashboard built in the in-line editor and one built as a Technical Dashboard. Both surface as dashboards in the Analytics Center. The distinction only matters to the builder.

Data Resources are the current model for any experience built in UI Builder — Technical Dashboards, configurable workspaces, and custom Next Experience pages. They are not available in the in-line editor and not relevant to Core UI.

So the full picture looks like this:

• Core UI / Responsive Canvas → Dynamic Content Blocks
• PAe in-line editor → the primary analytics authoring surface, no DCB support by design
• PAe Technical Dashboard (UI Builder) → connected components, then Data Resources

---

Why migrations were rocky — and what was behind it

If your organization went through the Core UI to PAe migration and found that Dynamic Content Block content just... didn't come across, let's name the honest reason first: we didn't document the distinction between the in-line editor and Technical Dashboards clearly enough early in the migration guidance, and customers reasonably filled that gap with the wrong assumption. That's on us. Here's what actually happened architecturally.

The migration tooling was built to move reports, Performance Analytics widgets, filters, and dashboard layouts into the PAe in-line editor. DCBs — with their embedded Jelly, JavaScript, and custom rendering logic — had no equivalent surface to land on in the in-line editor. The in-line editor doesn't support that model. It was never designed to.

So rather than attempt a lossy conversion or carry forward a pattern the platform was moving away from, the decision was made to leave DCBs behind.

The intended path was always:

When your organization is ready to replace what DCBs were doing — the context-aware headers, the interactive filters, the custom logic — you rebuild it. Not in the in-line editor, but in a Technical Dashboard using Data Resources. That's the architectural equivalent. That's where that capability lives now. Understanding why makes the path forward clearer.

---

The original problem

In Core UI — the environment most ServiceNow teams lived in before PAe — Dynamic Content Blocks were the mechanism for injecting dynamic behavior into Responsive Canvas dashboards. They worked, but the pattern was tightly coupled from the start: data logic lived inside the dashboard itself, mixing retrieval, transformation, and rendering into a single hard-to-inspect configuration. The dashboard was the solution. Understanding it required understanding everything inside it.

When Next Experience arrived — bringing Technical Dashboards and configurable workspaces with it — the first generation of components repeated the same pattern in a new context. ServiceNow called these "connected components." Each one handled its own server communication and operated as a self-contained mini-application, a little black box that worked independently. There were no first-class, shared data abstractions. Each component fetched and shaped its own data. Platform-level sources like tables and GlideRecord existed, but components accessed them directly — there was no shared declarative layer sitting between the component and the server.

Different surface, same architectural smell.

Both patterns worked fine at small scale, with one author who understood the whole thing. At organizational scale — or when someone new inherited the work — they broke down the same way.

The problems were predictable once you knew to look for them:

Logic hidden inside widgets is hard to test and nearly impossible to reuse. Copy-paste code between dashboards introduces subtle differences nobody documents. Performance is the builder's problem, not the platform's. And if the person who built it leaves, the work becomes untouchable.

---

What Data Resources actually change (in UI Builder)

Data Resources are ServiceNow's architectural answer to the connected component problem — specifically within UI Builder: Technical Dashboards, configurable workspaces, and custom Next Experience pages.

The core idea: separate data, logic, and presentation. A Data Resource mediates between a component and the server. Components become mostly presentational — they display data, they don't own it. Multiple components can bind to the same data source. The platform can optimize, de-duplicate, and cache in ways it couldn't when every component was its own black box.

That's not just a UI upgrade. It's a different model for who is responsible for what.

The builder focuses on intent. The platform handles execution. Pages become composable instead of scripted.

For teams, not just individuals, that distinction matters.

---

The practical difference, without the jargon

In Core UI (Responsive Canvas): Dynamic Content Blocks are the available mechanism for dynamic, context-aware dashboard behavior. Logic lives in the dashboard. The dashboard is the solution. If you're maintaining this environment, that's what you have.

In the PAe in-line editor: This is where most dashboard authors work and where most migration effort lands. It is purpose-built for analytics — KPIs, trends, data visualizations — and does not support Dynamic Content Block logic. If you need dynamic, data-driven behavior beyond what the in-line editor provides natively, Technical Dashboards are the answer.

In UI Builder (Technical Dashboards, workspaces, and custom pages): Data Resources are the current model. Logic lives outside the component. One Data Resource can feed multiple pages and surfaces. Change it once, it updates everywhere it's referenced. Components remain interchangeable. And from a dashboard consumer's perspective, a Technical Dashboard looks exactly like any other dashboard in the Analytics Center — the distinction is invisible to them.

This is the same principle Platform Analytics governance applies to Indicator definitions: put the logic where it can be governed, not where it's convenient to author. The surface is different; the reasoning is identical.

---

"But Dynamic Content Blocks worked fine"

They did. That's worth acknowledging directly.

DCBs unlocked real creativity in Core UI at a time when the platform didn't have better options for that environment. Teams built things that mattered with them. That work was legitimate. The question isn't whether the old approach worked. It's whether it scales — and whether it's the right investment given where the platform is going.

Core UI and Responsive Canvas dashboards are on a sunset path. New content creation in Core UI remains available, but is unsupported starting with the Australia release. If your organization is still building net-new DCB logic, you're investing in a surface the platform is moving away from.

Data Resources are the direction — but only in Technical Dashboards. They don't exist in the in-line editor, and they don't need to. Those are different surfaces with different jobs.

---

What this means in practice

• If you have existing DCB dashboards in Core UI that are stable — leave them. Don't break something that's working.
• If your DCB content didn't migrate to PAe and you're wondering why — that's expected. The in-line editor was never the destination for that content. When you're ready to rebuild it, Technical Dashboards and Data Resources are the right surface.
• If you're building anything new that requires dynamic, data-driven behavior — use Technical Dashboards with Data Resources. Full stop.
• If you're building standard analytics dashboards — KPIs, trends, scorecards — the PAe in-line editor is where you should be. That's what it's designed for.
• If you're tempted to add new DCB logic to an existing Core UI dashboard — pause and ask whether this is the right surface to keep investing in.

The rewrite cost is real. But so is the cost of building more technical debt on a surface the platform is sunsetting.

---

One last thing

The Brad Tilton article, "All About Data Resources in UI Builder", is the best technical reference on Data Resources in UI Builder, written by the person who built the feature. Start there for implementation details.

This post is meant to answer a different question: why the model changed, where each capability belongs, and why some migration content didn't come across automatically.

Those distinctions matter before you decide where to invest.

---

NOTE: This is community guidance based on field experience and publicly available platform documentation. It is not official product documentation. For official documentation, refer to docs.servicenow.com.