--- url: /technical/application-objects.md description: >- Every object type that lives inside an application, grouped the way an application uses them, with links to the documentation for each. --- # Application Objects Opening an application presents a navigation panel grouping every object type it can contain. This page is a map of that panel - one entry per object, linking to where it's documented. ![The Application View, showing navigation between Contributors, Access Tags, Screens, Menus and the Dashboard and Custom Page editors](/gateway-tour-application-view.png) For the equivalent map of a model, see [Model Objects](/technical/model-objects). For how applications sit beneath a model and instance, see [MODLR Architecture](/technical/modlr-architecture). ## Content What a user actually looks at. A Screen doesn't own its content - it displays content defined elsewhere, either at the model level (Cards and Workviews) or at the application level (Dashboards and Custom Pages). | Object | Description | Documentation | | --- | --- | --- | | Screens | The web pages an application serves, each at its own route. A screen is a header, its content, and a footer. One screen per application can be flagged as the initial landing page. | [Screens](/technical/screens) | | Dashboards | Built within the application from its own set of widgets, including Cards and Workviews. Added to a screen as content, and the way to put several things on one screen. | [Dashboards](/technical/dashboard-overview), [Cards in Dashboards](/card-guides/cards-in-dashboards) | | Custom Pages | Pages built with HTML, CSS and JavaScript, for interfaces the standard objects can't express. Also usable as a screen's header or footer. | [Custom Pages](/technical/custom-pages) | | Server-Side Pages | JavaScript that runs on the server rather than in the browser, with access to process functions. Not displayed directly - called from a client-side custom page to run secure logic. | [Server-side Pages](/custom-pages/server-side-pages), [Available Functions](/custom-pages/server-side-functions) | Content originating in the model - [Cards](/card-guides/) and [Workviews](/technical/creating-workviews) - is added to screens the same way, but is built and maintained in the [Model Workspace](/technical/model-objects) rather than here. ## Navigation | Object | Description | Documentation | | --- | --- | --- | | Menus | Fixed navigation, built from Screens, custom links and helper links, and attached to a screen as its header or footer. Supports two levels, the second rendering as a dropdown. | [Menus](/technical/menus) | A Menu isn't the only way between screens. Links on [Cards](/card-guides/button), and the [Link To Another Workview Using Formula](/set-instructions/link-to-another-workview-using-formula) set instruction, both navigate from within a screen's content - passing the clicked element through as a query string argument, so the destination scopes itself to it. See [Navigating between screens](/technical/screens#navigating-between-screens). ## Configuration | Object | Description | Documentation | | --- | --- | --- | | External Assets | Third-party JavaScript and CSS libraries included in the application, for [Custom Pages](/technical/custom-pages) to use. | [External Assets](#external-assets) below | ### External Assets [Custom Pages](/technical/custom-pages) are built with ordinary HTML, CSS and JavaScript, but can't pull in arbitrary third-party libraries at will - MODLR's security controls restrict what a page may load. **External Assets** is the sanctioned route: libraries are registered once against the application, and are then available to the custom pages within it. They're managed from the application's **Manage** page. Each asset is added with four fields: | Field | Description | | :--- | :--- | | **Type** | `JavaScript` or `CSS`. | | **Name** | A label identifying the asset in the list, e.g. `dataTables`. | | **URL** | Where the file is fetched from, typically a CDN. | | **Integrity** | An optional [Subresource Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) hash, e.g. `sha256-...`. | A library shipping both script and stylesheet needs two entries - one of each Type - since an asset is either JavaScript or CSS, not both. A typical set is `dataTables` (JavaScript), `dataTables CSS` (CSS) and `jqueryui` (JavaScript). ::: tip Use the Integrity hash where the CDN publishes one An integrity hash is the browser's check that the file it fetched is the file you registered: if the delivered bytes don't match the hash, the browser refuses to run it. That matters for a resource loaded from a third-party host, where a compromised or swapped file would otherwise execute with the same access as your own code. Most CDNs publish the hash alongside the URL - the field is optional, but worth populating whenever one is available. ::: ## Access Two separate layers decide who reaches an application and what they can do inside it. | Object | Description | Documentation | | --- | --- | --- | | Contributors | The users who can access the application, and the Access Tags allocated to each of them. | [Contributors](/technical/contributors), [Adding Collaborators](/technical/adding-collaborators) | | Access Tags | Specify what a user can access. Scoped to either screen access or element access, though element-level access is now better handled by Instance Security. | [Access Tags and Application Security](/technical/access-tags-and-application-security), [Screen Access Tags](/technical/access-tags-screen), [Element Access Tags](/technical/access-tags-element) | ::: tip Access tags aren't the whole story An Access Tag decides whether a user can open a screen. What they can then see and do on it is governed by [Instance Security](/technical/instance-security), against the cubes, dimensions and elements the screen is built from. A user can 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). ::: ## Distribution Ways of getting an application's content to people beyond the standard web front end. | Object | Description | Documentation | | --- | --- | --- | | Embed Tokens | A URL giving public or password-protected access to a single screen without a MODLR login. Access within the embed can be scoped to element level. | [Embed Tokens](/technical/embed-tokens) | | Excel Add-in | Connects Excel to the application, giving access to Cards, Workviews and individual cells via `cubeGet`, with screen access and model security still applying. | [Excel Add-in](/excel-addin/), [Cards in Excel](/excel-addin/cards-in-excel), [Live Workview](/excel-addin/live-workview) | | PowerPoint Add-in | Connects PowerPoint to the application, limited to Cards. | [PowerPoint Add-in](/powerpoint-addin/), [Cards](/powerpoint-addin/cards) | ## Related * [About Applications](/technical/about-applications) - what an application is and who reaches it * [Creating an Application](/technical/creating-application) - creating an application in the first place * [Model Objects](/technical/model-objects) - the equivalent map for a model * [User Interfaces](/technical/user-interfaces) - the surfaces an application is served through