Business Intelligence Components: A Complete Guide for 2026

BI doesn't fall apart because a dashboard looks bad. It falls apart when the pieces underneath don't line up.

A successful BI environment depends on six interconnected components: data sources, integration, storage, analytics, visualization, and governance. Once you see how they fit together, data work shifts from reactive report-building to proactive analysis that people actually trust. This guide breaks down each component, walks through the BI workflow from data to decisions, and shares practical implementation guidance.

Key takeaways

Here are the main takeaways:

• Business intelligence systems rely on six core components working together: data sources, data integration, data storage, analytics, visualization, and governance.
• The BI process runs in a loop: gather data, standardize it, analyze it, and share it in ways that drive decisions.
• BI implementations succeed when data, people, processes, and technology stay aligned.
• Modern BI platforms add AI and self-service capabilities so insights reach more of the organization.
• Different BI frameworks (three-part, four-element, five- or six-element models) describe the same underlying architecture from different angles, and mapping them to each other makes BI strategy easier to design and explain.

What is business intelligence?

If you've ever watched teams argue over whose numbers are "right," you've already met the core problem BI is meant to solve.

Business intelligence is a set of strategies and technologies that gather data, interpret it, and transform it into actionable insights. BI uses a variety of tools, including data mining, charts and visualizations, business analytics, and performance benchmarking, to help executives make sound business decisions.

Organizations have more data than ever, but it often lives in disconnected systems, uses inconsistent definitions, and takes too long to turn into answers. That's the gap BI is designed to close. A well-designed BI environment brings data together into a single governed source so teams can move quickly without second-guessing what the numbers mean.

You may have encountered different frameworks describing BI components. Some list three parts, others four elements, still others five or six. These models aren't contradictory; they put the spotlight on different layers of the same architecture. The six-component model explored below is a practical, end-to-end view that maps cleanly to other frameworks while covering what a modern BI system actually needs.

The six core components of business intelligence

Dashboards get the glory, but they're the last stop on the journey.

Business intelligence is more than tools and dashboards. It's an ecosystem of integrated components that work together to turn raw data into actionable insight. Think of these as connected layers, not a shopping list. When one layer is shaky, everything downstream inherits the wobble.

Here's a closer look at each core BI component:

Data sources

Start where the truth starts: the systems where work actually happens.

Data sources are the foundation of any BI environment. This includes everything from customer relationship management (CRM) and enterprise resource planning (ERP) systems to spreadsheets, cloud applications, and even social media feeds. The quality and reliability of your data sources directly impact the accuracy of your insights.

For data engineers and analytic engineers managing source diversity at scale, the challenge isn't just connecting to sources. It's keeping those connections reliable as data volumes grow and source systems change. One flaky integration can cascade into broken dashboards and mistrust, fast.

And honestly, that's the part most guides skip over: deciding which system is authoritative for each domain (customers, products, orders) early. "We'll sort it out later" usually turns into years of reconciliation.

Data integration and ETLextract, transform, load (ETL)

This is where raw data either becomes usable or becomes chaos.

Once you've identified your data sources, the next step is integrating that data so it's secure, consistent, and accessible. This often involves ETL (Extract, Transform, Load) or ELT (Extract, Load, Transform) processes that combine data into a unified format.

The difference between ETL and ELT matters for your architecture:

• ETL transforms data before loading it into your warehouse. This approach works well when you need to clean and structure data upfront, particularly when storage costs are a concern or when your warehouse has limited processing power.
• ELT loads raw data first, then transforms it inside the warehouse. This pattern has become more common with modern cloud warehouses that offer abundant compute power, allowing analysts to iterate on transformations without re-extracting data.

Many teams turn this into a philosophical debate instead of an operational choice. Pick a pattern you can run consistently, monitor, and explain when something breaks. That's what matters.

In many BI environments, ingestion is its own operational reality. If you're pulling from hundreds of apps and databases, the workflow often looks like "connect, schedule, monitor, repeat." That monitoring is what keeps downstream business intelligence components from going stale.

Transformation is also where your BI system earns trust, or loses it. When customer records arrive from multiple sources with different formats, transformation logic deduplicates them, normalizes addresses, and converts currencies so downstream reports reflect a single, accurate view of each customer. The failure mode to watch for: splitting business logic across too many places (a bit in the pipeline, a bit in the warehouse, a bit in a dashboard). That's how you end up debugging the same metric in three different tools.

