Naming (Drivers)
This article describes how to name drivers in Model Reef so they are easy to understand and reuse across variables and branches.
You will learn:
What driver names should communicate.
Naming patterns for economic, operational and modifier drivers.
How to distinguish driver names from variable names.
How to keep the Data Library tidy as the number of drivers grows.
1. What a driver name should communicate
A driver name should answer three questions:
Examples:
Driver - Price - SaaS Seat - GlobalDriver - Volume - Active Users - UKDriver - Conversion Rate - Free to Paid - OnlineDriver - Wage Inflation - AUDriver - FX Rate - GBP to USD
When you see a driver in a formula, the name alone should make it clear what it means.
2. Recommended naming pattern
A helpful pattern is:
Driver - [Type] - [Subject] - [Qualifier]
Where:
Type describes the general nature of the driver, for example
Price,Volume,Rate,Inflation,Index,FX Rate.Subject is what it applies to, for example
SaaS Seat,Store Footfall,Engineer Salary.Qualifier gives geography, segment or scope, for example
Global,UK,Enterprise,Retail.
Examples:
Driver - Price - Subscription - EnterpriseDriver - Volume - Orders - OnlineDriver - Rate - Churn - SMEDriver - Inflator - Rent - GlobalDriver - FX Rate - EUR to GBP
This pattern keeps all drivers grouped together when sorted by name and remains readable in formulas.
3. Differentiating drivers from variables
Although drivers are often Data Library backed series just like variables, they serve a different purpose.
To keep this clear:
Prefix driver names with
Driver -(or a similar consistent tag) so they are easy to recognise in autocomplete lists.Use nouns that reflect input behaviour rather than financial statement outcomes, for example
Churn Raterather thanLost Revenue.Avoid naming drivers in a way that looks like P&L lines, to reduce confusion.
Variables then tend to have names like Revenue - Subscriptions - UK, while drivers look like Driver - Price - Subscription - UK.
4. Scope and reusability in driver names
If a driver is intended to be global or used across many branches, make that clear:
Driver - Wage Inflation - GlobalDriver - FX Rate - USD to GBPDriver - Market Growth - SaaS
If a driver is specific to one branch or context, capture that as well:
Driver - Price - Retail - Store SydneyDriver - Utilisation - Engineers - Entity A
This helps others understand whether they can safely reuse a driver in their part of the model.
5. Notes, tags and descriptions
For important drivers, combine good names with:
Notes explaining how the driver should be used and where it came from.
Tags to group related drivers, for example
Inflation,FX,Market,Scenario.Data source references if the driver is imported from an external API or file.
Names tell the short story. Notes and tags provide the longer context and make review easier.
6. Renaming drivers safely
Like variables, drivers can be renamed without breaking formulas:
References in formulas are tracked via internal IDs, not just the text name.
When you rename a driver, any variable or chart that uses it will continue to work and will simply show the new name in the formula editor and legends.
This makes it safe to improve naming as driver usage becomes clearer over time.
7. Common driver naming pitfalls
Avoid:
Very generic driver names, for example
Rate,Factor,Adjuster. These become impossible to distinguish at scale.Drivers with similar names but different scopes and no clear qualifier.
Using codes only, for example
DRV_101, unless accompanied by a readable name.
If drivers are not clearly named, it becomes hard to audit how a forecast is built, which undermines trust in the model.
Related articles
Last updated