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.
Explanation
A Business Builder Consumption Model is the final artifact that business users interact with when building SAC stories or planning models on top of SAP Datasphere. It is assembled from one or more Fact Models plus the Business Entities (dimensions) that describe them, and it can be split into Perspectives so that each SAC-facing object exposes only a relevant subset of measures and dimensions rather than one enormous, unwieldy model. The practical value of this layer is separation of concerns: technical modelers work in the Data Builder building views with joins, unions, and calculated columns against source tables, while business modelers work in Business Builder assembling those views into Fact Models (measures and their grain) and Business Entities (reusable dimension definitions with attributes, hierarchies, and text tables). This separation lets a central team certify and govern the technical semantic layer while decentralized business teams compose consumption-ready models at the pace the business needs, without needing SQL or deep ETL knowledge. Design flow typically looks like this: first, technical views are built and deployed in Data Builder and marked as analytic-model-ready sources. Second, in Business Builder, a Fact Model is created referencing one of those views, defining which columns are measures and which are the associated dimensions at the correct grain (for example, a Sales Fact Model at Sales Order Item level). Third, Business Entities are created or reused for dimensions like Customer, Product, or Cost Center, each entity abstracting the underlying table/view so multiple Fact Models can share consistent dimension definitions and hierarchies. Fourth, the Fact Model and its Business Entities are combined into a Consumption Model, and Perspectives are optionally defined to present curated, role-specific views of that model to consumers. Once deployed, the Consumption Model (or a specific Perspective) becomes selectable as a data source when creating a new model or story in SAP Analytics Cloud, when the two systems are connected via the live data connection to SAP Datasphere. In live mode, SAC does not import or replicate the data; every story refresh and every filter/drill interaction issues a live query back into Datasphere, so query performance in the Consumption Model directly determines dashboard responsiveness. This differs from an acquired/imported SAC model, where data snapshots are loaded into SAC's in-memory engine and refreshed on a schedule; imported models are faster to render but go stale between refreshes and duplicate storage. For planning use cases, the Consumption Model can be enabled with planning-relevant settings so that SAC planning models can write back through it, provided the underlying Fact Model grain and dimension entities support the required write-back keys. Not every Business Builder object is planning-ready by default; the modeler must confirm the Fact Model exposes the correct version/time dimensions and that the Business Entities used support the write-back pattern expected by SAC planning, and this readiness must be validated per landscape since planning enablement options can evolve. Operationally, common troubleshooting scenarios include: a Consumption Model not appearing in SAC's data source picker, which is usually a deployment or space-sharing issue (the model must be deployed and the SAC connection's target space must have visibility to it); slow live queries, which usually trace back to an unoptimized Fact Model view (missing filters pushed down, overly wide joins, or a Business Entity carrying unnecessary attributes that get pulled into every join); and mismatched dimension grains, where a Business Entity used in a Consumption Model does not align with the Fact Model's grain, causing incorrect aggregation or duplicated rows in the SAC story. Governance-wise, it's important to track who can edit versus who can only consume Consumption Models and Perspectives, since business users given edit rights can inadvertently change measure definitions that downstream SAC stories depend on, silently altering reported numbers without any code review process typical of a technical development pipeline.
Real project scenario
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.
Common mistakes
ā¢ Assuming a Consumption Model built in Business Builder is automatically visible in SAC without confirming deployment and space-sharing configuration. ā¢ Building one oversized Consumption Model instead of using Perspectives, resulting in slow live queries and confusing dimension lists for business users. ā¢ Mismatching the grain of a Business Entity against the Fact Model it is joined to, causing row duplication or incorrect aggregation in SAC stories. ā¢ 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. ā¢ Allowing broad edit access to Consumption Models, letting business users change shared measure logic that other teams' stories silently depend on. ā¢ Treating live connection performance issues as an SAC problem when the root cause is an unoptimized underlying Data Builder view feeding the Fact Model.
Best practices
ā¢ Keep technical view logic in Data Builder and business-facing composition in Business Builder to preserve clear governance boundaries. ā¢ Use Perspectives to scope Consumption Models to the needs of specific consumer groups instead of exposing one large model to everyone. ā¢ Validate dimension grain against the Fact Model explicitly before publishing a Consumption Model, especially after any Business Entity change. ā¢ Confirm space-sharing and deployment status whenever a Consumption Model does not appear as expected in the SAC connection picker. ā¢ Restrict edit rights on shared Consumption Models and Business Entities to a governed group, and communicate changes to dependent SAC story owners. ā¢ Benchmark live query performance against the underlying Data Builder view before assuming a performance issue originates in SAC.
Interview angle
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.