Many organizations also implement a semantic layer (sometimes called a metrics layer) that sits between transformation and visualization. The semantic layer defines business logic, what "revenue" means, how "churn rate" is calculated, which filters apply, so every dashboard and report uses consistent definitions. Treat metric definitions like product code, with clear ownership and change control. Let it become a modeling playground with no owners, and you'll regret it.

Define your transformation logic once, apply it everywhere. That principle is what keeps the integration layer trustworthy for everyone downstream.

Data warehousing and storage

Storage is where good intentions go to live, or to get buried.

While standardization ensures consistency and quality, data warehousing provides the backbone for efficient storage. A data warehouse serves as a centralized hub where standardized data is securely stored, enabling people to run queries and generate reports without disrupting operational systems.

In some cases, organizations complement data warehouses with data marts, smaller, specialized repositories tailored for specific departments or use cases. Whether using a large-scale warehouse or a focused data mart, these storage solutions ensure standardized data is secure, well-organized, and accessible for analysis, visualization, and dashboarding.

The easy mistake is "dump everything in and we'll model later." Without basic modeling conventions and ownership, you get a lake of mystery tables that nobody wants to touch. Organizations increasingly use data lakehouses, which combine the flexibility of data lakes with the governance structure of warehouses. This hybrid approach lets teams store both structured and unstructured data while maintaining the query performance and management controls BI workloads expect.

Data analysis and mining

Here's where curiosity meets math.

With your data standardized and stored, you can dive into analysis and mining. This is where you start uncovering trends, identifying patterns, and revealing hidden opportunities within your data. Techniques include OLAP (Online Analytical Processing), predictive modeling, and other advanced analytics methods that help you move from "what happened" to "what's next."

Effective BI analysis depends not just on running queries but on having well-defined, consistently governed metrics. The key performance indicator (KPI) lifecycle, define, validate, publish, monitor, and revise, keeps the numbers your organization tracks aligned with how the business actually operates. A metric definition should include its calculation, grain (daily, weekly, monthly), refresh cadence, and owner so that everyone interprets it the same way.

This is also where AI can be genuinely helpful: forecasting, correlation, and anomaly detection work best when they're grounded in certified definitions from your semantic layer. Otherwise you're just automating arguments. Sanity-check "interesting" correlations against real-world context before you ship them to an executive dashboard. That step gets skipped more than it should.

For analysts and BI specialists, advanced analytics capabilities like forecasting and statistical modeling represent the work you actually want to spend time on. When the upstream components, integration, storage, governance, are doing their jobs, you spend less time reconciling numbers and more time answering the questions that matter.

Reporting and visualization

If analysis stays in a notebook, it doesn't change anything.

Analysis alone doesn't drive decisions. Clear reporting and visualization do. BI tools transform complex data into charts, graphs, dashboards, and scorecards so leaders can understand the story behind the numbers and act with confidence.

Modern BI platforms push reporting further with interactive dashboards that deliver real-time insights into performance metrics, key performance indicators (KPIs), and historical trends. These dashboards can be tailored: executives track strategic objectives, while marketers monitor campaign results with precision. Dashboard sprawl is the misuse to watch for. Dozens of slightly different dashboards answering the same question in slightly different ways. That's not insight; it's noise.

Effective visualization components are designed for the full spectrum of people, not just technical analysts. Line-of-business (LOB) managers and other non-technical people who still need daily data need self-service access to role-appropriate dashboards rather than waiting for analyst-built reports. Self-service doesn't mean ungoverned. Reliable visualizations depend on a governed metrics layer upstream where KPI definitions are certified and consistent across every report and dashboard. If people can't tell which metric is the "official" one, they won't trust any of them.

BI systems also support scheduled delivery of reports to stakeholders. When routine reporting runs on autopilot, analysts spend less time acting like a report factory and more time doing the interesting work.

On top of dashboards and static exports, many teams rely on alerts when something changes. If a KPI spikes, drops, or drifts outside a threshold, automated notifications help the right people act while the moment still matters. The catch with alerts is training: tune the thresholds poorly, and you'll train everyone to ignore the noise within a month.

Data governance and security

Governance is the part nobody brags about, until it's missing.

