Software catalog
Software catalog centralizes all your software data in one place, with a flexible modeling system, robust filtering, and details on key metadata like ownership and relations. Use Software catalog to record the software components that make up your business - such as Services, Teams, APIs, and cloud infrastructure.
Software catalog helps teams by:
- Providing context on your organization’s software to your AI tooling and the rest of your stack
- Clarifying ownership of services to leverage during incident management or research
- Highlighting dependencies between services to help determine blast radius and the effects of changes made
- Centralizing connections to external tooling like source code management, alerting, cloud infrastructure, and more
Entities
Software catalog is built upon entities. Each entity represents an individual piece of your software organization, and has a specific type, such as Service or Team. Each entity also has various properties that provide important context, such as ownership, relationships to other entities, and more.
Populating the Software catalog
When you enable a connection to a source code management tool in Admin > Connections, entities are discovered and imported into DX (see Entity Discovery).
Additionally, Software catalog can be fully managed via API endpoints for easily syncing data from multiple systems. Visit our API docs to learn how to programmatically manage your catalog.
Entity types
All entities must have a type. DX includes these built-in entity types:
Service- Available to all customers. Services are automatically created from DX deployment tracking and then used in report filtering.Team- Available to Fabric customers. Team entities are synced from your DX teams automatically.
You can also create custom entity types to catalog different types of entities in your business that DX doesn’t have out of the box. This may include APIs, Cloud Infrastructure, User Journeys, Kubernetes Clusters, GitHub Repositories, etc.
Custom entity types can be added from the Catalog Admin page. There you can manage properties, aliases, and relations for the entity type. If desired, each entity type can be marked as API-only, which will prevent users from modifying any entity of that type in the UI.
Custom entities are only available for Fabric customers.
Ownership
All entities (regardless of type) support multiple owners. Owners can be a DX team, a DX user, or a combination of both.
Ownership becomes especially helpful in DX when Initiatives on scorecards are created to drive improvements to your systems.
Owners are automatically assigned to entities based on DX Deployment data using PR authorship, but can be edited if desired.
Aliases
Entities can be connected external resources through an alias. For example, for any given entity, you can add an alias to its corresponding PagerDuty service, GitHub repository, Datadog service, or Jira project, and more. This centralizes all entity information in one place and makes it easy to drill into the entity in third‑party services when needed.
When you enable a connection to a third-party service in Admin > Connections, aliases appear in your catalog entity type settings. DX will then continually monitor the possible aliases from those systems and automatically add them to your Software catalog when the name or identifier matches exactly.
Auto alias assignment can be disabled from the service entity type settings page.
For aliases that support URLs, the alias is linked to the external system from within Software catalog.
Supported aliases
Expand for a full list of supported aliases
| System | Alias type key | Database table | Supports URLs? |
|---|---|---|---|
| ADO repositories | ado_repository |
ado_repositories |
Yes |
| Bitbucket Server repositories | bitbucket_server_repository |
bitbucket_server_repositories |
Yes |
| Bitbucket repositories | bitbucket_repository |
bitbucket_repositories |
Yes |
| BugSnag projects | bugsnag_project |
bugsnag_projects |
|
| Datadog Monitors | datadog_monitor |
datadog_monitors |
|
| Datadog SLOs | datadog_slo |
datadog_slo_tags |
|
| Datadog services | datadog_service |
datadog_services |
|
| DX Deployments | dx_deployment_service |
deployment_services |
|
| Dynatrace entities | dynatrace_entity |
dynatrace_entities |
|
| Dynatrace SLOs | dynatrace_slo |
dynatrace_slos |
|
| Firehydrant services | firehydrant_service |
firehydrant_services |
|
| GitHub repositories | github_repo |
github_repositories |
Yes |
| GitLab repositories | gitlab_repo |
gitlab_projects |
Yes |
| Incident.io services | incident_io_service |
incident_io_services |
|
| Jira service management services | jsm_services |
jsm_services |
|
| Launchdarkly projects | launchdarkly_project |
launchdarkly_projects |
|
| Opsgenie services | opsgenie_service |
opsgenie_services |
|
| PagerDuty services | pagerduty_service |
pagerduty_services |
|
| Rollbar projects | rollbar_project |
rollbar_projects |
|
| Rootly services | rootly_services |
rootly_services |
|
| Sentry projects | sentry_project |
sentry_projects |
|
| ServiceNow services | servicenow_services |
servicenow_services |
|
| Snyk projects | snyk_project |
snyk_projects |
|
| SonarCloud projects | sonarcloud_project |
sonarcloud_projects |
|
| SonarQube projects | sonarqube_project |
sonarqube_projects |
|
| New Relic entities | newrelic_entity |
newrelic_entities |
Properties
Properties are the best way to extend and customize catalog entities. A property has a name, identifier, description, and type. The following property types are supported:
| Type | Description |
|---|---|
Boolean |
A True or False value. |
Computed |
Use a SQL query to compute a value for an entity using the $entity_identifier variable. Re-computed every 1 hour. |
Date |
A valid date in ISO8601, MM/DD/YYYY or MM/DD/YYYY HH:MM:SS format. |
JSON |
Any JSON object. |
List |
A JSON array of strings (e.g., ["a", "b", "c"]). |
Select |
A pre-defined list of string values. Limited to selecting one option. |
Multi-select |
A pre-defined list of string values. Multiple selections allowed. |
Number |
A number value. |
Text |
Any text value. |
URL |
A string in URL format. |
User |
A DX user. |
OpenAPI spec |
A JSON object containing an OpenAPI or Swagger specification. |
File matching rule |
Reads file contents from a connected repository and extracts pattern matches. Requires a Repository Integration. |
For more information about advanced property types, see the Advanced properties page.
Individual properties can be API-only, meaning users cannot edit them from the UI. They can only be managed via the entities APIs.
Additionally, properties can be marked as “hidden”, which will put them in a collapsed section on the entity details page and they will be hidden in the table of entities.
Relations
Relations define how different entities in your system are connected to each other. They establish meaningful relationships between entity types and provide a structured way to model dependencies, hierarchies, and associations in Software catalog.
Relations are defined between entity types and edited from the Software catalog administration page as shown here:
Once a relation definition is created, it can be applied to specific entities on the entity settings page:
For example, you can define a relation where entities of type API Endpoint can depend on entities of type Service. You can then apply this relation to specific entities, such as declaring that the Create Order API endpoint depends on the Checkout Service.
Relation properties
- Identifier: A unique identifier for the relation (letters, numbers, underscores, periods, and hyphens only)
- Source Entity Type: The type of entity that the relation originates from
- Target Entity Type: The type of entity that the relation points to
- Relation Type: One of the six standard relation types
- Cardinality: The relationship cardinality (one-to-one, one-to-many, many-to-one, or many-to-many)
- Description (optional): Detailed description of what the relation represents
Standard relation types
Relations support six standard relation types that cover the most common relationship patterns in enterprise systems. Each relation type is automatically assigned a corresponding inverse relation type.
| Relation Type | Description | Common Use Cases | Inverse |
|---|---|---|---|
| consumes | Indicates that one entity uses or consumes another | Services consuming APIs, applications using databases | consumed by |
| depends on | Shows a dependency relationship | Applications depending on infrastructure, services depending on other services | dependency of |
| parent of | Establishes a hierarchical parent-child relationship | Organizational structures, component hierarchies | child of |
| part of | Indicates membership or composition | Components being part of larger systems | contains |
| provides | Shows that one entity provides something to another | APIs providing data to applications, services providing functionality | provided by |
| manages | Indicates management or control relationship | Systems managing resources, administrators managing systems | managed by |
How inverse relations work
When you create a relation from Entity A to Entity B with type “depends on”, the system automatically creates the inverse relationship from Entity B to Entity A with type “dependency of”. This ensures that:
- The relationship is visible from both perspectives
- Data consistency is maintained
- Navigation between related entities works in both directions
Relation cardinality
Cardinality defines how many entities can be involved in a relationship. Relations support four cardinality options:
- One-to-one (1:1): Each source entity can be related to only one target entity, and each target entity can be related to only one source entity
- One-to-many (1:N): Each source entity can be related to multiple target entities, but each target entity can be related to only one source entity
- Many-to-one (N:1): Multiple source entities can be related to one target entity, but each source entity can be related to only one target entity
- Many-to-many (N:N): Multiple source entities can be related to multiple target entities
Cardinality enforcement
The system automatically enforces cardinality rules to maintain data integrity. When you attempt to create a relationship that would violate the cardinality constraints, the system will automatically remove existing relationships to make room for the new one.
This enforcement ensures that your relationship data always conforms to the defined cardinality rules and prevents inconsistent or invalid relationship states.
Cardinality enforcement applies to source and target separately. So if a relation is between two entities of the same type and has one-to-one cardinality, each entity can have a relation to up to two other entities (one as source, one as target). For example, with a relation “a service depends on a service” (1:1 cardinality), Service A can depend on Service B, and Service B can depend on Service C. This is valid because Service B is the source of one relation and the target of another; cardinality is enforced per source and per target. It is not possible, however, for both Service A and Service B to depend directly on Service C with 1:1 cardinality.
Examples
Service dependencies
Service "Payment Service" → depends on → Service "User Service"
Service "Payment Service" → provides → API "Payment API"Organizational structure
Team "Backend Team" → parent of → Team "API Team"
Application "E-commerce App" → part of → System "Customer Platform"Technical notes
- Relations are automatically validated to ensure they only connect compatible entity types
- Inverse relations are automatically maintained and cannot be manually edited
- The system prevents circular dependencies in hierarchical relationships
- All relations are scoped to your account and cannot conflict with other accounts
Identifiers
DX uses unique identifiers for parts of Software catalog to provide a stable, human-readable reference for use in external systems. Entities, Entity Types, Properties, and Relations each have an identifier that is unique across your entire account. These identifiers allow easy API access, enable automations, and provide stable references for you to use in external systems.
Identifiers must only contain letters, numbers, underscores, periods, and hyphens.
Repository integrations
Repository integrations are different from data connectors in DX, as they are built specifically for Software catalog to read file contents directly from your source code repositories. This allows DX to extract data from your repos and surface it across Software catalog.
File matching rules
File matching rules let you define patterns (either substrings or regular expressions) that are matched against the file contents of a connected repository. To create a file matching rule, a repository integration must be connected.
For example, file matching rules can answer questions like:
- Does this service have a “Local development” section in its README?
- Does this service run unit tests in a GitHub Actions workflow?
- Does this service have an up-to-date version of a critical internal library dependency?
Supported providers
Support for additional providers is coming soon.
Feature availability by plan
All DX customers have access to Software catalog, but purchasing Fabric (whether standalone or part of a bundle) provides deeper customization and functionality - see below:
| Feature | All customers | Fabric |
|---|---|---|
| Service entity type | Yes | Yes |
| Team entity type | - | Yes |
| Ownership | Yes | Yes |
| Aliases | Yes | Yes |
| API management | Yes | Yes |
| Entity Discovery | Yes | Yes |
| Custom Entity Types | - | Yes |
| Properties | - | Yes |
| Relations | - | Yes |