{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":20879,"path":"integrate-applications/erp-integration-framework/exploring-erp-models.md","title":"Exploring Zero Copy Connector for ERP models","bundle":null,"doc_type":null,"release":"australia","body":"\n# Exploring Zero Copy Connector for ERP models\n\nBuild ERP \\(Enterprise Resource Planning\\) models in Zero Copy Connector for ERP to create read, update, and create operations and organize mirrored ERP data.\n\nIn Zero Copy Connector for ERP, a **model** is the foundational building block for accessing and working with ERP data. It represents the logical structure and organization of data coming from the ERP system. A model defines the tables, fields, read/update/create operations, and table join relationships that capture a specific business process or dataset. After you configure a model, you can use it as a data source for building apps, flows, playbooks, workspaces, and more.\n\nZero Copy Connector for ERP supports two types of models:\n\n-   ERP models follow the data structures defined by the external ERP system itself, accommodating the unique formats of each connected system.\n-   Platform models map ERP input and output fields to existing ServiceNow platform tables, standardizing ERP data into the data structure of the ServiceNow AI Platform for tighter integration.\n\nZero Copy Connector for ERP includes a standard set of models and supports creating custom models from scratch or cloning existing ones. Each model connects to one ERP system, and each model can have only one read operation, one update operation, and one create operation defined. Operations use one of several underlying methods depending on the type of operation and what the connected ERP system supports.\n\n\\[Omitted image \"erp-canvas-explore-models.png\"\\] Alt text: ERP model record showing information including name, module, and ERP system.\n\n## Key benefits\n\nModels create a consistent, reusable data layer. You can connect the same ERP table to multiple models, and build as many models as needed to represent different business areas.\n\nThrough input and output parameter mapping, you define which ERP fields are used and what the model sends back to the ERP system on reads, updates, and creates. This means sensitive fields never reach remote or extraction tables. The fields are excluded at the model level before any data flows.\n\nModels support a range of underlying connection methods \\(table reads, BAPIs, RFC, OData, IDoc, and REST APIs\\). You can match the method to what's available and appropriate for the ERP module and operation type you're working with.\n\nAfter a model is ready and its operations are configured, use it as a data source across Workflow Studio flows, ServiceNow Studio, Workspace Builder, UI Builder, Table Builder, and playbooks. This makes models a universal integration point rather than something custom-built for a single use case.\n\n## Use case\n\nA developer is building a vendor management application and needs to retrieve vendor data from SAP, enable updates to vendor payment terms, and create vendor records.\n\nInstead of building three separate integrations, the developer creates a single vendor model connected to the appropriate SAP system. In the model manager, they add three operations:\n\n-   A read operation using an RFC/BAPI entity to retrieve vendor details.\n-   An update operation using OData to write payment term changes back to SAP.\n-   A create operation using a BAPI to create vendors.\n\nThe developer uses the model as the data source for a Workflow Studio flow that triggers when a new vendor request is submitted. The flow automatically reads existing vendor data, routes through an approval, and writes the approved changes directly back to the SAP system. No one needs to log in to the SAP system directly.\n\n"}}