Data governance is not just a best practice. It's a core BI component that determines whether your insights can be trusted. Governance encompasses the policies, processes, and controls that ensure data quality, security, and compliance across your BI environment.

Key governance artifacts include:

• Data catalog: A searchable inventory of your data assets, including descriptions, owners, and classification (PIIpersonally identifiable information, confidential, public). The catalog enables discovery while controlling who can access what.
• Data lineage: The ability to trace data from its source through transformations to final reports. Lineage is essential for auditing, troubleshooting, and understanding how sensitive data flows through your systems.
• Access controls: Role-based access control (RBAC) assigns permissions based on job function, while row-level security restricts which records people can see based on attributes like region or department. These controls ensure people see only the data they're authorized to access.

Some platforms support more granular policies that act like a governed control plane for the whole BI stack. For example, personalized, row-level permissions can follow the data into every downstream business intelligence component, dashboards, reports, alerts, and AI-driven experiences, without you re-implementing rules in three different tools. Managing permissions ad hoc per dashboard is the pattern that looks fine until it doesn't, and then you're auditing access in a panic.

Data quality dimensions provide a framework for measuring trustworthiness:

• Freshness: How recently was the data updated?
• Completeness: Are required fields populated?
• Consistency: Do values match across systems?
• Referential integrity: Do relationships between tables hold?

Compliance alignment matters for regulated industries. Governance controls should map to standards like Service Organization Control 2 (SOC 2), the Health Insurance Portability and Accountability Act (HIPAA), and the General Data Protection Regulation (GDPR), with audit logs that track who accessed what data and when.

For IT and data leaders, governance is the mechanism that enables self-service without sacrificing control. When guardrails are built into the system, teams can explore data with confidence instead of waiting for approvals at every turn.

Most BI platforms treat governance as a separate concern managed outside the tool through third-party security infrastructure or complex configuration. Embedding governance directly into the BI component stack reduces risk and maintenance overhead while making compliance evidence easier to produce.

How business intelligence works

Knowing the parts is useful. Watching them interact is where BI clicks.

The BI process follows a cyclical flow that transforms raw data into decisions and then feeds learnings back into the system.

The BI workflow from data to decisions

Here's what the end-to-end flow looks like in practice:

1. Collect data from sources: Sales records from your CRM, product data from your ERP, web traffic from analytics platforms, and external data like market benchmarks all flow into the system.
2. Integrate and transform via ETL/ELT: Data is extracted, cleaned, deduplicated, and standardized. A customer record appearing in three systems becomes one trusted record with consistent formatting.
3. Store in a governed repository: Transformed data lands in a data warehouse or lakehouse, organized into schemas that support efficient querying (often a star schema with fact and dimension tables).
4. Apply metric definitions via a semantic layer: Business logic is defined once, "Revenue equals sum of sales amount, excluding returns, at daily grain," so every downstream consumer uses the same calculation.
5. Analyze and explore: Analysts run queries, build OLAP cubes, and apply statistical models to uncover patterns and answer business questions.
6. Visualize and distribute: Insights become dashboards, reports, and alerts tailored to different audiences. Executives see strategic KPIs; operations teams see real-time metrics.
7. Act on insights: Decisions are made, adjust pricing, reallocate marketing spend, address a supply chain issue, and the results flow back into source systems, starting the cycle again.

People sometimes treat this like a straight line with a finish date. It isn't. The loop only works when steps four through seven feed back into earlier assumptions: definitions, data contracts, even which sources you trust.

A concrete example: Imagine a retail company asking, "Why did Q3 sales drop in the Midwest?" Data flows from the CRM and point-of-sale (POS) systems through an automated pipeline that deduplicates transactions and normalizes product categories. The warehouse stores this in a star schema with fact_sales joined to dim_store, dim_product, and dim_date. The semantic layer defines "same-store sales" consistently. An analyst queries the data, discovers that a key product was out of stock at several locations, and surfaces this in a dashboard. The operations team sees an alert, investigates, and fixes the supply chain issue. Next quarter's data will show whether the fix worked.

For data engineers, the focus is on steps one through three, pipeline reliability and data quality. For LOB executives, it's steps five through seven, speed from data to decision. A well-designed BI system respects both perspectives, and the friction usually lives at the handoff between them.

Benefits of business intelligence

When the components play nicely together, the payoff is real:

