---
url: /technical/about-applications.md
description: >-
  An application is a curated section of a single model, presenting a set of
  screens to end users - and the only way a Collaborator ever reaches MODLR.
---

# About Applications

An application is a curated section of a single [Model](/technical/model-objects). Applications provide users with a set of screens which assist in directing the user through a business function such as a Budgeting Round, Profitability Analysis or Regular Report.

Where the Gateway exposes the whole model to whoever builds it, an application exposes a deliberate subset of that model to the people who need to use it - the screens relevant to their task, scoped to the data they're permitted to see.

## Who reaches an application

An application is the only way a [Collaborator](/technical/user-roles) ever reaches MODLR - through the [Thin](/technical/user-interfaces) at the instance URL, the [Excel Add-in](/excel-addin/), or the [PowerPoint Add-in](/powerpoint-addin/). [Modellers and Analysts](/technical/user-roles) can reach an application too, and are subject to the same access rules when they do.

Access is decided in two independent layers:

* **[Access Tags](/technical/access-tags-and-application-security)** decide whether a user can open a given screen at all.
* **[Instance Security](/technical/instance-security)** decides what they can see and do once inside it, against the cubes, dimensions and elements the screen is built from.

A user can therefore hold a tag for a screen and still find parts of it blank. See [Screen access vs. Instance security](/technical/modlr-architecture#screen-access-vs-instance-security).

## An application's structure

A model can hold more than one application, and an instance can serve several applications from the same [Thin](/technical/user-interfaces). Within one application:

* **[Screens](/technical/screens)** are the pages users open, each at its own route. A screen is a header, its content, and a footer.
* The **content** is a [Dashboard](/technical/dashboard-overview), [Custom Page](/technical/custom-pages), [Workview](/technical/creating-workviews) or [Card](/card-guides/cards-in-screens) - the first two built in the application, the last two in the model.
* **[Menus](/technical/menus)** provide the fixed navigation between screens, attached as a header or footer.

For the full list of object types an application contains, see [Application Objects](/technical/application-objects).

## Managing an application

An application's own settings live on its **Manage** page, separate from the objects it contains.

![The Manage Application page, showing Application Data, External Assets, Embed Tokens and the Danger Zone](/manage-application.png)

| Setting | Purpose |
| :--- | :--- |
| **Application Name** | The application's name in the Gateway. |
| **Route** | The path segment the application is served under. See [Routes and multiple applications](#routes-and-multiple-applications) below. |
| **Show Navigation Bar** | Whether MODLR's default navigation bar is displayed. Turn it off when the application supplies its own navigation through a [Menu](/technical/menus) or a [Custom Page](/technical/custom-pages) header. |
| **External Assets** | Third-party JavaScript and CSS to include in the application - see [External Assets](/technical/application-objects#external-assets). |
| **Embed Tokens** | URLs giving access to a single screen without a login - see [Embed Tokens](/technical/embed-tokens). |

::: danger Deleting an application
The Danger Zone's **Delete this Application** is not recoverable. Screens, Menus, Dashboards and Custom Pages belong to the application and go with it - though Cards and Workviews, which live in the model, are unaffected.
:::

### Routes and multiple applications

A model can hold several applications, and an instance can serve applications from more than one model, all from the same [Thin](/technical/user-interfaces). Since they share a hostname, **each application needs a distinct route** so their screens don't collide.

The usual arrangement is to leave the primary application's Route empty and give every other application one:

| Application | Route | A screen at `screen-url` is served from |
| :--- | :--- | :--- |
| Primary | *(empty)* | `example-instance-name.modlr.cloud/screen-url/` |
| Secondary | `secondary-application` | `example-instance-name.modlr.cloud/secondary-application/screen-url/` |

So the primary application answers at the bare instance URL, and each additional application is namespaced beneath its own route. Two applications sharing a route - or both left empty - leaves their screens ambiguous, so give every application after the first a route of its own.

This also applies to the [initial landing page](/technical/screens#setting-the-homepage-of-an-application): the flagged screen is what loads at the application's route, meaning the primary application's landing page is what a user reaching the bare instance URL sees.

## Related

* [Application Objects](/technical/application-objects) - every object type inside an application
* [Creating an Application](/technical/creating-application) - creating an application in the first place
* [Screens](/technical/screens) - the pages an application serves
* [MODLR Architecture](/technical/modlr-architecture) - how applications sit beneath a model and instance