Analyticsbeginner
Building Analyses: Criteria, Layout & Views
Explain the core workflow of building an OBIEE analysis — selecting criteria columns, adding filters, and composing views for presentation.
An Analysis (formerly called a "Request" or "Answer") is the fundamental reporting object in OBIEE — everything else (dashboards, agents, action links) is built on top of one or more analyses. Interviewers ask about this because it's the day-to-day bread and butter of a BI developer's job, and fluency here signals real hands-on time in the tool.
The Criteria tab is like choosing your ingredients and recipe once; the Results tab is like deciding whether to plate that same dish as a formal course, a buffet spread, or a photo for the menu — same food, different presentations.
Key Concepts
1
Building an analysis starts on the Criteria tab: you pick a subject area, drag presentation columns into the selection, optionally apply column formulas (adding calculations directly in the analysis rather than the RPD, for one-off logic that doesn't warrant a permanent logical column), and add filters to constrain the result set. Filters can be simple (Region = 'APAC') or based on another saved analysis/SQL query (a filter based on results of another analysis), and can reference presentation variables or session/repository variables for dynamic behavior.
Criteria tabfiltersfilter based on results of another analysispresentation variablessession/repository variables
2
Once criteria are set, the Results tab is where you compose views — the visual representations of the same underlying data: a Title, a Table, a Pivot Table, one or more Graphs, a Filters view (documenting applied filters), and a Compound Layout that arranges multiple views together into the final presentation. Each view can have its own conditional formatting, column properties (data format, aggregation rule override), and sort order, all without re-running the criteria — because views are just different renderings of the same result set.
Results tabviewsCompound Layout
3
A well-built analysis balances reusability (columns and filters that make sense across many use cases) against over-engineering (cramming too many optional columns "just in case") — interviewers sometimes probe this design judgment directly by asking how you'd structure an analysis meant to be reused across five different dashboard pages.