In 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 of record. A model defines the tables, fields, read/update/create operations, and table join relationships that capture a specific business process or dataset. After a model is configured, it becomes a data source for building apps, flows, playbooks, workspaces, and more.

Zero Copy Connector for ERP includes a standard set of models and supports creating custom models from scratch or by cloning existing ones. Each model is tied 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.

Key benefits

Models 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.

Through input and output parameter mapping, you define exactly which ERP fields are used and exactly what is sent back to the ERP on reads, updates, and creates. This means sensitive fields can be excluded at the model level before data ever reaches remote or extraction tables.

Models support a range of underlying connection methods (table reads, BAPIs, RFC, OData, IDoc, and REST APIs), so you can match the method to what's available and appropriate for the ERP module and operation type you're working with.

After a model is built and its operations are configured, it can be used 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.

Use case

A developer is building a vendor management application and needs to retrieve vendor data from SAP, allow updates to vendor payment terms, and create new vendor records.

Instead 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: a Read operation using an RFC/BAPI entity to retrieve vendor details, an Update operation using OData to write payment term changes back to SAP, and a Create operation using a BAPI to create new vendors.

The completed model is then used as the data source for a Workflow Studio flow that triggers whenever 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, all without anyone needing to log into the SAP system.