diff --git a/docs/docs-beta/docs/tutorial/multi-asset-integration.md b/docs/docs-beta/docs/tutorial/multi-asset-integration.md
index e0f3cb99f8a03..ea776f1e52e96 100644
--- a/docs/docs-beta/docs/tutorial/multi-asset-integration.md
+++ b/docs/docs-beta/docs/tutorial/multi-asset-integration.md
@@ -185,7 +185,11 @@ def my_assets(replication_resource: ReplicationProject):
 
 At the end of [Step 2](#step-2-implementation), we mentioned that end users were unable to customize asset attributes, like the asset key, generated by our decorator. Translator classes are the recommended way of defining this logic, and they provide users with the option to override the default methods used to convert a concept from your tool (for example, a table name) to the corresponding concept in Dagster (for example, asset key).
 
-To start, we will define a translator method to map the table specification to a Dagster asset key. **Note**: in a real world integration you will want to define methods for all common attributes like dependencies, group names, and metadata.
+To start, we will define a translator method to map the table specification to a Dagster asset key.
+
+:::note
+In a real world integration, you will want to define methods for all common attributes like dependencies, group names, and metadata.
+:::
 
 ```python
 from dagster import AssetKey, _check as check