# AML user attributes and variables

> Reference user attributes, system user attributes, and built-in variables in AML expressions.

## Introduction

AML expressions can use runtime context from the current user and the current Git environment. This is useful when the same AML code needs to behave differently for different users, teams, branches, or production environments.

You can use these values anywhere AML accepts an expression, such as dynamic data source names, dynamic schemas, or AI custom context.

## User attributes

Use `H.current_user.<attribute_name>` to access any [custom user attribute](/docs/admin/user-attributes) of the current user. For example, `H.current_user.data_source` returns the current user's `data_source` attribute, which you can use to route each user to the correct database.

Before referencing a custom user attribute in AML, define it in [User Attributes Management](/docs/admin/user-attributes#add-new-user-attributes). The attribute name in AML must match the user attribute name exactly.

```aml
Dataset sales {
  // highlight-next-line
  data_source_name: H.current_user.data_source
  models: [orders]
}
```

### Use user attributes in conditional logic

User attributes also work well with [if-else expressions](/reference/aml/if-else). In this example, analysts and marketers receive different AI context based on their `team` attribute.

```aml
const ai_context = @md

${
  if (H.current_user.team == 'Business Analyst') {
    'Focus on product performance, margin, and inventory analysis.'
  } else if (H.current_user.team == 'Growth & Marketing') {
    'Focus on customer acquisition, retention, and campaign performance.'
  } else {
    'Answer using the standard company definitions in the semantic layer.'
  }
}

;;
```

## System user attributes

[System user attributes](/docs/admin/user-attributes#system-user-attributes) are provided by Holistics, prefixed with `h_`, and cannot be modified by users.

| Attribute | Description |
|---|---|
| `H.current_user.h_email` | The email of the current user account. |
| `H.current_user.h_role` | The role of the current user account, such as `admin`, `analyst`, `explorer`, or `viewer`. |

In this example, admins connect to the production database while other roles are routed to a restricted data source:

```aml
Dataset sales {
  // highlight-start
  data_source_name:
    if (H.current_user.h_role == 'admin') {
      'production_data_source'
    } else {
      'restricted_data_source'
    }
  // highlight-end
  models: [orders]
}
```

## Holistics built-in variables

Holistics also provides built-in variables for the current Git and deployment context. These are useful when you want different behavior in development and production.

| Variable | Description |
|---|---|
| `H.git.current_branch` | Returns the name of the current Git branch. |
| `H.git.is_production` | Returns `true` when in the Reporting tab or in the Development workspace with production mode enabled. |

For example, this setup uses each user's `data_source` attribute in production, but always uses a development database while modeling:

```aml
Dataset sales {
  // highlight-start
  data_source_name:
    if (H.git.is_production) {
      H.current_user.data_source
    } else {
      'development_data_source'
    }
  // highlight-end
  models: [orders]
}
```

## Common use cases

These variables are most commonly used when your AML project needs to adapt at runtime:

- [Dynamic data sources](/docs/development/dynamic-data-source): route the same dataset or model to different databases.
- [Dynamic schemas](/docs/development/dynamic-schema): use different database schemas for different environments or users.
- [Custom context for Holistics AI](/docs/ai/context/custom-context): tailor AI instructions for different teams or workflows.
- [Row-level permissions as code](/docs/access-control/row-level-permission-as-code): define data access rules based on user attributes.