Customizing Scaler end-to-end: from inputs to dashboards

Scaler's custom features let you reshape the platform to match how your organization measures, models, and reports performance. This guide walks through how those capabilities fit together, from input fields to dashboards, with worked examples of common workflows.

If you only need one capability (for example, just custom fields), jump to that section and use the deep-dive article linked there. If you want the picture of how everything connects, and how clients build full LP DDQs, scorecards, and asset-level decarbonization views entirely inside Scaler, read this end-to-end.

The custom feature suite is built around one principle: every step from data collection to reporting can be tailored to your organization. Each feature below works on its own, and the value compounds when you connect them.

Read end to end, the path is: a custom input becomes a custom metric, becomes a tracked target, appears as a chart in a custom dashboard, then gets shared with an LP.

What it is: fields you define to collect data Scaler doesn't capture by default. Why you'd use it: to stop maintaining parallel spreadsheets for organization-specific data points, and to feed them straight into your analytics and dashboards.

Any data point you would otherwise keep in a parallel Excel sheet (bike-rack counts, heat-pump installation type, biodiversity score, lease-up date) can be modeled as a custom field. Five field types are supported: number (with min/max), text, date, dropdown (configurable options), and boolean.

Once a field is created at company level, it flows automatically into:

Using custom fields in Scaler covers the full configuration flow.

What it is: build your consumption estimates and unit conversions as formulas inside Scaler, the same logic you would otherwise keep in Excel. Why you'd use it: keep estimations next to your actual data with a full audit trail, instead of in spreadsheets that break and cannot be traced.

If you've written a formula in Excel or Google Sheets, this works the same way: you write the calculation once and Scaler runs it for the asset. Anything in curly braces, like {reporting.gross_floor_area}, means "use this asset's value for that field."

Replace external estimation logic with formulas built directly in Scaler, using familiar Excel-style syntax. Supported functions are IF, XLOOKUP, ROUND, MIN, MAX, and ABS, alongside arithmetic and comparison operators. A formula can reference standard asset and reporting attributes (for example {reporting.gross_floor_area}, {asset.postal_code}) and any of your own custom fields by name (for example {Installation Type}). Every computed value carries an audit trail showing the formula, its inputs, and the result, so auditors get the full chain of logic without exporting anything.

Start simple, then build up.

Put together, those three steps are the worked example below. As you type, Scaler suggests field names and shows the computed value live, so you can check each step before saving.

Worked example: estimating cooling consumption, adjusted for location

Read left to right: if the asset's Installation Type is "Cooling", multiply its gross floor area by an intensity benchmark (1.1 × 38.20 kWh/m²), then divide by the location-specific conversion factor looked up from the asset's postal code; otherwise return 0. Here, Installation Type is a custom dropdown field you created earlier (with an option called Cooling), not the built-in Type of installation field. A formula can branch on any custom field you define. The computed value (for example 91,612.24 kWh) appears as soon as the formula validates, and the formula, every input field, and the lookup table it called are all preserved in the audit trail.

What it is: a stored two-column lookup, a key and a value, that a formula calls by name to return the matching value. Why you'd use it: when a mapping is too large or fiddly to enter per asset, store it once and look it up. Common patterns:

Copy and paste from existing Excel reference sheets. Scaler reads them the same way x-lookup does in a spreadsheet. Tables scale to thousands of rows (a full postal-code-to-conversion-factor mapping can hold 8,000+ entries), and you paste them straight from Excel or Google Sheets.

What it is: the CO2 factors Scaler applies to consumption to calculate emissions. Why you'd use it: when you need to match a specific dataset, region, or methodology rather than Scaler's defaults.

Override Scaler's default factors (CRREM and IEA-aligned) with your own. Editable at state and e-grid sub-region level for location-based, and supplier region for market-based. Editable inline per cell or multiple cells copy/pasted from a spreadsheet.