• Timelier decisions: Instead of waiting days for an analyst to pull data, business people can answer questions in minutes through self-service dashboards. The time between a business question and a confident answer shrinks dramatically.
• Consistent metrics across teams: A governed semantic layer ensures that "revenue" means the same thing in the sales dashboard, the finance report, and the executive presentation. No more conflicting numbers in meetings.
• Reduced reliance on analyst intermediaries: Self-service access means LOB managers can explore data directly rather than submitting requests and waiting in queue. Analysts can focus on complex analysis instead of routine report generation.
• Improved operational efficiency: Automated data pipelines and real-time dashboards replace manual spreadsheet work, which frees teams to spend time on analysis instead of reformatting data.
• Clearer customer understanding: Unified customer data enables segmentation, personalization, and churn prediction that wouldn't be possible with fragmented systems.
• Data-driven culture: When insights are accessible and trustworthy, more people use data in their daily decisions. This compounds over time as data literacy spreads across the organization.

These benefits only materialize when the underlying components, especially data governance and data quality, are working correctly. A BI system with inconsistent metrics or unreliable data can make decisions worse by giving false confidence in flawed numbers.

BI tools and platforms

The BI tool landscape gets noisy quickly. A simple way to cut through it is to map tools to the component they serve.

Here's how common tools map to BI components:

• Data integration: Domo, Fivetran, Airbyte, Stitch, Talend, and Informatica handle extraction and loading from source systems.
• Data transformation: Domo, dbt, Dataform, and Matillion focus on the transformation layer, often running inside the warehouse.
• Data storage: Snowflake, BigQuery, Redshift, Databricks, and Azure Synapse provide warehouse and lakehouse capabilities.
• Semantic layer: dbt Metrics, LookML (Looker modeling language), Power BI semantic models, and AtScale define business logic and metric consistency.
• Visualization: Domo, Tableau, Power BI, Looker, Qlik Sense, and Metabase turn data into dashboards and reports.
• Governance: Alation, Collibra, Atlan, Monte Carlo, and Great Expectations handle cataloging, lineage, and quality monitoring.

Worth recognizing that some popular tools emphasize one slice of the stack. Tableau is often centered on visualization, while platforms like ThoughtSpot focus on search-style, natural language analytics. Those approaches can work well, but you still need to account for ingestion, transformation, governance, and metric consistency somewhere else, usually with more tooling and more coordination than teams expect.

When evaluating tools, consider these selection criteria:

• Data volume and latency requirements: Real-time dashboards need different infrastructure than weekly batch reports.
• Governance needs: Regulated industries require strong access controls, audit logs, and compliance documentation.
• Self-service vs. centralized model: Some organizations want analysts to control all reports; others want business teams to build their own.
• Existing technology stack: Tools that integrate with your current cloud provider and data infrastructure reduce complexity.
• Total cost of ownership: Consider not just license fees but also implementation, training, and ongoing maintenance.

Point solutions like Tableau for visualization or Snowflake for storage require organizations to assemble and govern multiple tools separately. That can be a solid approach for teams with the capacity to integrate and operate the full stack, but it introduces overhead and more places for metric definitions to drift. Unified platforms that handle multiple components under a single architecture reduce coordination work, though they may offer less specialized depth in any one area.

What are the four main components of BI?

BI implementation isn't a one-and-done project. It's ongoing, and it touches a lot of the business.

In order to understand the BI cyclical process, you need to understand the four main components: data gathering, data standardization, data analysis, and reporting.

1. Data gathering

First, you collect the raw material.

The first step in business intelligence is to gather data. This includes collecting data from all your sources as well as collecting historical data to inform strategic decisions. This first step of gathering data will give you a baseline to which you can compare future metrics.

Teams sometimes stop here and assume "more data" equals "stronger BI." If you don't also capture the right keys and timestamps, joining and trending later becomes guesswork. More sources without more structure is just more mess.

2. Data standardization

This is the step most teams underestimate. Consistently.

Data standardization is often the most challenging aspect of Business Intelligence (BI). It begins with data cleaning, filtering out inaccuracies, incomplete records, duplicates, and irrelevant information. Once the data's quality is verified, the next step is storage. This involves implementing data automation, setting permissions, establishing security protocols, and other technical measures to ensure reliable storage. Additionally, the data must be properly categorized and organized within the storage system for easy and quick access.

