> ## Documentation Index
> Fetch the complete documentation index at: https://docs.runway.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Formulas in databases
> This article covers how to manage driver formulas in databases to support scalable, dimensional modeling in Runway.
For guidance on mapping values using dimensions (i.e., lookups), see [this article](https://docs.runway.com/guides/modeling/lookups).
## Default formulas
* Setting default formulas across a column can save a lot of time—both when you have many drivers that should follow the same logic, **and** when new segments are added to the database. Any new segment will automatically inherit the default formula unless it’s explicitly overridden.
* In databases, each driver column can have a default formula, and any individual row (i.e., specific segmented driver) can override it. To revert to the default, just backspace or clear the custom formula.
* Inherited formulas are shown in a lighter style to indicate they’re coming from the default.
## Formula inheritance
To make modeling at scale simple—while keeping it easy to override when needed—Runway applies **smart defaults** to fill in missing formulas.
When editing a formula, you can **hover over the formula editor** to see where the value is being inherited from.
Runway follows a clear set of rules to determine how formulas are inherited and overridden.
### **Actuals formula** inheritance hierarchy
Runway applies the actuals formula using the following order of precedence:
1. An **explicitly set actuals formula** for the driver
2. A **default actuals formula** set at the column level in the database
3. If no actuals formula is available, the driver falls back to its **forecast formula**
### Forecast formula inheritance hierarchy
Similarly, forecast formulas follow this order of precedence:
1. An **explicitly set forecast formula** for the driver
2. A **default forecast formula** set at the column level in the database
3. If none is set, Runway uses the **global default formula**: `self * last month`
For example, if only a forecast formula is set at the column level, every driver in that column will automatically inherit that formula—unless an override is applied.
## Dynamic formulas using *This Segment*
In highly dimensional models, when you want to apply similar logic across many segments (like forecasting product usage or modeling revenue per customer), you can use ***This Segment*** to write formulas that scale.
* ***This Segment*** refers to **other data that shares some or all of the same dimensional attributes** as the driver you’re writing the formula for.
* It allows you to write a **single formula** that dynamically adjusts based on the segment it’s applied to—helping you avoid repetitive formulas and reduce the chance of errors.
* While most commonly used within the same database, ***This Segment*** also works **across different databases**.
* You can also use **dimension filters** inside *This Segment* to fine-tune the match—for example, matching on just one shared dimension if that’s all that’s needed.
Let’s walk through some common use cases where *This Segment* helps scale your modeling logic and keep things simple.
When chaining formulas together in databases, the **Timeseries view** is a great way to see how logic flows across multiple drivers. You’ll be able to view all default formulas side by side, and edit them directly by clicking the **ƒ** icon for each driver to see how changes propagate.
You can switch to this view via: **Customize → View as → Timeseries**.\
\\
### Example: Dynamic default formula using *This Segment*
In this example, we use the *This Segment* to populate a default formula that applies consistent logic across all segments in the database. Below is a video and diagram to help illustrate how it works.
### **Example: Dynamic filters using dimensions**
Sometimes, you may want to filter based on partial match with a segment—for example, matching on a single dimension rather than all of them. With *This Segment*, you can apply dynamic filters across **all dimensions** or a **subset of them**, directly from the filter menu.
Let’s walk through an example: you want to calculate what percentage of each product’s usage is consumed by each customer.
In the filter menu:
* If you want to match across **all** the dimensions in the segment (e.g. match on Customer Name + Product), you can use the **Segment** filter.
* To apply the dynamic filters for specific dimensions, you can select the relevant dimension and then use the \*\*This \ \*\*option.
When choosing what to filter:
* Selecting a **formula pill with the database name and icon** lets you filter on **any column** in that database.
* Selecting a **formula pill with just the driver name** limits you to filtering on **columns the driver is segmented by.**
### Example: Dynamic filters using driver values
**Numeric drivers**
There’s one more powerful use case for *This Segment*—using it to dynamically match on **driver values**, not just dimensions. This allows you to reference a value from one driver based on the value of another, similar to `VLOOKUP()` in Excel—but more robust.
Let’s walk through an example. You want to charge customers different unit prices based on their usage tier thresholds.
Imagine you have a database of **usage tiers** with associated **unit prices**, and you're trying to calculate how much to charge each customer.
To perform this match, we can simply apply a formula that multiplies: `each customers # transactions` \* `unit price for their usage tier`
You can then use *This Segment* in the filter menu to dynamically select the correct unit price for each customer based on their usage level.
**Date drivers**
You can also use *This Segment* to dynamically filter based on **date driver values**—a powerful technique often used in cohort or revenue recognition models.
When filtering a database by a date column, you'll see the option to use **\** as the filter value. This allows you to reference dates from your model—such as contract start dates, signup dates, or feature release dates.
To apply this dynamically for each segment, use *This Segment* when selecting the date driver. That way, each segment uses **its own corresponding date** to filter the data.