Advanced Business Builder: Architecture, Integration and Production Design (Part 7)

At senior and architect level, Business Builder should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
Introduction to Business Builder: Purpose and Core Entities: Understand what Business Builder is, why it exists alongside Data Builder, and the core entity types (fact models, consumption models, dimensions) used to create business-friendly semantic layers in SAP Datasphere.

Building Fact Models, Measures, and Associations in Business Builder: Learn the practical steps and design decisions for building fact models in Business Builder, including measure definitions, currency/unit handling, dimension associations, and how these models surface for consumption in SAP Analytics Cloud.

Exposing Business Builder Consumption Models to SAC Stories and Planning: Learn how Business Builder Consumption Models and Perspectives are structured, deployed, and connected to SAP Analytics Cloud for reporting and planning, including live connection behavior and common integration pitfalls.

Business Builder Foundations: Purpose, Layers, and Business Entities: Understand why SAP Datasphere separates Business Builder from Data Builder, what business entities (dimensions, fact models, consumption models) are, and how business users consume them versus how technical modelers build source objects.

Building Fact Models and Dimensions: Associations, Measures, and Deployment: Learn the practical steps and design considerations for building dimensions and fact models in Business Builder, including associations, measure definitions, currency/unit handling, and the deployment and troubleshooting workflow.

Building Consumption and Planning Models with Business Builder: Learn how to assemble fact models and consumption models in Business Builder, expose them for reporting and planning, and understand how these objects interact with the data layer and SAP Analytics Cloud stories.

Architecture and production criteria

• Always deploy and test a Fact Model and its Consumption Model in a non-production space before promoting to production consumption.
• Always finalize and deploy underlying Data Builder views before starting Business Builder modeling
• Always validate dimension key uniqueness in the source view before building associations in a fact model.
• Always validate join cardinality explicitly when creating associations in a fact model, don't rely solely on auto-suggestions
• Benchmark live query performance against the underlying Data Builder view before assuming a performance issue originates in SAC.
• Confirm currency/unit reference columns exist in source data before configuring currency-aware or unit-aware measures.
• Confirm space-sharing and deployment status whenever a Consumption Model does not appear as expected in the SAC connection picker.
• Deploy objects in dependency order: dimensions first, then fact models, then consumption models, and re-deploy the full chain after upstream changes.
• Design version and time dimensions up front if planning is even a possible future requirement
• Document the full entity-to-consumption chain for each exposed model so support staff can trace defects efficiently
• Document which team owns Data Builder objects versus Business Builder objects to avoid governance conflicts.
• Document which team owns Data Builder objects versus Business Builder objects to maintain clear governance boundaries
• Establish naming conventions (business names vs technical names) early so Business Builder objects are self-explanatory to end users.
• Explicitly review and set correct aggregation behavior for every measure rather than accepting defaults
• Keep calculated and restricted measure logic in the consumption model layer so fact models remain reusable across multiple consumption scenarios
• Keep Data Builder views as the single source of technical transformation logic; use Business Builder purely for business semantics and consumption assembly.
• Keep dimension and fact model naming business-friendly and consistent across spaces to avoid confusion in SAC
• Keep technical view logic in Data Builder and business-facing composition in Business Builder to preserve clear governance boundaries.
• Maintain and monitor currency/unit conversion reference data on a defined refresh cycle
• Restrict edit rights on shared Consumption Models and Business Entities to a governed group, and communicate changes to dependent SAC story owners.
• Sample and manually verify joined data between fact model and dimensions after each significant change, not just after deployment
• Scope consumption models narrowly to specific reporting or planning use cases rather than building one large universal model.
• Standardize on shared, IT-governed dimensions for common business entities and discourage duplicate local dimensions
• Test consumption models with at least one restricted-role test user before releasing to broader audiences
• Test Data Access Controls with multiple representative user roles before promoting a fact model to production consumption
• Use a small pilot fact model to validate the end-to-end flow into SAP Analytics Cloud before scaling to many business models
• Use clear, business-friendly naming and descriptions in the consumption model since this is what end users see directly in SAC
• Use Perspectives to scope Consumption Models to the needs of specific consumer groups instead of exposing one large model to everyone.
• Use test queries or sample data previews after each deployment step to catch row-multiplication or missing-data issues early, before promoting to production spaces.
• Validate associations and cardinalities immediately after creating a fact model rather than after downstream story-building begins
• Validate dimension grain against the Fact Model explicitly before publishing a Consumption Model, especially after any Business Entity change.
• Validate grain and key uniqueness in source views before exposing them as dimensions, since Business Builder assumes clean, de-duplicated master data.

