diff --git a/docs/source/schema-design/federated-schemas/entities/define-advanced-keys.mdx b/docs/source/schema-design/federated-schemas/entities/define-advanced-keys.mdx
index c3216d514..d0d0f3035 100644
--- a/docs/source/schema-design/federated-schemas/entities/define-advanced-keys.mdx
+++ b/docs/source/schema-design/federated-schemas/entities/define-advanced-keys.mdx
@@ -4,6 +4,12 @@ subtitle: Define and use compound keys, nested key fields, and more
description: Learn how to define compound keys, nested key fields, and multiple keys for the same entity in a federated GraphQL architecture.
---
+
+
+Understand how to [define a single key](/graphos/schema-design/federated-schemas/entities/intro#1-define-a-key) for an entity.
+
+
+
Depending on your entities' fields and usage, you may need to use more advanced `@key`s.
For example, you may need to define a [compound `@key`](#compound-keys) if multiple fields are required to uniquely identify an entity.
If different subgraphs interact with different fields of an entity, you may need to define [multiple](#multiple-keys)—and sometimes [differing](#differing-keys-across-subgraphs)—`@key`s for the entity.
diff --git a/docs/source/schema-design/federated-schemas/entities/migrate-fields.mdx b/docs/source/schema-design/federated-schemas/entities/migrate-fields.mdx
index 781521084..9eb98c920 100644
--- a/docs/source/schema-design/federated-schemas/entities/migrate-fields.mdx
+++ b/docs/source/schema-design/federated-schemas/entities/migrate-fields.mdx
@@ -6,6 +6,12 @@ description: Learn how to safely move parts of one subgraph to another subgraph
import ProgressiveOverrideEnterprise from '../../../../shared/progressive-override-enterprise.mdx';
+
+
+Understand how to [define entity fields for a subgraph](/graphos/schema-design/federated-schemas/contribute-fields).
+
+
+
As your supergraph grows, you might want to move parts of one subgraph to another subgraph.
For example, suppose your Payments subgraph defines a `Bill` entity: