# Metamodel Prerequisites

> Configuration settings and prerequisites described here are the responsibility of a **YouDesign Admin** working with a **ServiceNow System Administrator**.

Before you can configure shapes, relationships, and visualizations in YouDesign Models, the ServiceNow platform must have the right metamodel in place. YouDesign Models reads from — and commits to — your ServiceNow data model, so **incomplete metamodel setup is the single most common reason new deployments fail**.

This page tells you what to check before you start configuring YouDesign Models.

## What the Metamodel Covers

Three ServiceNow constructs together form the metamodel YouDesign Models relies on:

| Construct                   | ServiceNow Table        | What It Defines                                                                   |
| --------------------------- | ----------------------- | --------------------------------------------------------------------------------- |
| **Tables**                  | `sys_db_object`         | The data entities you want to model (applications, capabilities, services, etc.)  |
| **Relationship Types**      | `cmdb_rel_type`         | The kinds of relationships that exist between records (e.g. *Depends on*, *Uses*) |
| **Suggested Relationships** | `cmdb_rel_type_suggest` | Which relationship types are valid between which pair of tables                   |

## Checklist Before Configuring YouDesign Models

Work through this list with your ServiceNow admin before creating shapes or visualizations. Missing any of these will surface later as "I can't draw this relationship" or "my shape doesn't show in the Data Hub" problems.

### 1. Tables (`sys_db_object`)

Every entity you plan to model with YouDesign Models must be a table in ServiceNow. This includes:

* Out-of-the-box CMDB tables you already use (e.g. `cmdb_ci_business_app`)
* Custom tables your organization has introduced
* Any tables referenced by suggested relationships you plan to use

For each table, confirm:

* The table exists and is accessible
* Relevant fields are present (name, description, and any fields you want to show in the Data Panel)
* ACLs permit the roles that will use YouDesign Models to read/write records

### 2. Relationship Types (`cmdb_rel_type`)

For each *kind* of relationship you want to model (e.g., *Depends on*, *Provided by*, *Exchanges data with*), confirm:

* The relationship type record exists
* The name is clear and readable (this text appears on links in the editor)
* Parent and child descriptors match what end users will understand

### 3. Suggested Relationships (`cmdb_rel_type_suggest`)

Suggested Relationships define **which relationship types are valid between which pairs of tables**. YouDesign Models uses this table at two key moments:

* **When drawing a link** — the editor only allows links that match a suggested relationship between the two endpoints' tables
* **When using** [**Load Dependencies**](/models/work-in-the-app/editor/load-dependencies.md) — the Relationships tab pulls from suggested relationships

For each relationship you plan to model, confirm:

* A suggested relationship exists between the correct **parent table** and **child table**
* The **direction** (parent → child) matches how you want users to draw the link
  * Example: *Business Capability is provided by Business Application* → define parent = Business Capability, child = Business Application. Users draw the link **from** the capability **to** the application.

> **Direction matters.** The direction of the suggested relationship determines the direction the user must draw the link in the editor. Getting this wrong creates confused users and invisible "my link won't save" bugs.

## When to Do This Work

* **Before first-time configuration** — don't start creating YouDesign Models shapes before the metamodel is in place.
* **Before adding a new shape to the library** — if the shape points at a new table, verify the table and its suggested relationships are ready.
* **Before enabling a new visualization** — [Hierarchy Map](/models/work-in-the-app/editor/visualizations/hierarchy-map.md), [Context Map](/models/work-in-the-app/editor/visualizations/context-map.md), and similar visualizations rely on parent-child or relationship-based traversal, which needs the metamodel in place.

## Migration-Aware Configuration

If you're setting up the metamodel in a non-production instance first (recommended), remember that:

* `sys_db_object` changes are captured in **Update Sets**, not YouDesign's XML migration
* `cmdb_rel_type` and `cmdb_rel_type_suggest` entries are ServiceNow records — migrate via Update Sets
* YouDesign Models shape and RTI configuration migrates via **XML files** (see [Migrating Configuration](/models/get-the-app/migrating-configuration.md))

Plan both migration paths together so the dev-to-prod promotion doesn't leave the metamodel out of sync with the YouDesign configuration that depends on it.

## Working with ins-pi

If you're unsure whether your metamodel is ready for the shapes you want to build, your ins-pi representative can help review the configuration before you invest time in YouDesign Models-side work. Escalate through the [support process](/models/reference/support.md).

## Related

* [Installation](/models/get-the-app/installation.md) — installing YouDesign Models itself
* [Shape Administration](/models/admin/shapes.md) — where tables become canvas shapes
* [Shape Relationships](/models/admin/shape-relationships.md) — styling relationships
* [Migrating Configuration](/models/get-the-app/migrating-configuration.md) — nonprod → prod flow
* [Support Process](/models/reference/support.md) — escalation path


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ins-pi.com/models/admin/metamodel.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