Failure analysis and operational risk

• Allowing broad edit access to Consumption Models, letting business users change shared measure logic that other teams' stories silently depend on.
• Applying currency conversion logic at the wrong layer (business entity instead of consumption model), making it hard to reuse the same fact model for multiple reporting currencies
• Assigning sum aggregation to ratio, percentage, or already-aggregated measures, producing meaningless totals
• Assuming a Consumption Model built in Business Builder is automatically visible in SAC without confirming deployment and space-sharing configuration.
• Assuming a successful deployment means the join between fact model and dimension is business-correct, without sampling actual joined data
• Assuming Business Builder can fix data quality or grain issues that originate in the underlying Data Builder view
• Assuming Business Builder eliminates the need for clean, well-modeled source views in Data Builder, leading to incorrect grain or duplicated rows once consumption models are built.
• Building dimensions directly on raw source tables instead of curated, deployed Data Builder views
• Building fact model associations without first verifying that the referenced dimension's business key is truly unique, causing row multiplication in consumption models.
• Building fact models referencing dimensions with mismatched key data types, causing deployment failures that are hard to diagnose for non-technical users.
• Building one large, all-purpose consumption model instead of use-case-scoped models, leading to slow queries and confusing variable prompts for business users.
• Building one oversized Consumption Model instead of using Perspectives, resulting in slow live queries and confusing dimension lists for business users.
• Configuring currency conversion without verifying the exchange rate table is complete and current for all relevant periods
• Confusing a fact model with a consumption model and being unsure which object to expose to SAP Analytics Cloud
• Creating associations in the fact model without verifying cardinality, leading to fan-out and duplicated measure values
• Enabling planning write-back on a Consumption Model without verifying that the underlying Fact Model and dimension entities actually support the required version/time keys.
• Exposing too many technical or intermediate calculated columns in the consumption model, confusing business users in SAC
• Forgetting to deploy a Fact Model or Dimension after making changes, so consumers still see the old version in SAC.
• Forgetting to mark a consumption model as planning-enabled, so SAC displays data but blocks user input
• Ignoring key and cardinality mismatches between fact model associations and dimension keys, leading to fan-out or missing rows
• Mismatching the grain of a Business Entity against the Fact Model it is joined to, causing row duplication or incorrect aggregation in SAC stories.
• Mixing technical/source-system field names directly into business entities instead of renaming them to business-friendly labels, hurting adoption.
• Not deploying the underlying Data Builder view before attempting to reference it in Business Builder, causing validation errors
• Not re-deploying downstream fact models and consumption models after a change to an upstream dimension or source view, leaving stale metadata in production.
• Not testing row-level security with a representative restricted user before go-live, only validating with an admin account
• Not understanding that a Consumption Model is a separate, explicitly published artifact and expecting a Fact Model alone to be consumable by all downstream tools.
• Omitting a currency or unit reference column mapping on monetary/quantity measures, so currency conversion or formatting does not work as expected in SAC.
• Recreating near-duplicate dimensions per fact model instead of reusing a shared governed dimension, causing inconsistent KPIs across stories
• Skipping multi-user testing of Data Access Controls, leading to over-exposure or unexpected empty results in production
• Skipping version and time dimension planning during model design, forcing a rebuild once planning requirements are added later
• Treating live connection performance issues as an SAC problem when the root cause is an unoptimized underlying Data Builder view feeding the Fact Model.
• Trying to deploy a fact model before its associated dimensions have been successfully deployed, resulting in confusing dependency errors.

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A retail company's finance analyst wants a self-service Sales Actuals model in SAC without waiting on the data engineering backlog for every new measure. The data engineering team builds and deploys a Data Builder graphical view called V_SALES_ACTUALS joining order line items with product and store master, applying row-level currency and status filters. The finance analyst, given Business Builder access in their space, creates a Product dimension and a Store dimension referencing existing master data views, then builds a Sales fact model on V_SALES_ACTUALS, mapping Net Revenue and Quantity as measures and associating them to the two dimensions. The resulting fact model is exposed to SAP Analytics Cloud as a live data source for a monthly sales story, letting the analyst iterate on measure labels and dimension groupings without filing IT tickets.

