Reference Types and Relationships in JSM Assets

What are Reference Types?

A reference type defines the meaning of a relationship between objects. It's the label that explains why two things are connected.

In JSM Assets, a reference type has:

• Name - What you call the relationship (e.g., "Managed By")
• Description - What it means
• Color - Visual distinction in graphs and lists

References connect objects across object types (or within the same type):

Application --> "Managed By" --> Team
Server --> "Located In" --> Data Center
Person --> "Reports To" --> Person

Why Reference Types Matter

Without reference types, you just have generic "links" between objects. That's not useful.

The same two object types can have multiple reference types with completely different meanings.

Relationship Cardinality

Cardinality defines how many objects can be on each side of a relationship.

One-to-One

One object on each side. Rare in practice.

Employee --[Has Assigned Laptop]--> Laptop
    1                                  1

Use case: Each employee has exactly one primary laptop.

One-to-Many

One object relates to multiple objects.

Person --[Reports To]--> Person
  *                        1

Use case: Many people report to one manager.

Many-to-Many

Multiple objects on both sides.

Application --[Used By]--> Team
     *                      *

Use case: An application can be used by many teams; a team can use many applications.

Cardinality in JSM Assets

Naming References Clearly

Reference names should read naturally as "Source [Reference Type] Target".

Good Names (Directional and Clear)

Avoid These Patterns

Common Relationship Patterns

Ownership Relationships

Who is responsible for this thing?

Application --[Business Owner]--> Person
Application --[Technical Owner]--> Person
Application --[Owning Team]--> Team
Contract --[Contract Owner]--> Person

Management Relationships

Who operates or maintains this?

Server --[Managed By]--> Team
Cloud Account --[Managed By]--> Team
Vendor --[Relationship Owner]--> Person

Location Relationships

Where is this thing?

Server --[Located In]--> Data Center
Person --[Works At]--> Location
Equipment --[Installed In]--> Room

Hierarchy Relationships

Organizational structure.

Person --[Reports To]--> Person
Department --[Parent]--> Department
Team --[Part Of]--> Department
Location --[Parent]--> Location

Dependency Relationships

What does this thing need to function?

Application --[Depends On]--> Application
Service --[Runs On]--> Server
Application --[Uses Database]--> Database

Relationship Graph: Visualization

JSM Assets automatically creates a graph view of your relationships. This is powerful for:

• Impact analysis: What's affected if this server goes down?
• Root cause analysis: What does this failing service depend on?
• Audit trails: Who owns what? What's connected to what?

Application Dependency Graph

                 +-----------------+
                 |  Customer Portal|
                 |   (Application) |
                 +--------+--------+
                          | Depends On
           +--------------+--------------+
           |              |              |
    +------v------+ +-----v------+ +-----v------+
    | Auth Service| | API Gateway| |  Database  |
    |(Application)| |(Application)| | (Database) |
    +------+------+ +-----+------+ +------------+
           |              |
           |              | Depends On
    +------v------+ +-----v------+
    |    LDAP     | | User Service|
    |(Application)| |(Application)|
    +-------------+ +-------------+

Bidirectional vs. Unidirectional

Unidirectional (Default)

The relationship is defined from one side only.

Application --[Depends On]--> Database

You can query "What does this application depend on?" but not easily "What applications depend on this database?"

Bidirectional (Inverse References)

JSM Assets can show the relationship from both sides when you query either object.

• Viewing Application: Shows "Depends On: Database"
• Viewing Database: Shows "Depended On By: Application"

In JSM Assets, bidirectional display is automatic when you view an object - it shows both outgoing references AND incoming references from other objects.

Avoiding Circular Dependencies

Circular dependencies create confusion and can break automation.

The Problem

App A --[Depends On]--> App B --[Depends On]--> App C --[Depends On]--> App A

If App A depends on App B, which depends on App C, which depends on App A... what's the startup order? What's the root cause when something fails?

How to Avoid

1. Model reality: Real systems rarely have true circular dependencies
2. Distinguish dependency types: Maybe App A needs App B for startup, but App B only needs App A for a feature
3. Add direction indicators: "Hard Depends On" vs. "Soft Depends On"
4. Break the circle: Often one relationship is actually "Integrates With" not "Depends On"

Relationship Best Practices

Do This

Avoid This

Color Coding Conventions

Use consistent colors to make graphs readable:

Example: Complete Reference Type Set

Here's a well-designed set of reference types for a Core CMDB:

Querying Relationships

Once relationships are in place, you can answer powerful questions:

Relationships turn data into knowledge. Name them clearly, design them thoughtfully, and your CMDB becomes a powerful tool for understanding your organization.