---
title: "Server Value Expressions for Data Connect"
description: "Server Value Expressions for Data Connect"
published: "2025-06-05"
last_updated: "2025-06-05"
authors:
  - "Andrea Wu (Developer Advocate)"
categories:
  - "SQL Connect"
  - "Authentication"
  - "GraphQL"
  - "PostgreSQL"
canonical_url: "https://firebase.blog/posts/2025/06/dataconnect-server-values"
---

# Server Value Expressions for Data Connect

*Published June 5, 2025 by Andrea Wu (Developer Advocate)*

---
> **Note:** Firebase Data Connect has been renamed to SQL Connect. Learn more in the [SQL Connect announcement](https://firebase.blog/posts/2026/04/whats-new-sql-connect).

When using Data Connect, your app sometimes might need server-computed values because the values need to be computed at the time of data creation. 

As an example, suppose you're adding a `user` field to `AddReview`, and you want to set the field to the current user ID when a review is added. You could add a variable and change the app to set it from the client side, but an attacker may leverage that to post reviews attributed to another user. It's a lot of work to ensure security.

With Data Connect, you only have to change the server side by using server values. This means the server dynamically populates fields in your tables using stored or readily-computable values using particular server-side expressions. 

Data Connect already supported some server values, and now, there are even more server values that you can use!

### Previously
Until now, the only supported server values were: `auth.uid`, `request.time`, and `uuidV4()`. As an example, you could define a field with a timestamp applied when the field is accessed using the expression `createdAt: Timestamp! @default(expr: "request.time")`. 

This might be used when a user creates their account, so the schema could look like this:

```graphql
type User @table(key: "userId") {
  # other fields
  userId: String! @default(expr: "auth.uid") # or (expr: “uuidV4()”)
  createdAt: Timestamp! @default(expr: "request.time")
}
```

This schema not only means that the corresponding database table gets created but also that the server automatically fills in the correct values.

To use these in your queries or mutations, you use `<field>_expr`, which are auto-generated on all fields. For example, to add a user:

```graphql
mutation AddUser {
  user_insert(data: {
    userId_expr: "auth.uid"
    createdAt_expr: "request.time"
  })
}
```

### New Updates
The supported server values above still work, but now, you can use CEL expressions to make more complex field values.

To do so, you use `<field>_expr`, which are auto-generated on all fields. The schema stays the same as above, and to add a user:

```graphql
mutation AddUser {
  user_insert(data: {
    userId_expr: “auth.token.email”
    createdAt_expr: "request.time"
  })
}
```

Without using `_expr`, `auth.token.email` and `request.time` will be string literals (meaning `userId`’s value will have the literal value “auth.token.email”. `createdAt` will not hold the correct value, as the literal “request.time” string parses into a specific Timestamp and will be that value every single time).

Aside from the expressions that worked before today, you can now create even more complex fields! Let’s say you need to add a prefix to all userIDs located in a specific region. With server values, this is how you can do so:

```graphql
mutation AddUserInUS {
  user_insert(data: {
    userId_expr: "'US' + auth.uid"
  })
}
```

If the `auth.uid` is `abc123`, the userId for this particular user will be `USabc123`. 

Note: to ensure proper computation of the expression, you need to wrap the entire expression in double quotes and use single quotes inside the expression.

For a more interesting example, let’s say you’re building a medical app with doctors creating profiles and you’re using Firebase Auth to authenticate:

```graphql
type Profile @table(key: "id") {
  id: String! # cannot be UUID since Firebase Auth ids are not UUIDs
  displayName: String!
}
```

You want to add a new user with their Firebase Auth UID as the ID:

```graphql
mutation CreateProfile @auth(level: USER) {
  profile_insert(data: {
    id_expr: "auth.uid",
  })
}
```

When a doctor fills out profile information, they provide their degree, like MD, DO, PA, NP, and MA. In displaying this information to clients, the app needs to list this degree after the name. Therefore in the app code, each new profile insertion also needs to include their name, concatenated with a comma and their degree. Adding to the code above, you can use a CEL expression value in `displayName_expr` to do name concatenation:

```graphql
mutation CreateProfile($name: String!, $degree: String!) @auth(level: PUBLIC) {
  profile_insert(
    data: {
      id_expr: "auth.uid",
      displayName_expr: "vars.name + ', ' + vars.degree"
    }
  )
}
```

`vars` above is shorthand for `request.variables` to make writing code easier and succinct. There is no advantage in `request.variables` as it’s longer and these two get the exact same information.

Later, let’s say a user has saved the name of the doctor and degree they have, and the user wants to see the doctor’s profile. To query for results for the correct doctor:

```graphql
query FindProfilesWithDegree($name: String, $suffix: String) @auth(level: PUBLIC) {
  profiles(
    where: { displayName: {eq_expr: "vars.name + ', ' + vars.suffix"} }) {
      id
      displayName
    }
  )
}
```

With `<field>_expr` being able to evaluate CEL expressions, you have a lot more options for server values!

### Try it out!
These new features and improvements are designed to unlock new use cases and make Data Connect a more capable database service for your apps. We're excited to see what you build with it and these new features. Happy coding!