## Get the fields

Query the run to get the fields that exist on the run steps you want to update:

```
{
  run(id: 419) {
    id steps {
      id fields {
        id name value type _etag
      }
    }
  }
}
```

The response looks like this:

```
{
  "data": {
    "run": {
      "id": 419,
      "steps": [
        {
          "id": 1429,
          "fields": [
            {
              "id": 1461,
              "name": "required_field",
              "value": null,
              "type": "STRING",
              "_etag": "066b1eb08dab44d6925d7bbd899e92cf"
            },
            {
              "id": 1462,
              "name": "pass_fail",
              "value": null,
              "type": "BOOLEAN",
              "_etag": "066b1eb08dab44d6925d7bbd899e92cf"
            },
            {
              "id": 1463,
              "name": "quality",
              "value": null,
              "type": "SIGNOFF",
              "_etag": "066b1eb08dab44d6925d7bbd899e92cf"
            }
          ]
        }
      ]
    }
  }
}
```

The query returns a list of run steps within that run, and the fields within those run steps. Find the field that you want to update.

## Update a field value

From the example response above, suppose you want to update field `1462` because your test equipment can determine pass or fail. Use this mutation:

```
mutation {
  updateRunStepFieldValue(input: {
    id: 1462,
    value: true,
    etag: "066b1eb08dab44d6925d7bbd899e92cf"
  }) {
    runStepField {
      id value
    }
  }
}
```

This mutation does the following:
- Because it updates data, it’s a `mutation`.
- The mutation is `updateRunStepFieldValue`.
- The field `id` is `1462` and the `value` you’re setting is `true`.
- It includes the `etag` of the original field. The `etag` prevents accidental data overwrites by enforcing concurrency control.

The response returns the `id` and the updated `value` of the field.