MODLR Architecture

Object hierarchy

MODLR 
 ├─ Gateway (go.modlr.co)
 └─ Client
     ├─ User (Modeller / Analyst / Collaborator)
     └─ Instance (e.g. Production, Development, Test)
         ├─ Model
         │   ├─ Cube
         │   ├─ Dimension
         │   ├─ Element
         │   ├─ Mapping
         │   ├─ Process (Scriptable / Visual)
         │   ├─ Card
         │   ├─ Workview
         │   └─ Application
         │       ├─ Screen (displays added Cards, Workviews, Dashboards, Custom Pages)
         │       ├─ Dashboard
         │       ├─ Custom Page
         │       ├─ Server Side Pages
         │       ├─ Embed Tokens       
         │       ├─ Access Tag
         │       ├─ Excel Add-in
         │       └─ PowerPoint Add-in
         ├─ Instance Security
         ├─ Internal Datastore - MySQL (MariaDB)
         └─ Frontend (Thin)

Objects

MODLR

The overall Corporate Performance Management platform. Everything else in this hierarchy, the Gateway and every Client, sits beneath it.

Path: MODLR

Related entries: What is MODLR?

Gateway

MODLR's central administrative portal, accessed at go.modlr.co, sitting outside of any single Client. It's where Modellers and Analysts log in to reach the Instances they've been added to, and where administrative MODLR functions, such as creating instances and managing client users, are performed. See Accessing MODLR below.

Path: MODLR > Gateway

Client

The top-level object in MODLR and the overall owner of one or more instances. Comparable to a tenant in Active Directory. Example: "Acme Corp" is a client. The client's name sets the naming convention used downstream (e.g. company-name).

Path: MODLR > Client

Related entries: Getting Started, Configuring a new instance

User

A person with access to MODLR, related to a Client (typically their employer) and added to one or more of that Client's Instances. Every user holds one of three roles: Modeller, Analyst, or Collaborator. Modellers and Analysts are, by default, given access to their Client's instances on the Gateway (go.modlr.co), unless Instance Security restricts this. Collaborators only ever reach MODLR through an application: via the Excel Add-in, PowerPoint Add-in, or their Client's Frontend (Thin) (company-name.modlr.cloud). See Accessing MODLR below for how these methods relate.

Path: MODLR > Client > User

Instance

An environment beneath a client (e.g. Production, Development, Test), named using the client's naming convention plus an environment suffix: company-name for production, company-name-dev for development. This carries through to the URL end users access: company-name.modlr.cloud / company-name-dev.modlr.cloud. An instance contains its own models, security configuration, and internal datastore, isolated from other instances. Instances are single-tenanted: there is no overlap of customer data between them.

Path: MODLR > Client > Instance

Internal Datastore

A MySQL (MariaDB) database associated with each instance, used as MODLR's internal data store. Access is restricted so that only modellers (an administrator-associated user type) can configure their own access to it directly. End users can never run their own SQL queries against it, but SQL queries can be embedded into cards, custom pages, or processes for reporting or data processing.

Path: MODLR > Client > Instance > Internal Datastore

Frontend (Thin)

The customer-branded web application hosted on each instance, addressable at the instance's URL (company-name.modlr.cloud). It's the surface through which Applications, Screens, and their content are served to end users, and is how Collaborators, and Modellers or Analysts outside the Gateway, reach MODLR. An instance's Thin isn't tied to a single Application: since an instance can hold multiple models, and each model multiple applications, more than one Application can be configured to serve from the same Thin.

Path: MODLR > Client > Instance > Frontend (Thin)

Related entries: User Interfaces, About Applications, Screens

Model

The configuration layer within an instance. Contains the cubes, dimensions, elements, mappings, processes, and applications that make up a MODLR solution.

Path: MODLR > Client > Instance > Model

Cube

A multidimensional data structure within a model, built from dimensions.

Path: MODLR > Client > Instance > Model > Cube

Dimension

A structural component of a cube (e.g. Account, Time, Entity).

Path: MODLR > Client > Instance > Model > Dimension

Element

An individual member within a dimension.

Path: MODLR > Client > Instance > Model > Element

Mapping

A model-level configuration for translating or aligning data, e.g. between systems or structures.

Path: MODLR > Client > Instance > Model > Mapping

Process

A model-level object (scriptable or visual) used for data processing and automation of tasks, such as click-of-button allocations, nightly loads, on-click loads, archiving datasets, creating mappings, exporting data to other systems, or loading external data into MODLR.

Path: MODLR > Client > Instance > Model > Process

Card

A model-level object that enables reports/interfaces to be built from a drag and drop interface builder, displaying data sourced from one or more cubes. Cards are able to be added as content to one or more screens within an application.

Path: MODLR > Client > Instance > Model > Card

Workview

A model-level object providing a direct view into a cube. Like a Card, a Workview is able to be added as content to one or more screens within an application.

Path: MODLR > Client > Instance > Model > Workview

Instance Security

An instance-level framework governing access control across model components: models, cubes, dimensions, elements, cards, and workviews. See Screen access vs. Instance security below for how this relates to Access Tags.

Path: MODLR > Client > Instance > Security

Application

The frontend layer through which most users interact with MODLR. An application groups a set of screens under a unique identifier and is where access tags are created and allocated to users.

Path: MODLR > Client > Instance > Model > Application

Screen

The resultant web page produced by an application, addressable at a predictable URL (e.g. acmecorp.modlr.cloud/payroll-planning/payroll-review). A screen doesn't own its content, it displays content added to it: a Card or Workview, both of which live at the model level, or a Dashboard or Custom Page, both of which live at the application level.

Path: MODLR > Client > Instance > Model > Application > Screen

Dashboard

An object created within an application, built from its own set of custom widgets (including cards and workviews). Like a Card or Workview, a Dashboard is added as content to a screen rather than belonging to it.

Path: MODLR > Client > Instance > Model > Application > Dashboard

Related entries: Cards in Dashboards, Dashboard Overview

Custom Page

An application-level object built with HTML and JavaScript, similar to standard web development, with reduced use of external libraries due to MODLR's security controls. Added as content to a screen, rather than belonging to it.

Path: MODLR > Client > Instance > Model > Application > Custom Page

Related entries: Custom Pages

Server Side Pages

An application-level object, distinct from Custom Pages: JavaScript that executes on the server rather than in the browser, giving it access to MODLR process functions. Server-side pages aren't displayed on a screen directly; they're called from a client-side custom page (e.g. via ServerClient) to run secure logic or automation.

Path: MODLR > Client > Instance > Model > Application > Server Side Pages

Related entries: Custom Pages, Server-side Pages, Available Functions

Embed Tokens

An application-level object generated directly from a screen: a URL that gives public or password-protected access to that screen without requiring a MODLR login. Access within the embed can be scoped at an element level.

Path: MODLR > Client > Instance > Model > Application > Embed Tokens

Related entries: Embed Tokens, Screens, Access Tags and Application Security

Access Tag

An application-level object specifying what a user can access. Access tags can be scoped to either screen access or element access, but they're typically only used for screen access: element-level access is now better handled by Instance Security, which offers more flexibility than element access tags. See Screen access vs. Instance security below for how Access Tags relate to model Security.

Path: MODLR > Client > Instance > Model > Application > Access Tag

Excel Add-in

Gives users the flexible, familiar modelling experience of regular Excel, while keeping the underlying data centralised in MODLR rather than scattered across individual workbooks. It connects to a MODLR application, so all screen access and model security still apply, and provides access to cards, workviews, individual cells (via cubeGet), and other functions.

Path: MODLR > Client > Instance > Model > Application > Excel Add-in

PowerPoint Add-in

Connects to a MODLR application in the same way, but access is limited to cards only, governed by model security.

Path: MODLR > Client > Instance > Model > Application > PowerPoint Add-in

Accessing MODLR

There are four ways to reach MODLR. Which ones are available to a given User depends on their role.

Method	Description	Modeller	Analyst	Collaborator
Gateway (`go.modlr.co`)	The primary web-based administrative portal: build models, applications, and manage instance configuration.	Yes	Yes	No
Thin (Customer Frontend) (`company-name.modlr.cloud`)	The customer-branded application front end, at a Client's instance URL.	Yes, subject to model security and access tags	Yes, subject to model security and access tags	Yes, limited to their assigned applications and Access Tags
Excel Add-in	Connects to a MODLR application from within Excel.	Yes, subject to model security and access tags	Yes, subject to model security and access tags	Yes, limited to their assigned applications and Access Tags
PowerPoint Add-in	Connects to a MODLR application from within PowerPoint, limited to cards.	Yes, subject to model security and access tags	Yes, subject to model security and access tags	Yes, limited to their assigned applications and Access Tags

Collaborators never get Gateway access: everything they see is reached through an application, and scoped by the Access Tags allocated to them.

Even Modellers are not exempt from security once they're accessing MODLR through an application (Thin, Excel, or PowerPoint): their access there is still governed by model security and access tags, the same as any other role. A Modeller's Gateway (back-end) access can also be restricted by model security, though it's uncommon to configure an instance that restricts a Modeller's own back-end access.

Clarifications

Screen access vs. Instance security

These are connected but separate layers. To open a screen at all, a user just needs an Access Tag that grants them access to it. Once inside, that user's model Security determines what they can actually see and do there. So a user can hold an access tag for a screen and still find parts of it restricted, or blank, if their security role doesn't cover the underlying cubes, dimensions, or elements the screen is built from. See MODLR Security for how Instance Security and Application Security (Access Tags) each work.

MODLR Architecture ​

Object hierarchy ​

Objects ​

MODLR ​

Gateway ​

Client ​

User ​

Instance ​

Internal Datastore ​

Frontend (Thin) ​

Model ​

Cube ​

Dimension ​

Element ​

Mapping ​

Process ​

Card ​

Workview ​

Instance Security ​

Application ​

Screen ​

Dashboard ​

Custom Page ​

Server Side Pages ​

Embed Tokens ​

Access Tag ​

Excel Add-in ​

PowerPoint Add-in ​

Accessing MODLR ​

Clarifications ​

Screen access vs. Instance security ​