What it is: saved KPI tables built from any standard or custom data in Scaler. Why you'd use it: to produce the recurring reporting tables each stakeholder needs (sustainability team, fund managers, GRESB, SFDR, GRI) without rebuilding them by hand.

The Metrics dashboard is where you build reporting tables. Rows are KPIs (energy intensity, GHG emissions, water, custom number fields). Columns are reporting years. Both are reorderable and saveable per stakeholder view.

Aggregation options per metric: Sum, Average, and Weighted average for number fields, and Count if for dropdown and boolean custom fields — counting the assets whose value matches your selection (for example, assets with heat-pump or electric heating). Like-for-like percentages between any two years are calculated automatically. You can keep several named metric sets side by side (for example Main, GRESB, SFDR PAI, and a GRI Annual Report view) and switch each between Active in analytics and Active in reports.

Custom fields surface here automatically: number fields (a Biodiversity score, say) as summable or averageable metrics, and dropdown or boolean fields as countable ones.

Custom Metrics dashboard covers the full configuration flow.

What it is: the goals and external comparators you measure performance against. Why you'd use it: to align a portfolio to a net-zero or Paris/CRREM trajectory and see, per asset, who is on or off track.

Three target types sit at portfolio level: single-year targets, multi-year pathways (CRREM, custom Paris-aligned, or fully manual year-by-year), and benchmarks (external comparators).

Asset-level target overlay: set a portfolio-wide target (for example, 55% EUI reduction by 2040 from a 2025 baseline) and Scaler applies it proportionally to every asset. The Asset List view shows on-track or off-track status per asset, so you can sort by gap and focus retrofit planning where it is needed.

All targets can be linked to GRESB target reporting and scoped by property subtype and country.

Setting and viewing Targets, Pathways & Benchmarks covers the full configuration flow.

What it is: stakeholder-ready pages of charts and narrative built from everything above. Why you'd use it: to package data for a specific audience (an LP, the board, IR) and share it live, without exporting to slides or handing over platform access.

The Custom Dashboard Builder turns all of the above into stakeholder-ready visualizations. Five chart types (bar, line, area, pie, doughnut), weighted aggregations, free-form text widgets, target overlays, and external sharing.

Custom charts can be normalised in two ways, configured in two different places. On a consumption metric, the per selector (Data Source tab) divides the total by a denominator you choose, such as GIA, GUA, gross asset value, or beds, effectively building your own use intensity; for reference, Scaler's standard use intensity divides consumption by active floor area. On a metric that is already an intensity, Weight by (Options tab) controls how much each asset contributes to the portfolio-level figure: gross floor area by default, or alternatives like gross asset value, beds, or a Number-type custom field for specific cases such as hospitality portfolios weighting by beds. The full option lists are in Custom Dashboard Builder.

The most common pattern: combine custom inputs, custom metrics, and standard ESG data into a single dashboard tailored to an LP's DDQ. Add text widgets for narrative answers. Share the dashboard with the LP's Scaler user, who accesses a read-only view secured by two-factor authentication, so your data stays inside the platform.

Each chart pulls live data, so a DDQ dashboard built once stays current automatically for every reporting cycle. If the LP isn't already a Scaler user, your Account Operations representative can set them up with the right access level.

A typical LP DDQ asks for portfolio-level EUI by property type, scope 1 plus 2 emissions trend, certifications coverage, and narrative answers on climate strategy. To build this once and reuse it every year:

Next reporting cycle: review the dashboard, update narrative widgets if needed, the same shared access stays current.

To track a biodiversity score across the portfolio with monitoring and reporting:

If you have not set up custom fields yet, start with Using custom fields in Scaler. If inputs are in place but the analytics side is not being used to its full extent, Custom Metrics dashboard and Custom Dashboard Builder are the next reads. If you are deep in the custom feature set already and want help connecting it for a specific use case (fund-level reporting, LP DDQs, decarbonization tracking), your Account Operations representative can walk through it on a call.