Standardization also requires converting data into consistent, compatible formats, ensuring it remains readable and can be processed uniformly across systems. A common pitfall: standardizing "just enough" for a single report. As soon as a second team needs the same data, the definitions fracture again. You end up standardizing the same field three times for three different audiences, and nobody notices until the quarterly review.

3. Data analysis

Now you get to ask questions that matter.

With data gathered and standardized, the analysis component begins. This is the stage where you start getting insights and building strategy. Identify trends, compare data sets, observe correlations, visualize data into charts and graphs, and make predictions based on real-time updates. The more you analyze the data, the more actionable insights you'll find to help improve your business processes.

Keep analysis tied to a decision. Analysis that doesn't connect to a choice often turns into interesting charts that never change what anyone does. That's a real risk, and it's more common than most BI guides admit.

4. Reporting

Reporting is where you make the work shareable.

A data report consolidates specific data sets into a single snapshot. Think of it as a photograph capturing a moment in time, like someone mid-jump off a diving board. The data is static and unchanging after the report is created or exported. It still provides valuable insights, though: you can deduce past events (the person jumped off the diving board) and make predictions about the future (they'll likely hit the water soon, and you can even estimate when).

Treating exports as the destination is where teams get stuck. If a report drives ongoing decisions, it usually belongs as a governed dashboard with a clearly defined refresh cadence and ownership.

Best practices for an effective BI environment

You can buy plenty of tools and still end up with a brittle BI environment. The difference is the discipline you build around the components.

Start with governance, not visualization. It's tempting to jump straight to dashboards, but without governed data sources and consistent metric definitions, you'll build on a shaky foundation. Establish a semantic layer or certified metrics standard early so that every report uses the same business logic.

Design for your full user spectrum. Data engineers need pipeline reliability and clear data contracts. Analysts need reusable metrics and the ability to explore data deeply. IT leaders need governance without bottlenecks. LOB people need self-service access that does not require SQL skills. A successful BI environment serves all these needs, not just the most technical people.

Invest in data quality monitoring. Automated checks for freshness, completeness, and consistency catch problems before they reach dashboards. A subtle but real failure mode is monitoring pipelines while ignoring business-level checks (like "orders can't be negative"). You need both to keep BI trustworthy.

Document metric definitions explicitly. Every KPI should have a documented calculation, grain, filters, refresh cadence, and owner. This documentation prevents the "what does this number mean?" conversations that erode trust in BI systems.

Build for iteration, not perfection. BI environments evolve as business needs change. Design your architecture to accommodate new data sources, new metrics, and new groups of people without requiring a complete rebuild.

Measure adoption, not just deployment. A dashboard that nobody uses provides no value. Track which reports get viewed, which metrics get queried, and where people get stuck. Use this feedback to improve the BI experience over time.

Real-world BI use cases

Same components, different shape, depending on the problem you're solving.

BI components come together differently depending on the business problem. Here are examples that illustrate how the components work in practice:

Sales pipeline visibility: A business-to-business (B2B) company connects CRM data (data sources) through an automated pipeline (integration) into a warehouse (storage) where opportunity stages are standardized. A semantic layer defines "qualified pipeline" consistently, and sales managers access a dashboard (visualization) showing pipeline by rep, region, and product. Governance ensures reps see only their own opportunities while managers see their full team.

Marketing attribution: A consumer brand integrates web analytics, ad platform data, and CRM records to understand which campaigns drive conversions. The transformation layer handles cross-device identity resolution and attribution modeling. Dashboards show marketing ROI by channel, and alerts notify the team when cost-per-acquisition exceeds thresholds. Attribution is also where definition drift happens easily, so teams tend to get clearer results when they lock down a small set of agreed-upon models instead of letting every channel report "its" version.

Operational efficiency: A logistics company monitors delivery performance in near-real-time. Data streams from GPS devices and warehouse systems into a lakehouse, where transformations calculate on-time delivery rates by route and driver. Operations managers see dashboards with drill-down capability, and anomaly detection flags routes that suddenly underperform.

Financial forecasting: A retail chain combines historical sales data with external factors like weather and economic indicators to predict demand. The analysis layer applies statistical models, and finance teams access forecasts through governed reports that show assumptions and confidence intervals. Row-level security ensures regional managers see only their markets. Forecasts also need a feedback loop. If you don't compare predicted vs. actual and adjust, "forecasting" turns into a fancy way to repeat last quarter.

In each case, the value comes not from any single component but from how the components work together, reliable data flowing through governed transformations into accessible, trustworthy visualizations.

Common mistakes in business intelligence implementation

BI projects rarely fail for lack of ambition. They fail in the boring places.

While business intelligence can be extremely beneficial to companies, there are common mistakes that undermine BI initiatives.

Data quality issues

Data quality problems usually start with not understanding what kind of data you're dealing with.

When gathering data for business intelligence, it's important to understand the three main types of data:

Structured data is organized in a predefined format, typically stored in a database, making it easy to access and analyze.

Unstructured data lacks a predefined format and includes things like emails, social media posts, and images.

Semi-structured data falls between structured and unstructured, with examples including Extensible Markup Language (XML) and JavaScript Object Notation (JSON) files.

Understanding these data types and how to gather and analyze them effectively is crucial for businesses.

Data that lacks freshness, completeness, referential integrity, or consistency will produce unreliable insights regardless of how sophisticated your analysis tools are. Sophisticated tools applied to bad data don't produce solid answers. They produce confidently wrong ones.

Process and adoption failures

Even with good data, process issues can stall a BI environment.

Several process-related mistakes commonly derail BI initiatives:

• Not gathering data from all relevant sources: In order to make accurate decisions, companies need to gather data from all relevant sources. This includes internal data sources like financial reports and customer databases as well as external data sources like news articles and social media posts.
• Not cleaning or standardizing the data: Once the data has been gathered, it needs to be cleaned and standardized. This includes things like removing duplicates, standardizing formats, and filling in missing values.
• Not defining consistent metrics: When different teams calculate the same metric differently, conflicting reports erode trust in the entire BI system.
• Not empowering people to use data: In order for business intelligence to be successful, people need to be empowered to use data to make decisions. This includes training people on how to use the BI system, giving them access to the data, and encouraging them to use data when making decisions.

You can avoid many of these mistakes by taking the time to develop a strategic business intelligence environment that addresses data, people, processes, and technology together. One telltale sign you're on the right track: when a new question comes up, you can answer it by extending the system, not by starting over in a spreadsheet.

How Domo supports a more effective BI environment

Good BI isn't just "more tools." It's fewer seams between the components.

Building an effective business intelligence environment requires the right infrastructure, processes, and tools. That's where Domo comes in.

Unlike fragmented multi-tool stacks that require organizations to assemble and govern separate solutions for ingestion, transformation, storage, visualization, and governance, Domo provides all core BI components under a single governed platform. This architectural completeness means:

• IT and data leaders get enterprise-grade security with RBAC, Personalized Data Permissions (PDP), row-level security, Single sign-on (SSO) integration, audit logs, visual data lineage, and compliance certifications (SOC 2, HIPAA, GDPR) built into the platform rather than bolted on.
• Analysts and BI specialists work with certified metrics and reusable logic through Domo's Certified Metrics and semantic layer, eliminating the "multiple versions of truth" problem.
• LOB managers and other non-technical people can ask plain-English questions with AI Chat and get instant answers grounded in governed data and certified definitions, without filing a ticket or waiting in a queue.
• LOB executives stay on top of performance with Dynamic Dashboards and AI-powered alerts that call out KPI changes as they happen.
• Data engineers connect to over 1,000 pre-built connectors and build reliable pipelines with built-in data quality monitoring. For teams juggling many source systems, that breadth reduces connector sprawl and the long tail of one-off integrations that quietly break on a Tuesday morning.
• Analytic engineers can prep and enrich data with Magic Transformation (structured query language [SQL]-based and no-code ETL/ELT), then trace issues end to end with lineage.
• Teams can automate routine distribution with Scheduled Reports Delivery, so stakeholders get the right report on the right cadence.
• Organizations that need embedded analytics can use Domo Embed, with the same governed metrics, permissions, and AI Chat available inside embedded experiences.

From data collection to decision-making, Domo helps teams access clean, centralized data, visualize insights quickly, and act with confidence. If you're just getting started, the platform keeps the basics consistent; if you're already mature, it helps you tighten governance and reduce handoffs across the stack.

Ready to see it in action? Watch a demo or try Domo for free today.