Model access

Some models are implementation details, meant for reference only within their group of related models. Other models should be accessible through the ref function across groups and projects. Models can set an access modifier to indicate their intended level of accessibility

Configuring model access

You can apply access modifiers in config files, including the dbt_project.yml, or to models one-by-one in properties.yml. Applying access configs to a subfolder modifies the default for all models in that subfolder, so make sure you intend for this behavior. When setting individual model access, a group or subfolder might contain a variety of access levels, so when you designate a model with access: public make sure you intend for this behavior.

Use the access configuration to define the access level for a model. There are multiple approaches to configuring access.

properties.yml

models/properties_my_public_model.yml

version: 2

# using the new method supported in v1.7
models:
  - name: my_public_model
    config:
      access: public 

# Older method, still supported

  - name: my_public_model_two
    access: public 
    

dbt_project.yml

dbt_project.yml

models:
  my_project_name:
    subfolder_name:
      +group: my_group
      +access: private  # sets default for all models in this subfolder

In-file

models/my_public_model.sql

-- models/my_public_model.sql

{{ config(access = "public") }}

select ...

Access level definition

The access level of the model you are declaring properties for.

Access	Referenceable by
private	Same group
protected	Same project (or installed as a package)
public	Any group, package, or project. When defined, rerun a production job to apply the change

By default, all models are protected. This means that other models in the same project can reference them, regardless of their group.

Models with materialized set to ephemeral cannot have the access property set to public.