How to Choose BI Extension, Embedded Integration or Custom Development

Summary: BI extension adds functions within an existing product's exposed capabilities and license terms. Embedded integration brings BI capabilities into an existing portal, business application or management dashboard. Independent development builds around the client's data, permissions, interface, workflows and deployment requirements. Compare more than initial development effort: interface stability, licensing, upgrade dependence, operations and exit costs also matter.

In brief: if most needs fit the product, configure or extend it first. If the goal is a single entry point that reuses mature reports, consider embedding. If product limits prevent cross-system metrics, complex permissions, dedicated workflows or required deployment, consider independent development. The three approaches can also be combined.

Start with three clear definitions

BI extension

Develop plugins, components, scripts, interfaces, themes or custom functions through an existing BI product's extension mechanisms. The result still depends on that product's runtime, data model, permission system, version and license. What is possible depends on its officially supported capabilities.

Embedded BI integration

Place reports, dashboards, analytics or natural-language querying inside a company portal, business application or management dashboard. This also requires single sign-on, account mapping, filter parameters, navigation, styling, data permissions and activity logs. Embedding means more than showing a screenshot or an iframe.

Independent custom development

Build a system around the client's databases, interfaces, identity, permissions, business processes, UI, deployment and acceptance requirements. Open-source or commercial components can still be reused, but one BI product does not define the overall architecture or delivery boundary.

The main differences between the three approaches

Comparison	BI extension	Embedded integration	Independent development
Prerequisites	An existing product supports extensions.	Existing reports, APIs or SDKs can be embedded.	Requirements and boundaries for data, permissions and environment can be defined.
Main goal	Add a limited capability within the product.	Create one entry point while reusing product features.	Support dedicated scenarios outside product limits.
Control over the interface	Limited by the component, theme and plugin mechanisms.	The outer shell can be customized; embedded content remains constrained.	Can be designed around each role's tasks, but requires development and maintenance.
Identity and permissions	Based on the product's permission model.	Portal and BI identities must be mapped; parameters must not bypass access controls.	Can inherit enterprise identity and enforce permissions at API, row, column and field levels.
Deployment and licensing	Depends on supported environments and extension licenses.	Embedding, users, concurrency and external-access licenses must be confirmed.	Third-party dependencies and deployment scope are set through contract and technical validation.
Upgrade impact	Plugins or scripts may need updating with each product version.	APIs, SDKs, tokens and page capabilities may change.	Framework, component, security and compatibility upgrades must be managed directly.
Delivery focus	Extension code, configuration, compatibility notes and regression results.	Integration code, identity and permissions, API documentation and fallback plan.	Requirements, design, source or builds, deployment, testing and operations materials.
Exit dependence	High: extensions generally cannot run without the product.	Medium to high: plan an alternative entry point if the product is unavailable.	Depends on third-party components, source-code rights, documentation and maintenance capacity.

When BI extension makes sense

The existing data model, permissions and most pages already fit; only a few components or actions are missing.
The product has stable, supported plugins, scripts, SDKs or open APIs.
Extensions can be included in upgrade regression tests, with an internal team or supplier responsible for ongoing maintenance.
The license expressly permits extensions for the intended users, devices, concurrency and deployment method.

If the extension requires extensive changes to internal product logic, depends on undocumented APIs or must be rebuilt after every upgrade, compare embedding and independent development again instead of adding more temporary patches.

When embedded integration makes sense

The company already has a unified portal or business application and does not want users to log in through several entry points.
BI reports, data models and permissions are mature enough to reuse.
Users need to move from a customer, project, organization or device record into the corresponding analysis page.
The product supports embedding, tokens, parameters, events and permission APIs.

Identity and data scope are the easiest parts of embedding to overlook. Organization, project or time parameters passed by the host application should only set context. The BI system must still check access against the signed-in identity; a frontend parameter is not authorization.

When independent development makes sense

The solution must connect multiple business systems, live devices, GIS or 3D, video, work orders or approvals.
Role-specific pages, interaction order and business actions cannot be expressed within the product's components.
Permissions must follow a complex organization structure across pages, APIs, rows, columns, fields, exports and devices.
The deployment environment, hardware, network isolation, monitoring, backup or release process has specific constraints.
The contract must define code, builds, configuration, dependencies, accounts, testing and operations materials as part of delivery and exit.

Independent development should not rebuild mature functions merely to appear "custom." Existing BI can continue to serve self-service analytics, while a custom dashboard uses a metric service, data warehouse or supported API for its own tasks.

Do not compare only the initial quote

Break down costs over three years or the contract term:

Product licenses, users or concurrency, embedding, extension components and technical support.
Data integration, models, permission mapping, interfaces, testing and migration development.
Version upgrades, compatibility regression, security fixes, monitoring, backup and incident recovery.
New metrics, organization changes, interface changes and process iterations.
Retirement, replacement, data export, missing documentation and account revocation.

Fast initial configuration is not automatically cheaper long term, and more initial custom work is not automatically a better investment. Put assumptions, scope boundaries and responsibilities in the same comparison table to make costs controllable.

Test all three approaches with one small prototype

Data:Choose a metric that spans two systems; check fields, refresh, null values and historical versions.
Permissions:Use two organizations and three roles to test pages, APIs, fields, exports and unauthorized parameters.
Interaction:Move from a fixed management view into detailed analysis, then into the actual business-processing entry point.
Environment:Run it in the intended browser, network, identity system and representative devices.
Upgrades and failures:Simulate interface failure, expired tokens, no data and unavailable components; check messaging and fallback behavior.
Evidence:Record requirement coverage, performance, permissions, licenses, compatibility, operations and estimated total lifecycle cost.

Only the same prototype scenario gives a fair comparison. If each solution uses different data, roles and content, the demonstration itself can bias the result.

Four reasons to pause the choice

Core functions require undocumented APIs, a shared high-privilege account or screen scraping.
Embedding, external-access, concurrency or extension licensing is still unconfirmed.
No agreement states who handles compatibility after an upgrade, how quickly issues are fixed or whether rollback is possible.
The metric owner, permission approver and post-launch maintainer are still unknown.

Frequently asked questions

Are BI extension and embedded integration the same thing?

Not quite. Extension generally adds plugins, components, scripts, interfaces or custom functions within a product's exposed capabilities. Embedded integration focuses on putting BI reports or analytics into an existing portal, business system or dashboard, including identity, permissions, navigation and context transfer.

Is independent development always more expensive than extending BI?

You cannot judge without scope. Reusing an existing product is often economical when many standard analytics functions are needed. If licenses, interface limits and repeated adaptation dominate cost, independent development or a hybrid architecture may be more controllable. Compare licensing, development, upgrades, operations and exit over the full lifecycle.

What must be confirmed before embedding BI?

At minimum, confirm embedding rights, accounts and concurrency, single sign-on, data permissions, filter context, API versions, cross-origin and security policies, mobile support, upgrade compatibility, monitoring logs and fallback behavior.

Can the three approaches be combined?

Yes. A common hybrid keeps the BI semantic model and self-service analytics, embeds standard reports in a business application, and independently builds a management landing page, cross-system metrics, dedicated workflows or GIS and 3D views. Keep metric definitions, identities and maintenance ownership consistent.