A multinational manufacturer builds a Business Builder fact model called Plant Costs sourced from a Data Builder view that aggregates cost postings by plant, cost center, and period, in multiple local currencies. The modeling team configures currency conversion on the Amount measure to report in USD using a maintained exchange rate table, associates the fact model with shared Cost Center and Plant dimensions used across several other fact models, and attaches a data access control so that plant controllers only see costs for plants in their assigned region. During UAT, a controller in Brazil reports seeing costs in the wrong currency; the root cause is traced to a missing exchange rate for the reporting period in the conversion table, which the team fixes by updating the rate maintenance process rather than the fact model itself.

A retail analytics team built a Sales Fact Model in Business Builder at Sales Order Item grain, joined to Customer and Product Business Entities, then split it into two Perspectives: one for regional sales managers (regional aggregates only) and one for finance (full margin and cost detail). SAC stories were built as live connections against the sales manager Perspective for fast, low-detail dashboards, while a separate planning model used the finance Perspective for margin forecasting. When a business analyst later added a new attribute to the Customer Business Entity without validating grain alignment, several regional dashboards began showing duplicated order counts, requiring the team to trace the issue back to the entity join cardinality rather than the Fact Model itself.

A retail company's central BI team builds and cleans sales transaction views and product/customer master views in Data Builder from an S/4HANA replication flow. The finance business analyst team, who are not SQL experts, use Business Builder to create a 'Product Dimension' referencing the cleaned product view, a 'Customer Dimension' referencing the customer view, and a 'Sales Fact Model' that combines both dimensions with revenue and quantity measures. They then publish a Consumption Model exposing net revenue by product category and region, which is consumed directly in an SAP Analytics Cloud story used in the monthly sales review.

