---
title: Manage Business Terms
description: >-
  Define a common language with terms, ownership, and taxonomic relationships so
  the catalog retains business meaning.
audiencia: Administrator | Data Owner | Data Steward | User
roles: >-
  Administrator; Data Owners and Data Stewards within their applicable
  capability and scope; read access as authorized
modulo: Business Terms
revision: '2026-10-19'
section: gobernar-datos
order: 20
sources:
  - CONTEXT.md
  - Modelodeobjetosyrelaciones.md
  - 'Roles,capacidadesyalcance.md'
  - Módulosydependencias.md
  - Cómoleerelmapaderelaciones.md
locale: en
---
# Manage Business Terms

Business Terms establish a shared vocabulary for interpreting catalog data. In GovFrame, they include a definition, relationships, ownership, and a company-specific code. Their primary association is with a Domain, and they can be linked to one or more Entities; through component relationships, they can provide context to other catalog nodes. In this way, the term explains the meaning without replacing the taxonomic structure or the technical data.

Terms belong to a single company, and search supports partial matches and pagination. Treat the code as a governance identifier and the definition as the explanation a business person should understand. Do not use the code to replace a readable name in functional documentation, or expect the interface localization to translate content recorded by the company.

## Before you begin

- **Role and scope:** The Administrator can manage the company catalog. Data Owners and Data Stewards need the applicable business capability and a Domain or Subdomain within their scope to create, edit, or associate items. Profiles with read access can locate and read only the objects they are permitted to access.
- **Module:** Confirm that **Business Terms** is enabled. If it is disabled, the interface does not present it as operable, and the backend rejects module operations; existing data is not automatically deleted.
- **Prerequisites:** Identify the responsible Domain and, where applicable, the linked Entities. Gather an agreed definition, a readable name, a company-specific code, and the person or role that will assume ownership.

> **Synthetic example:** The term **Active Customer** may belong to the *Customer Relationships* Domain and be linked to the *Customer* Entity. The definition should clarify the applicable business criterion; it should not be inferred solely from the name of a technical column.

## Recommended workflow

1. **Search before registering.** Use partial search to detect synonyms, homonyms, or a definition already in effect in the same context. Review the paginated results before creating another term that looks similar.
2. **Write the business definition.** Explain what the concept represents, its boundaries and, if necessary, the conditions that prevent ambiguity. Distinguish the concept from a table, report, API, or physical expression.
3. **Assign the taxonomic context.** Link the term to the Domain and the Entities it describes. If an additional link is needed, use it to express a documented relationship, not to artificially extend the scope to nodes that merely share a name.
4. **Record ownership.** Make it clear who is responsible for the definition. Responsibility recorded in the catalog complements the session role: by itself, it does not grant editing or approval capabilities beyond the person’s scope.
5. **Connect the term to valuable uses.** It can participate in a Data Contract and document a KPI. When establishing these relationships, retain a single definition and do not create copies of the term for each Product, Contract, or indicator.
6. **Review the meaning when the context changes.** If an Entity, Attribute, or definition evolves, assess whether the term, its ownership, and its links are still accurate. The available documentation confirms relationships and term management, but does not prescribe a workflow or states for that review.

## Expected outcome

The catalog contains searchable terms defined in business language and connected to the relevant Domain and Entities. People can distinguish what a concept means, who is responsible for it, and where to consult its relationships with Products, Contracts, or indicators, without confusing it with a physical name.

A term does not guarantee that an associated technical field, Quality Rule, Product, or Contract exists. Those objects are registered and related independently. Likewise, a line on the relationship map represents a saved link; a relationship must not be inferred from name similarity.

For more information, see the [object and relationship model](/en/explicaciones/modelo-de-objetos-y-relaciones/), [how to read the relationship map](/en/guias/como-leer-mapa-de-relaciones/), [roles, capabilities, and scope](/en/referencia/roles-capacidades-y-alcance/), and [modules and dependencies](/en/referencia/modulos-y-dependencias/).