| \n\nName\n\n | \n\nUnique and meaningful name of the digital integration.\n\n |
| \n\nNumber\n\n | \n\nNumber of the digital integration. This field is automatically generated with the DINTG prefix and can't be edited.\n\n |
| \n\nProvider Digital Interface\n\n | \n\nName of the digital interface. Because a digital integration between two business applications or services uses a digital interface \\(API\\), you must select an interface related to the provider business application or service. This field is automatically generated and can't be edited.\n\n |
| \n\nProvider Business Application\n\n | \n\nName of the business application that provides the digital interface that enables other applications to consume or ingest data. Changes, ownership, and responsibilities of the interface are often connected to the provider.**Note:** The provider and subscriber roles define interface ownership, not data flow direction. The provider owns the digital interface; the subscriber consumes it. Data flow direction—whether incoming, outgoing, or bidirectional—is set separately using the **Data Flow Direction** field and reflects which application initiates the connection. For example, the provider can receive data \\(incoming\\) if the subscriber initiates the connection. For more information, see [Example: Provider and subscriber with data flow directions](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-portfolio-management/example-prov-n-subsc-roles-with-data-flow.md).\n\nThis field is automatically generated and can't be edited.\n\n |
| \n\nSubscriber Digital Interface\n\n | \n\nName of the digital interface that subscribes for the integration.\n\n |
| \n\nSubscriber Business Application\n\n | \n\nName of the business application that uses the provided interface to consume, exchange, or ingest data to support a business capability. The subscriber business application is affected by the changes or an outage, causing connection or data loss.**Note:** The provider and subscriber roles define interface ownership, not data flow direction. The provider owns the digital interface; the subscriber consumes it. Data flow direction—whether incoming, outgoing, or bidirectional—is set separately using the **Data Flow Direction** field and reflects which application initiates the connection. For example, the provider can receive data \\(incoming\\) if the subscriber initiates the connection. For more information, see [Example: Provider and subscriber with data flow directions](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/application-portfolio-management/example-prov-n-subsc-roles-with-data-flow.md).\n\n |
| \n\nSubscriber company\n\n | \n\nReference to the \\(external\\) company subscribing to this integration.\n\n |
| \n\nType\n\n | \n\nType of the integration. Use the following options:\n\n- **Data Integration**: Use this option when the integration must mainly focus on the exchange of data such as users, groups, locations, configuration items, and departments.\n- **Process Integration**: Use this option when the integration is about an interaction of transactional data to support a specific process.\n- **User interface Integration**: Use this option when the integration opens a connection with another application and sends app data via a URL to query the application.\n\n |
| \n\nSubtype\n\n | \n\nSubtype of the integration.This field appears only when **Data Integration** is selected from the **Type** field. Use the following options:\n\n- Process configuration\n- Foundation data\n- Configuration items\n- Events\n- Reporting\n- Sys log\n\n |
| \n\nVersion\n\n | \n\nVersion of the integration. You can apply a practice of designing, planning, and managing changes to an Integration. You can describe the different changes and capabilities according to version in the **Description** field. This field helps Application Owners and Architects to look up which version of an integration is in use. This also helps to decide whether to change the life cycle.\n\n |
| \n\nLife Cycle Stage\n\n | \n\nLife cycle stage of the integration. Helps to track the life cycles for products, assets, contracts, CIs, locations, and other objects. Using the standard CSDM life-cycle values helps you to track objects through their transitions over time. Reporting can therefore accurately reflect the actual states of CIs: usage, availability, end of support, and so on.\n\n |
| \n\nLife Cycle Stage Status\n\n | \n\nLife cycle stage status of the integration. The state transition of a Digital Integration guides you through the different stages of its life cycle. A life-cycle state is the combination life-cycle stage and life-cycle status of a Digital Integration during the life cycle.\n\n |
| \n\nBusiness Unit\n\n | \n\nName of the business unit that the integration belongs to.\n\n |
| \n\nDescription\n\n | \n\nDescription of the digital integration. Explain why the integration is being created and what business value it adds.\n\n |
\n