--- url: /technical/screens.md description: >- A Screen is a web page on an Application, made of a header, its content, and a footer. Headers and footers hold a menu or a custom page; the content holds a dashboard, workview, card or custom page. --- # Screens A **Screen** is a web page on an [Application](/technical/about-applications), served at its own route. Every screen is made of three parts: | Part | Holds | | | :--- | :--- | :--- | | **Header** | A [Menu](/technical/menus) or a [Custom Page](/technical/custom-pages) | Optional | | **Page** | The screen's content - see below | Required | | **Footer** | A [Menu](/technical/menus) or a [Custom Page](/technical/custom-pages) | Optional | A screen doesn't own any of this. It references objects built elsewhere, which is why the same menu can head every screen in an application, and the same workview can appear on more than one. ![A rendered screen, annotated to show the Menu forming the screen header above the Workview that forms the screen content](/annotated_workview.png) ## What a screen can display The **Page** is the body of the screen, shown between the header and footer. It can be any one of: | Content | Built in | Documentation | | :--- | :--- | :--- | | Dashboard | The application | [Dashboards](/technical/dashboard-overview) | | Custom Page | The application | [Custom Pages](/technical/custom-pages) | | Workview | The model | [Creating Workviews](/technical/creating-workviews) | | Card | The model | [Cards in Screens](/card-guides/cards-in-screens) | A Dashboard is the way to put several things on one screen - a screen's Page takes a single object, so a Card added directly fills the screen on its own. Users can only reach the screens granted to them by their [access tags](/technical/access-tags-and-application-security). ## Navigating between screens Navigation is a separate concern from content, and there's more than one route between screens: | Route | Where it lives | Best for | | :--- | :--- | :--- | | [Menus](/technical/menus) | Attached to a screen as its header or footer | Fixed, application-wide navigation available from every screen | | [Custom Pages](/technical/custom-pages) | As a header or footer, in place of a Menu | Navigation a Menu can't express | | Links on [Cards](/card-guides/) | Card components, such as a [Button](/card-guides/button) | Contextual jumps from a report into related detail | | [Link To Another Workview Using Formula](/set-instructions/link-to-another-workview-using-formula) | A Workview's set instructions | Making row or column headers clickable, per element | The last two are what turn a report into a drill path: a summary by department where clicking a department opens that department's detail screen, rather than the user going back to the menu and picking it manually. Both can pass the clicked context through as a query string argument, where the argument name is the **dimension's ID** - `department-detail?6ad83e6275498f152a2d74e1784c4c21=Sales`. Values are wrapped in [`URLENCODE`](/cube-functions/urlencode) so names containing spaces or ampersands survive. The destination doesn't read the URL itself. The value is written to the browser's local storage against that dimension, and selectables bound to the same ID populate themselves from it - always for a Workview's title selectables, and for a [Card Selectable](/card-guides/selectable) when its **Persist** property is set to `Yes`. ## Setting the homepage of an application One screen per application can be marked as the **initial landing page**, using the checkbox of that name on the screen itself. This is the screen a user lands on when they open the application without a path. ![The Edit Screen dialog with the Is initial landing page checkbox selected](/screen-is-initial-landingpage.png) | The user opens | They land on | | :--- | :--- | | `https://example.modlr.cloud` | The screen flagged as the initial landing page | | `https://example.modlr.cloud/example-route/` | That specific screen, after signing in | Because a path-specific URL survives the login redirect, a link to a particular screen can be shared directly and will still deliver the user to that screen rather than to the landing page. The [Home](/technical/menus#home-and-the-initial-landing-page) helper link in a [Menu](/technical/menus) resolves to whichever screen carries this flag, rather than to a fixed URL. ## Creating a new Screen in your application ![The New Screen dialog, with Name, Route, Header, Page and Footer fields](/add-application-modal.png) * **Name** - names the screen in the Gateway at `go.modlr.co`. It does not affect what the screen shows. * **Route** - the URL path of the screen, appended to the application's own path (shown as a fixed prefix in the dialog). If your application is accessed at `https://example.modlr.cloud`, this screen is reached at `https://example.modlr.cloud/*route*`. * **Header\*** - a [Menu](/technical/menus) or a [custom page](/technical/custom-pages) to show above the content. A header usually contains the application's navigation bar. * **Page** - the screen's content: a Dashboard, Custom Page, Workview or Card. Shown between the header and footer when those are defined. Cards appear in this dropdown prefixed with `Card -`. * **Footer\*** - a [Menu](/technical/menus) or a [custom page](/technical/custom-pages) to show below the content. A footer usually contains Copyright text, Contact Us, Addresses for Support, etc. **\*Optional** A completed screen brings the three parts together - here a Menu as the header, a Dashboard as the page, and a Custom Page as the footer: ![The Edit Screen dialog, annotated to show Route, Header, Page, Footer and the Is initial landing page checkbox](/edit-screen-dialog.png) Before a screen is accessible to the front-end, it first needs to be added to an [access tag](/technical/access-tags-and-application-security).