diff --git a/daprdocs/content/en/contributing/codespaces.md b/daprdocs/content/en/contributing/codespaces.md
index 993f3e2bd7f..111f04d9be8 100644
--- a/daprdocs/content/en/contributing/codespaces.md
+++ b/daprdocs/content/en/contributing/codespaces.md
@@ -46,4 +46,6 @@ git reset --hard
 ```
 
 ## Related links
-- [GitHub documentation](https://docs.github.com/en/github/developing-online-with-codespaces/about-codespaces)
+<!-- IGNORE_LINKS -->
+- [GitHub documentation](https://docs.github.com/github/developing-online-with-codespaces/about-codespaces)
+<!-- END_IGNORE -->
diff --git a/daprdocs/content/en/developing-applications/building-blocks/state-management/state-management-overview.md b/daprdocs/content/en/developing-applications/building-blocks/state-management/state-management-overview.md
index d6c48658002..93a42e4e9ee 100644
--- a/daprdocs/content/en/developing-applications/building-blocks/state-management/state-management-overview.md
+++ b/daprdocs/content/en/developing-applications/building-blocks/state-management/state-management-overview.md
@@ -66,11 +66,17 @@ With the HTTP API, you can set content type via URL query parameter `metadata.co
 
 With the gRPC API, you can set content type by adding key/value pair `"contentType" : <content type>` to the request metadata.
 
-### Bulk operations
+### Multiple operations
 
-Dapr supports two types of bulk operations: **bulk** or **multi**. You can group several requests of the same type into a bulk (or a batch). Dapr submits requests in bulk operations as individual requests to the underlying data store. In other words, bulk operations are not transactional. On the other hand, you can group requests of different types into a multi-operation, which is then handled as an atomic transaction.
+Dapr supports two types of mult-read or multi-write operations: **bulk** or **transactional**. Read the [API reference]({{< ref state_api.md >}}) to learn how use bulk and multi options.
 
-Read the [API reference]({{< ref state_api.md >}}) to learn how use bulk and multi options.
+#### Bulk read operations
+
+You can group multiple read requests into a bulk (or batch) operation. In the bulk operation, Dapr submits the read requests as individual requests to the underlying data store, and returns them as a single result.
+
+#### Transactional operations
+
+You can group write, update and delete operations into a request, which are then handled as an atomic transaction. The request will succeed or fail as a transactional set of operations.
 
 ### State encryption
 Dapr supports automatic client encryption of application state with support for key rotations. This is supported on all Dapr state stores. For more info, read the [How-To: Encrypt application state]({{< ref howto-encrypt-state.md >}}) topic.
diff --git a/daprdocs/content/en/reference/api/state_api.md b/daprdocs/content/en/reference/api/state_api.md
index 375b775ab95..011d4d595db 100644
--- a/daprdocs/content/en/reference/api/state_api.md
+++ b/daprdocs/content/en/reference/api/state_api.md
@@ -443,9 +443,9 @@ POST http://localhost:3500/v1.0-alpha1/state/myStore/query?metadata.partitionKey
 
 ## State transactions
 
-Persists the changes to the state store as a multi-item transaction.
+Persists the changes to the state store as a [transactional operation]({{< ref "state-management-overview.md#transactional-operations" >}}).
 
-> This operation depends on a state store component that supports multi-item transactions.
+> This API depends on a state store component that supports transactions.
 
 Refer to the [state store component spec]({{< ref "supported-state-stores.md" >}}) for a full, current list of state stores that support transactions.
 
@@ -481,20 +481,28 @@ POST http://localhost:3500/v1.0/state/myStore/transaction?metadata.contentType=a
 
 Field | Description
 ---- | -----------
-`operations` | A JSON array of state operation
-`metadata` | (optional) The metadata for transaction that applies to all operations
+`operations` | A JSON array of state `operation`
+`metadata` | (optional) The `metadata` for the transaction that applies to all operations
 
-Each state operation is comprised with the following fields:
+All transactional databases implement the following required operations:
 
-Field | Description
+Operation | Description
+--------- | -----------
+`upsert` | Adds or updates the value
+`delete` | Deletes the value
+
+Each operation has an associated `request` that is comprised of the following fields:
+
+Request | Description
 ---- | -----------
 `key` | State key
 `value` | State value, which can be any byte array
 `etag` | (optional) State ETag
-`metadata` | (optional) Additional key-value pairs to be passed to the state store
+`metadata` | (optional) Additional key-value pairs to be passed to the state store that apply for this operation
 `options` | (optional) State operation options; see [state operation options](#optional-behaviors)
 
 #### Examples
+The example below shows an `upsert` operation for `key1` and a `delete` operation for `key2`. This is applied to the partition named 'planet' in the state store. Both operations either succeed or fail in the transaction.
 
 ```shell
 curl -X POST http://localhost:3500/v1.0/state/starwars/transaction \