Integrations Inventory and Attributes

Description — A human-readable, self-documenting unique name for this integration, typically constructed by concatenating Source Entity Semantic ID, Target Entity Semantic ID, and Integration Payload. Permanent once assigned.

Benefit(s) — Provides an unambiguous, portable identifier for this integration that is meaningful to practitioners without lookup. A well-formed Semantic ID communicates the integration’s purpose in a Jira ticket, a Slack message, a governance report, or a risk register without additional context.

Source — Manual.

Examples — Salesforce-SAP-CustomerProfile, ClaimsSystem-PaymentGateway-ClaimPayment, ProductionDB-UAT-OrderData

Notes — Recommended construction: {SourceEntitySemanticID}-{TargetEntitySemanticID}-{Payload}. When multiple integrations exist between the same source and target, the Payload segment distinguishes them. Once assigned, the Semantic ID is permanent and must not be reused after retirement.

Description — The type or class of entity that initiates or sends data in this integration. This is the Entity Type of the sending end, drawn from the IF4IT Noun Type taxonomy.

Benefit(s) — Makes the Integrations Inventory entity-agnostic — any two entities of any type can be connected in a single governed record. Enables portfolio-level analysis of integration patterns by entity type pair (e.g., all Application-to-Database integrations, all Human-to-Application integrations).

Source — Manual.

Examples — Application, Database, File System, Queue, API, Human, External Partner, Cloud Service, Message Broker

Notes — The Source Entity Type determines which Noun Type inventory the Source Entity ID and Source Entity Semantic ID reference. There is no closed list — any recognized Noun Type may appear here.

Description — The unique identifier for the source entity as it is recognized within the source system or its governing inventory. This is the system-level UID, not the Semantic ID.

Benefit(s) — Enables automated reconciliation between the Integrations Inventory and the governing inventory for the source entity. A Source Entity ID that appears in the Integrations Inventory but not in the corresponding Noun Type inventory signals a gap.

Source — Manual.

Examples — APP-00147 (Applications Inventory), DB-PROD-CLAIMS-01, FS-SFTP-VENDOR-DROP, QUEUE-PAYMENT-OUT

Description — The human-readable name for the source entity, drawn from its governing inventory record where one exists. For entities not yet formally inventoried, a descriptive plain English name.

Benefit(s) — Makes integration records immediately readable without lookup. Allows integration maps and dependency diagrams to display meaningful names rather than opaque system identifiers.

Source — Manual.

Examples — Salesforce CRM, Claims Processing System, SFTP Vendor Drop Folder, Payment Outbound Queue, SAP S/4HANA

Description — The type or class of entity that receives data in this integration. Mirrors Source Entity Type in structure.

Benefit(s) — Enables analysis of integration patterns by entity type combination. Surfacing all integrations where Target Entity Type = External Partner immediately identifies the enterprise’s external data sharing footprint.

Source — Manual.

Examples — Application, Database, File System, Queue, API, Human, External Partner, Cloud Service, Message Broker

Notes — Mirrors Source Entity Type. The full list of valid values is the same.

Description — The unique identifier for the target entity as it is recognized within the target system or its governing inventory.

Benefit(s) — Enables reconciliation between the Integrations Inventory and the governing inventory for the target entity.

Source — Manual.

Examples — APP-00203 (Applications Inventory), DB-DW-ANALYTICS-01, FS-REPORT-OUTPUT, EXT-PARTNER-BANKOFAMERICA

Description — The human-readable name for the target entity, drawn from its governing inventory record where one exists.

Benefit(s) — Makes integration records readable without lookup. Enables integration maps and dependency diagrams to display meaningful names.

Source — Manual.

Examples — SAP S/4HANA, Enterprise Data Warehouse, Regulatory Reporting File Store, Bank of America Payment Gateway

Description — A business-level description of the data or information being transmitted through this integration. Describes what is moving, not how it moves. Both structured data (JSON, CSV, database records) and unstructured information (PDF documents, images, audio files) are valid payloads.

Benefit(s) — Provides a governance-readable description of the integration’s content without requiring a formal data taxonomy to exist. Enables sensitivity classification, regulatory scoping, and business impact assessment at a glance.

Source — Manual.

Examples — Customer Profile, Bank Payment Instruction, Claims Record, Regulatory Filing, Supplier Invoice, PDF Contract Document, Audit Log

Notes — An Integration is also known as a Data and Information Integration — reflecting that both structured data and unstructured information flow through governed integrations. The Payload attribute captures this distinction at the record level.

Description — Whether data flows in one direction only (Unidirectional: Source to Target) or in both directions (Bidirectional).

Benefit(s) — Identifies integrations that carry return flows which may have different governance, performance, or sensitivity characteristics. A bidirectional integration that transmits sensitive data in one direction and acknowledgment codes in the other has an asymmetric risk profile that a single Direction flag surfaces immediately.

Source — Manual.

Examples — Unidirectional, Bidirectional

Notes — When a bidirectional integration has materially different protocols, owners, or sensitivity in each direction, consider creating two separate records — one per direction — rather than a single bidirectional record.