A consultant is asked to fix a sales dashboard in SAC where total revenue appears roughly double the expected value. Investigating the underlying Business Builder Fact Model, they discover the association between the Sales Fact and the Customer Dimension was built against a customer view that had duplicate rows per customer (due to a slowly changing dimension sourc

• Allowing broad edit access to Consumption Models, letting business users change shared measure logic that other teams' stories silently depend on.
• Applying currency conversion logic at the wrong layer (business entity instead of consumption model), making it hard to reuse the same fact model for multiple reporting currencies
• Assigning sum aggregation to ratio, percentage, or already-aggregated measures, producing meaningless totals
• Assuming a Consumption Model built in Business Builder is automatically visible in SAC without confirming deployment and space-sharing configuration.
• Assuming a successful deployment means the join between fact model and dimension is business-correct, without sampling actual joined data
• Assuming Business Builder can fix data quality or grain issues that originate in the underlying Data Builder view
• Assuming Business Builder eliminates the need for clean, well-modeled source views in Data Builder, leading to incorrect grain or duplicated rows once consumption models are built.
• Building dimensions directly on raw source tables instead of curated, deployed Data Builder views
• Building fact model associations without first verifying that the referenced dimension's business key is truly unique, causing row multiplication in consumption models.
• Building fact models referencing dimensions with mismatched key data types, causing deployment failures that are hard to diagnose for non-technical users.
• Building one large, all-purpose consumption model instead of use-case-scoped models, leading to slow queries and confusing variable prompts for business users.
• Building one oversized Consumption Model instead of using Perspectives, resulting in slow live queries and confusing dimension lists for business users.
• Configuring currency conversion without verifying the exchange rate table is complete and current for all relevant periods
• Confusing a fact model with a consumption model and being unsure which object to expose to SAP Analytics Cloud
• Creating associations in the fact model without verifying cardinality, leading to fan-out and duplicated measure values
• Enabling planning write-back on a Consumption Model without verifying that the underlying Fact Model and dimension entities actually support the required version/time keys.
• Exposing too many technical or intermediate calculated columns in the consumption model, confusing business users in SAC
• Forgetting to deploy a Fact Model or Dimension after making changes, so consumers still see the old version in SAC.
• Forgetting to mark a consumption model as planning-enabled, so SAC displays data but blocks user input
• Ignoring key and cardinality mismatches between fact model associations and dimension keys, leading to fan-out or missing rows
• Mismatching the grain of a Business Entity against the Fact Model it is joined to, causing row duplication or incorrect aggregation in SAC stories.
• Mixing technical/source-system field names directly into business entities instead of renaming them to business-friendly labels, hurting adoption.
• Not deploying the underlying Data Builder view before attempting to reference it in Business Builder, causing validation errors
• Not re-deploying downstream fact models and consumption models after a change to an upstream dimension or source view, leaving stale metadata in production.
• Not testing row-level security with a representative restricted user before go-live, only validating with an admin account
• Not understanding that a Consumption Model is a separate, explicitly published artifact and expecting a Fact Model alone to be consumable by all downstream tools.
• Omitting a currency or unit reference column mapping on monetary/quantity measures, so currency conversion or formatting does not work as expected in SAC.
• Recreating near-duplicate dimensions per fact model instead of reusing a shared governed dimension, causing inconsistent KPIs across stories
• Skipping multi-user testing of Data Access Controls, leading to over-exposure or unexpected empty results in production
• Skipping version and time dimension planning during model design, forcing a rebuild once planning requirements are added later
• Treating live connection performance issues as an SAC problem when the root cause is an unoptimized underlying Data Builder view feeding the Fact Model.
• Trying to deploy a fact model before its associated dimensions have been successfully deployed, resulting in confusing dependency errors.

• Always deploy and test a Fact Model and its Consumption Model in a non-production space before promoting to production consumption.
• Always finalize and deploy underlying Data Builder views before starting Business Builder modeling
• Always validate dimension key uniqueness in the source view before building associations in a fact model.
• Always validate join cardinality explicitly when creating associations in a fact model, don't rely solely on auto-suggestions
• Benchmark live query performance against the underlying Data Builder view before assuming a performance issue originates in SAC.
• Confirm currency/unit reference columns exist in source data before configuring currency-aware or unit-aware measures.
• Confirm space-sharing and deployment status whenever a Consumption Model does not appear as expected in the SAC connection picker.
• Deploy objects in dependency order: dimensions first, then fact models, then consumption models, and re-deploy the full chain after upstream changes.
• Design version and time dimensions up front if planning is even a possible future requirement
• Document the full entity-to-consumption chain for each exposed model so support staff can trace defects efficiently
• Document which team owns Data Builder objects versus Business Builder objects to avoid governance conflicts.
• Document which team owns Data Builder objects versus Business Builder objects to maintain clear governance boundaries
• Establish naming conventions (business names vs technical names) early so Business Builder objects are self-explanatory to end users.
• Explicitly review and set correct aggregation behavior for every measure rather than accepting defaults
• Keep calculated and restricted measure logic in the consumption model layer so fact models remain reusable across multiple consumption scenarios
• Keep Data Builder views as the single source of technical transformation logic; use Business Builder purely for business semantics and consumption assembly.
• Keep dimension and fact model naming business-friendly and consistent across spaces to avoid confusion in SAC
• Keep technical view logic in Data Builder and business-facing composition in Business Builder to preserve clear governance boundaries.
• Maintain and monitor currency/unit conversion reference data on a defined refresh cycle
• Restrict edit rights on shared Consumption Models and Business Entities to a governed group, and communicate changes to dependent SAC story owners.
• Sample and manually verify joined data between fact model and dimensions after each significant change, not just after deployment
• Scope consumption models narrowly to specific reporting or planning use cases rather than building one large universal model.
• Standardize on shared, IT-governed dimensions for common business entities and discourage duplicate local dimensions
• Test consumption models with at least one restricted-role test user before releasing to broader audiences
• Test Data Access Controls with multiple representative user roles before promoting a fact model to production consumption
• Use a small pilot fact model to validate the end-to-end flow into SAP Analytics Cloud before scaling to many business models
• Use clear, business-friendly naming and descriptions in the consumption model since this is what end users see directly in SAC
• Use Perspectives to scope Consumption Models to the needs of specific consumer groups instead of exposing one large model to everyone.
• Use test queries or sample data previews after each deployment step to catch row-multiplication or missing-data issues early, before promoting to production spaces.
• Validate associations and cardinalities immediately after creating a fact model rather than after downstream story-building begins
• Validate dimension grain against the Fact Model explicitly before publishing a Consumption Model, especially after any Business Entity change.
• Validate grain and key uniqueness in source views before exposing them as dimensions, since Business Builder assumes clean, de-duplicated master data.

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers commonly probe whether a candidate understands the separation of technical (Data Builder) versus business (Business Builder) modeling layers, why that separation exists for governance, and how a fact model differs from a dimension and a consumption model. Be ready to explain the dependency chain: Data Builder view must exist and be deployed before Business Builder objects can reference it, and describe a realistic scenario where business users self-serve on top of governed data.

Expect questions on how currency/unit conversion is handled, how associations between fact models and dimensions are validated, and how performance issues in a live SAC connection are diagnosed and resolved (usually by tracing back to the underlying Data Builder view). Also be ready to discuss dimension reuse and governance to prevent semantic drift across fact models, and how Data Access Controls are tested before production rollout.

Interviewers assess whether you understand the layered relationship between Data Builder (technical views), Business Builder (Fact Models, Business Entities, Consumption Models, Perspectives) and SAC consumption (live vs imported connections), plus whether you can diagnose grain mismatches, deployment visibility issues, and live-query performance problems rather than only describing the UI steps for building a model.

Interviewers often probe whether a candidate understands the conceptual split between Data Builder (technical) and Business Builder (business-user, semantic) layers in Datasphere, and whether they can explain the object hierarchy: source view -> dimension/fact model -> consumption model. Be ready to explain why this separation supports governance and self-service without contradicting each other, and to contrast it (without overclaiming exact feature parity) with similar semantic-layer concepts in other tools you may have used.

Expect scenario-based questions such as diagnosing inflated totals in a report, which tests understanding of association cardinality and dimension key uniqueness rather than rote UI steps. Be prepared to explain the deployment dependency order (dimensions before fact models before consumption models) and to describe how currency/unit-aware measures are configured, while being clear about what depends on source data quality versus what Business Builder itself can control.

Interviewers assess whether a candidate understands the layered architecture: business entity to fact model to consumption model, and can explain where to troubleshoot specific defect types such as duplicated values, missing input-readiness, or security leakage. Strong answers reference the propagation of row-level security through the layers and the difference between exposing a model for reporting only versus planning-enabled consumption, and can describe a realistic debugging sequence rather than guessing at the fix.