Traversal rules extend a partition’s query surface beyond the fields that physically exist on a resource. When you configure a traversal, you instruct the registry to project specific properties from related resources (or contained structures) into the current query scope. Filters and sorts can then reference those projected paths as if they were native fields.Documentation Index
Fetch the complete documentation index at: https://docs.clinia.com/llms.txt
Use this file to discover all available pages before exploring further.
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.
Keep exploring
MDM partitions
Understand the unified context where traversals often operate.
Traversed filters how-to
Apply traversed properties to deliver richer search experiences.