> For the complete documentation index, see [llms.txt](https://docs.dexlabs.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dexlabs.io/lakehouse-platform/develop-with-dex/hooks-and-operations.md).

# Hooks and Operations

Hooks and operations in dex let you run custom logic **before or after** certain actions during the build process. They're useful for automating side effects such as permission grants, logging, notifications, or downstream system triggers.

Hooks are declared inside your models or macros using the `config()` block, and they’re executed as part of your model’s lifecycle. Operations, on the other hand, are standalone SQL or Python scripts that can be triggered manually or as part of a Flow.

Both features help you extend dex beyond transformation logic—adding automation and control to your data platform.

### What Are Hooks?

Hooks are commands that run automatically at specific moments during model execution. dex supports two hook types:

* `pre-hook`: runs **before** the model executes
* `post-hook`: runs **after** the model finishes

Hooks are often used to:

* Grant access to specific roles after a model is created
* Log or audit model execution
* Clean up intermediate tables or update metadata

### Example: Post-Hook to Grant Permissions

```sql
{{ config(
    materialized='table',
    post_hook=[
      "grant select on {{ this }} to role analytics"
    ]
) }}

select *
from {{ ref('customer_orders') }}
```

In this example, once the model is created or updated, it will automatically grant `SELECT` permissions to the `analytics` role.

You can define multiple hooks by passing a list of SQL strings or macros.

### When Hooks Run

Hooks run **as part of a model’s lifecycle** and follow these phases:

1. `pre-hook`: runs before model logic is executed
2. Model logic is compiled and executed
3. `post-hook`: runs after the model finishes successfully

Hooks can be used with models, snapshots, seeds, and other resources.

{% hint style="info" %}
If a hook fails, the model run may fail as well
{% endhint %}

### Operations

Operations in dex are standalone SQL or Python scripts that you can execute independently of models. They’re useful for:

* Maintenance tasks
* Triggers and notifications
* One-off administrative jobs
* Managing external systems

Operations can be:

* Manually executed from the UI
* Included in Flows
* Parameterized using Jinja and environment variables

#### Example SQL operation

```sql
-- operations/grant_access.sql

grant select on schema reporting to role finance

```

You can then trigger this operation manually or schedule it as part of a Flow.

### File Structure Example

```
models/
  └── core/
      └── revenue.sql

operations/
  └── permissions/
      └── grant_analytics_access.sql
  └── maintenance/
      └── refresh_indexes.sql
```

### Best Practices

* Use `post-hooks` for controlled side effects like permissions or metadata updates
* Keep hook logic idempotent—make sure it won’t break if run multiple times
* Group operations by purpose (e.g. `permissions/`, `maintenance/`, `sync/`)
* Avoid putting complex business logic in hooks—prefer models and macros instead
* Test hooks in non-production environments before rollout


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dexlabs.io/lakehouse-platform/develop-with-dex/hooks-and-operations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.