Why traverse properties?
- Targeted filtering — Ask for “clinics that offer cardiology services” even if the service lives in a separate relationship.
- Predictable performance — Traversals are explicit; the registry precomputes the paths so queries stay bounded.
- Governed exposure — Only the properties you whitelist become visible, which simplifies access control and schema evolution.
How traversal works
- Declare the traversal when configuring the partition. You choose:
- The source collection (resource or relationship) you want to project from.
- The path you want to expose (for example,
service.code). - Whether the projection should be filterable, sortable, or both.
- Reference the projected path in search requests using the traversed property notation
Design guidelines
- Keep traversals purposeful — Expose only the fields you need for filters or ranking. This reduces index size and keeps query plans simple.
- Avoid deep chains — Traversing multiple levels increases maintenance costs and may complicate troubleshooting. Flatten data offline if you need more than one hop.
- Plan for governance — Align traversed properties with your access policies. If a downstream team should not see a field, omit it from the traversal.