MODLR Architecture

Object hierarchy

Everything in MODLR nests. A Client owns one or more Instances; an Instance holds its Models, its security and its own datastore; a Model holds the objects you build with, and its Applications hold what end users actually see.

MODLR

Gatewaygo.modlr.co - one, shared by every Client

Clientthe tenant, e.g. Acme Corp

UsersModeller · Analyst · Collaborator

Instancecompany-name.modlr.cloud - Production, Dev, Test

Model

CubeDimensionMappingTableVariableProcessScheduleCardWorkviewShortcutStylePackage

Applicationwhat end users reach

ScreenDashboardCustom PageServer Side PageEmbed TokenAccess TagExcel Add-inPowerPoint Add-in

Instance Securitymodels, cubes, dimensions, elements

Internal DatastoreMySQL (MariaDB)

Frontend (Thin)serves the Applications

The same hierarchy as a text tree

MODLR 
 ├─ Gateway (go.modlr.co)
 └─ Client
     ├─ User (Modeller / Analyst / Collaborator)
     └─ Instance (e.g. Production, Development, Test)
         ├─ Model
         │   ├─ Cube
         │   ├─ Dimension
         │   │   ├─ Element
         │   │   ├─ Hierarchy
         │   │   └─ Alias
         │   ├─ Mapping
         │   ├─ Table
         │   ├─ Variable
         │   ├─ Process (Scriptable / Visual)
         │   ├─ Schedule
         │   ├─ Card
         │   ├─ Workview
         │   ├─ Shortcut
         │   ├─ Style
         │   ├─ Package
         │   └─ 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, and the unit a cell address is built from. Elements are either Numeric, String, or Parent (Consolidation), the last of which exists only inside a Hierarchy.

Path: MODLR > Client > Instance > Model > Dimension > Element

Hierarchy

A tree built over a dimension's flat element list, defining how elements consolidate into parents. A dimension can hold several hierarchies sharing the same leaf elements, each giving a different aggregation view of them.

Path: MODLR > Client > Instance > Model > Dimension > Hierarchy

Alias

An alternative display name for an element, used where the element's principal name is a code or otherwise unfriendly. A dimension can hold multiple alias sets.

Path: MODLR > Client > Instance > Model > Dimension > Alias

Mapping

A model-level lookup table associating elements on one set of dimensions with elements on another. Mappings supply the relationship between two cubes whose structures don't share an axis, and are read from a cube formula via MAPPING and LINKBY.

Path: MODLR > Client > Instance > Model > Mapping

Table

A flat relational table held in the instance's Internal Datastore and listed in the model. Used as an ETL staging area on the way into Dimensions and Cubes, or for structured data that has no natural multidimensional shape. Tables in external databases connected over JDBC aren't model Tables and aren't listed here, though Processes can read and write them.

Path: MODLR > Client > Instance > Model > Table

Related entries: Tables, Table Functions, Datasources, SQL Table (card component)

Variable

A model-scoped key-value pair, readable from Cards, Workviews, Cube Formulas, Processes, and the Excel Add-in, so a value is maintained in one place rather than duplicated everywhere it's used.

Path: MODLR > Client > Instance > Model > Variable

Related entries: Model Variables, Using Model Variables, Reserved Variables

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

Schedule

A model-level object that names a Process and an interval - monthly, weekly or daily, each at a given time - running that Process automatically rather than on demand. Finer intervals can be created through the API using cron-format arguments. Schedule times are in UTC, as all MODLR servers run on UTC +0000.

Path: MODLR > Client > Instance > Model > Schedule

Related entries: Scheduling Processes, Creating Processes, Restful API

Shortcut

A folder grouping model objects of any type for quick access, independent of where those objects actually live in the model. Used to gather the objects involved in one operational task, such as a month-end close.

Path: MODLR > Client > Instance > Model > Shortcut

Related entries: Shortcuts, Model Objects

Style

A model-wide library of named CSS formats used in Workviews. Cards have their own separate style system. Reached from the model's Actions menu rather than the navigation panel.

Path: MODLR > Client > Instance > Model > Style

Package

MODLR's proprietary export/import file format (.package) for moving pre-built model objects between models or instances. Also reached from the model's Actions menu.

Path: MODLR > Client > Instance > Model > Package

Related entries: Packages, Model Objects

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.

Security Package

Formula Validation

References in Formula

Access Tags and Application Security

MODLR Architecture ​

Object hierarchy ​

Objects ​

MODLR ​

Gateway ​

Client ​

User ​

Instance ​

Internal Datastore ​

Frontend (Thin) ​

Model ​

Cube ​

Dimension ​

Element ​

Hierarchy ​

Alias ​

Mapping ​

Table ​

Variable ​

Process ​

Card ​

Workview ​

Schedule ​

Shortcut ​

Style ​

Package ​

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 ​

MODLR Architecture

Object hierarchy

Objects

MODLR

Gateway

Client

User

Instance

Internal Datastore

Frontend (Thin)

Model

Cube

Dimension

Element

Hierarchy

Alias

Mapping

Table

Variable

Process

Card

Workview

Schedule

Shortcut

Style

Package

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