# Context Views > Context views in Schemity show only the entities relevant to a feature or bounded context, keeping large schemas readable from one ERD source of truth. Source: https://schemity.com/doc/context-views/ A **context view** is a saved, focused view of your schema that shows only a subset of entities and the relationships between them. It is Schemity's answer to the biggest problem with large ERDs: one giant canvas nobody can read. "Context Views" is the actual feature name in the app. There are two ways to build one, and the video below walks through both: adding a view from the **Context Views** panel and importing entities into it, and right-clicking a legend on the main diagram to send everything it frames into a context view in one step. The sections after it cover the same ground in text. ## Watch: creating a context view
## Why is one big ERD diagram a problem? A real application might have eighty entities. Drawn all at once on the **main** diagram, the ERD is a wall of boxes and crossing lines. Context views solve this: one underlying schema, many focused views into it. ## How do context views work? You keep a single set of entities - the **ERD single source of truth** - and create context views on top. A `billing` view might show `invoices`, `line_items`, `payments`, and the `users` they belong to, hiding the other seventy entities entirely. Every view points at the same entities, so editing an entity's fields in the main diagram updates it everywhere. What a context view stores on its own is the **presentation**: which entities it includes, their positions, their connector routing ([waypoints](https://schemity.com/doc/custom-waypoints/)), and its own [legends](https://schemity.com/doc/legends-and-annotations/). There is no second copy of the schema to keep in sync. ## How do I create a context view? There are two routes. Both end at the same thing - a named view holding a subset of the entities - and both are shown in the video above. **From the Context Views panel**, when you want to pick the entities yourself: 1. Open the **Context Views** panel and choose **Add context view**. 2. Give it a **Name** (and color) for the area it covers, for example `billing` or `auth`. 3. Add the entities relevant to that context and arrange them for that view. **From a legend on the main diagram**, when the domain is already framed: **right-click the legend** and choose **Import to context views**, then pick the target view - creating it from the same step if it does not exist yet. Every entity inside the legend's frame lands in that view at once, so step 3 above disappears entirely. **From every legend at once**: **Sync from legends** in the **Context Views** drawer gives each legend on the main diagram a context view holding exactly its tables, in one click. The legend route is usually the faster one, because grouping entities with a legend is work you have already done while reading the main diagram. Whichever route you take, the view starts as presentation over the same entities - nothing is copied. Entities are never *created* inside a context view - they are imported, because the main view owns the schema. A newly created view says so on its empty canvas, pointing at import rather than at the create-entity actions the main view offers. ## How do I see what crosses a context view's boundary? An entity with relations leaving the view carries a boundary indicator. Click it to list everything crossing that boundary - the foreign keys it owns pointing out, and the entities outside referencing it - each with its relation description. Pick a row to land on the main diagram with that entity selected. Every context view canvas also has a **Main diagram** button, so getting back is one click. ## Can I add a description to a context view? Yes. A context view can carry a **description written in markdown**. When a view has one, its row in the **Context Views** list shows a **file icon** button; clicking it opens a modal that renders the markdown-formatted description. The same file icon appears on that context's node on the **Context Map**, so the description is readable at the architecture scale without leaving the map. Use it to state what the view is for - the bounded context it covers, who its audience is, what "done" looks like for that slice of the schema - so a teammate opening the workspace understands each view without asking. Legends and entities support markdown descriptions the same way. ## How do I see the dependencies between context views? Open the [Context Map](https://schemity.com/doc/context-map/): a bird's-eye view where each context view becomes a single node and the dependency arrows between contexts are derived from the actual foreign keys - with per-direction foreign key counts, circular dependency detection, and export to JPG, PNG, SVG, or Mermaid. It has its own doc page. ## Why do context views fit domain-driven design? Context views map naturally onto a **bounded context ERD**. Each view is one slice of the domain, so the diagram mirrors how your team actually reasons about the system. That makes Schemity a strong fit for **domain-driven design database schema** work. ## Next Annotate and group your diagram with [Legends & Annotations](https://schemity.com/doc/legends-and-annotations/).