# Features

Features are entity-level attributes, representing all the things we know of entities.\
Lynk makes it simple to create features, based on related data assets or related entities.

{% hint style="info" %}
Features represent the business logic of enriching entities with information based on other related assets or entities. Essentially, features can be thought of as dynamic dimensions.
{% endhint %}

***

## Types of features

### Field

Field features are great for enrichments from **one-to-one** or **many-to-one** relations.\
It is commonly used to enrich an entity with simple, non aggregate fields from one-to-one related assets or entities. See more in depth information on [Field](https://docs.getlynk.ai/reference/data-modeling/features/field)[ features](https://docs.getlynk.ai/reference/data-modeling/features/field).

### Metric

Metric features are great for aggregations from **one-to-many** relations.\
It is commonly used to enrich an entity with aggregated fields from one-to-many related assets or entities. See more in depth information on [Metric features](https://docs.getlynk.ai/reference/data-modeling/features/metric).

### First-Last

First-Last features are great for enrichments of fields from **one-to-many** relations.\
It is commonly used to enrich an entity with fields of the first or last appearance of a one-to-many related assets or entities. See more in depth information on [First-Last features](https://docs.getlynk.ai/reference/data-modeling/features/first-last).

### Formula

Formula features are used when we need to create calculated features on top of other features.\
It is commonly used to enrich an entity with more complex calculations that require multiple aggregations or calculations to be done first. See more in depth information on [Formula features](https://docs.getlynk.ai/reference/data-modeling/features/formula).

***

## Chaining features

Lynk supports creating features based on previously created features on related entities.

For example, let's assume we have an entity called `user` and another entity called `team`, with in a many-to-one relationship. You can create a feature called `is_active_user` on the `user` level and consume it for creating a metric feature `active_users_count` on the `team` entity level.

{% hint style="info" %}
This allows building consistent, accessible and governed business logic - See [chaining features](https://docs.getlynk.ai/reference/data-modeling/features/chaining-features) for in depth information about this.
{% endhint %}

***

## Consuming features

Features are consumed via [SQL API](https://docs.getlynk.ai/reference/consume-and-apis/sql-api), [REST API](https://github.com/lynk-ai/docs/blob/main/reference/data-modeling/features/broken-reference/README.md) or via Lynk [Playground](https://github.com/lynk-ai/docs/blob/main/reference/data-modeling/features/broken-reference/README.md).

For example, here is a simple SQL API request to get some features defined on a customer level:

```sql
-- A simple SQL API query

SELECT  customer_id,
        total_order_amount,
        first_order_date,
        last_order_status
FROM    entity('customer') 
WHERE   country = 'US'
LIMIT   100
```

See [consume](https://docs.getlynk.ai/reference/consume-and-apis) for in depth information on this.

***

## Time aggregations

Lynk separates between business logic and time aggregations like rolling\_window on the consumption layer. See [time aggregations](https://docs.getlynk.ai/reference/data-modeling/time-aggregation) for in depth information on this.

***

## Governance

Lynk [Governance](https://docs.getlynk.ai/reference/governance) makes sure features are unique and trusted:

* Features have unique names
* Features have unique definitions
* Monitoring relationship type to make sure feature definitions won't break