> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clarityq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Building Features from the Event Catalog

> How events become queryable features in the Semantic Catalog.

Features are the Semantic Catalog components that represent product events — things like `signup_completed`, `purchase_made`, or `level_finished`. They're created by syncing approved events from the [Event Catalog](/context-layer/event-catalog/what-is-the-event-catalog) into the Semantic Catalog.

Unlike metrics, entities, and skills, features are **not built through the Context Builder**. They come from the Event Catalog's sync process.

## How Features Are Created

<Steps>
  <Step title="Approve events in the Event Catalog">
    Events must have an approved description before they can be synced. Use the [Missing Description Wizard](/context-layer/event-catalog/missing-description-wizard) to fill in descriptions efficiently.
  </Step>

  <Step title="Sync to the Semantic Catalog">
    Select one or more approved events and choose **Sync to Semantic Catalog**. See [Syncing Events to the Semantic Catalog](/context-layer/event-catalog/syncing-events-to-the-semantic-catalog) for the full walkthrough.
  </Step>

  <Step title="Review the resulting features">
    Each synced event becomes a Feature. The event's parameters and user properties become Dimensions on that Feature. Descriptions carry over automatically.
  </Step>
</Steps>

## What Gets Created

| Source               | Becomes                         |
| -------------------- | ------------------------------- |
| The event itself     | A Feature named after the event |
| Each event parameter | A Dimension on that Feature     |
| Each user property   | A Dimension on that Feature     |

## Sync Options

When syncing, you choose between two options:

* **Sync and Approve** — The Feature is immediately available to everyone in your workspace.
* **Sync Only** — The Feature is created in a private state, visible only to you until you manually approve it. Use this when you want to review or adjust the Feature before exposing it to the team.

## Keeping Features Up to Date

Once an event is synced, new parameters and user properties are added as Dimensions automatically as they're approved in the Event Catalog. You don't need to re-sync the parent event each time.

<Note>
  When you edit an event's description in the Event Catalog after it's been synced, ClarityQ prompts you to update the corresponding Feature's description as well. The same applies when editing a parameter or user property description — you'll be asked whether to update the matching Dimension in the Semantic Catalog.
</Note>

## Adding Table Columns as Dimensions

Beyond synced parameters and user properties, you can add columns from your events table as dimensions on features. This is useful for columns that exist in the table but aren't tracked as event parameters — for example, a `session_id`, `device_model`, or `app_version` column.

When adding table columns, you can choose to add them to:

* **All features** — The dimension is linked to every feature and automatically links to future features as well. This creates a **shared** dimension.
* **Specific features** — The dimension is linked only to the features you select.

## Adding Custom Dimensions

You can also create dimensions with custom SQL that don't come from a table column or event parameter. This is useful for derived values — for example, a dimension that extracts a nested field, applies a transformation, or combines multiple columns.

Custom dimensions can be scoped the same way: shared across all features, or linked to specific ones.

## Common Dimensions vs Feature-Specific Dimensions

A dimension that's linked to **two or more features** is automatically classified as a **common dimension**. A dimension linked to only one feature is considered feature-specific.

Common dimensions appear in a dedicated **Common Dimensions** tab in the Semantic Catalog, making them easy to find and manage separately from the dimensions nested under individual features.

This distinction matters because common dimensions represent properties that apply broadly across your product events — like `country`, `platform`, or `user_id` — while feature-specific dimensions are unique to a single event.

## Managing Common Dimensions

From the Common Dimensions view, you can manage how a dimension relates to each of its linked features:

* **Link to more features** — Extend a common dimension to additional features it isn't linked to yet.
* **Remove from a feature** — Deletes the link between the dimension and that feature. If the dimension has no remaining feature links, it's deleted entirely.
* **Duplicate and Detach** — Creates a copy of the dimension linked only to that specific feature, breaking the shared link. Future changes to the common dimension no longer affect this feature. Use this when a feature needs its own version of a dimension that diverges from the shared definition.