Building custom models in Zero Copy Connector for ERP

[Enevoldsen]

Why and when to create a custom model

ERP Content Packs are the fastest way to get started with Zero Copy Connector for ERP. If your use case maps to a pre-built model in Quote to Cash, Source to Settle, or Enterprise Data Foundation, start there. Clone it, configure it, go live.

But ERP Content Packs cover common patterns, not every pattern. The moment you needs access to an SAP entity outside that scope, or wants to use a different protocol than the one the pre-built model uses, a custom model is the answer.

There are three situations where building custom is the right call.

1) The SAP entity the use case needs does not exist in any ERP content pack. SAP has thousands of BAPIs and  hundreds of OData services available. The pre-built models cover a fraction of that surface. If the use case involves a custom SAP entity, an industry-specific object, or a standard SAP entity that happens not to be included, a custom model is what gets you there.

2) Your SAP team has a preference on protocol. Some SAP governance policies favour OData v2 over RFC for external access, particularly in S/4HANA environments where clean core principles are in play. You might want to read Sales Orders via API_SALES_ORDER_SRV rather than the BAPI approach the pre-built model uses. That is a completely valid choice, and a custom model makes it possible.

3) A cloned ERP Content Pack model needs to go further than configuration allows. Cloning gives you a starting point. If the required changes go beyond field mapping and filtering, a custom model built from scratch gives you full control from the beginning.

What a model actually is

A model in Zero Copy Connector for ERP is a configured interface between a specific SAP entity and the ServiceNow platform. It describes what operation you are performing (Create, Read, or Update), what inputs the SAP entity expects, and what output it returns.

The platform does not distinguish between a pre-built model and one you built yourself. Once a custom model exists in the Model Manager, it surfaces in Flow Designer, Remote Tables, and ETL extraction exactly like anything from a ERP Content Pack. Downstream developers do not need to know or care how the model was created.

Models use human-readable field names, not SAP technical names. That is deliberate. It means the person building a workflow in Flow Designer does not need to know what the technical nameVBELN means. They see "Sales Order Number" and work with that.

The two model types

Two model types exist in Zero Copy Connector for ERP: ERP Models and Platform Models. The difference is about how the model's input and output are defined.

ERP Models follow the data structure of the connected SAP system. Input and output fields reflect SAP's own structures, translated into human-readable names. These models support Create, Read, and Update operations and handle both simple and complex input and output types. This is the type you will build most often when creating a custom model for a specific SAP entity.

Platform Models are different in a fundamental way. When you create a Platform Model, the input and output fields are not defined by the SAP structure alone. They are mapped to an ODM (One Data Model) table definition. This means the model semantically conforms to a shared ServiceNow data standard rather than the ERP's native format.

The practical effect is significant. A Sales Order field called VBELN in SAP, SalesOrder in one OData service, and SALESDOCUMENT in a BAPI all describe the same thing. A Platform Model resolves that inconsistency by mapping all of those to a single ODM field, for example OrderNumber on the ODM SalesOrder table. Any workflow or application consuming that model works with the standardised definition, not the SAP-specific name. This is very power full, if you work with use cases which integrates with different types of ERP systems and releases. 

You can map to an existing ODM table, or define your own table structure and use it as the mapping target. The outcome is the same either way: the model output carries semantic meaning that the platform, AI agents, and downstream applications can reason about consistently.

Platform Models support Read operations only and are designed for simple input and flat output types. If the use case involves Create or Update operations, or complex nested output, an ERP Model is the right choice.

Supported protocols and when to choose each

Three protocols are supported for custom models: RFC/BAPI, OData v2, and IDoc. The right choice depends on what the ERP system exposes for the entity you need and what the ERP team will allow.

Building Models for SAP:

RFC/BAPI is the most widely available option. SAP ECC and S/4HANA expose thousands of BAPIs, and most SAP Basis teams are comfortable granting RFC access. If you are working with ECC, RFC is often the only practical option for many entities. For S/4HANA it remains valid, though some customers are moving away from RFC for new integrations as part of clean core governance.

OData v2 is the preferred protocol in S/4HANA environments where clean core or API-first policies are in place. The SAP API Business Hub documents the available standard OData services. If the service the use case requires is available and can be activated in SAP, OData v2 is a clean choice. The activation step is a SAP Basis task and is often the most common delay in getting an OData-based model live.

IDoc is the right fit for asynchronous, document-based exchange. If the use case involves posting documents to SAP rather than calling a transactional function in real time, IDocs are worth considering. Less common for real-time workflow scenarios, but relevant for batch or event-driven patterns.

The practical build process

Everything happens in the Model Manager. There is no custom code required at any stage.

The build follows four steps.

1) Create the system connection. The ERP system record in Zero Copy Connector for ERP holds the connection configuration. For OData connections, this means an HTTP connection with a credential alias. For RFC connections, the Zero Copy Connector for ERP (Probe) configuration is defined here. Once the system record is saved and the heartbeat confirms a successful connection, the Model Manager retrieves the available BAPIs, OData services, and tables from the SAP system.

2) Create the model record. Give the model a name, select the ERP system, and specify the SAP software version. The software version matters because it helps managing which entity types can be used. SAP SuccessFactors Cloud, for example, only offers OData v2 as an entity type.

3) Add an operation and select the entity. Each model has at least one operation: Read, Create, or Update. Within the operation, you select the entity type (BAPI, RFC function, OData service, or table) and then the specific entity from the catalog retrieved from SAP. For OData, selecting a service triggers a metadata call to read the available entity sets.

4) Review field mappings. ZCC for ERP generates human-readable field names from the SAP technical names. Review these and adjust where the auto-generated names are not clear enough for the people who will use the model in workflows.

The most common blocker at build time is SAP-side readiness, not the configuration in ServiceNow. For OData models, the relevant service must be activated in the SAP system before the Model Manager can read its metadata. For RFC models, the RFC user account needs the correct authorisation objects for the BAPIs the model will call. Confirming this with the SAP team before starting the build saves time.

Check the documentation to find more details related to Model creation

What you can do with a custom model once it is built

The moment a custom model is saved and validated, it is available across the platform in the same way as any pre-built model.

1) Flow Designer surfaces the model as a native action. Developers drag it into a flow, map inputs from the workflow context, and map outputs to downstream steps. No scripting needed for standard Read and Write operations.

2) Remote Tables make the SAP entity queryable as if it were a ServiceNow table. Useful for lookup's and any situation where you want to display live SAP data in a ServiceNow interface without copying it.

3) ETL Extraction pulls data from the model into ServiceNow on a schedule. This is the one pattern that does involve a data copy, which is worth being clear about. Remote Tables and Flow Designer actions are real-time and zero-copy. ETL is a deliberate choice for scenarios where local querying performance matters more than real-time freshness.

4) Scripted API is the option to reach for when Flow Designer actions are not enough. It gives developers a programmatic interface directly on top of the Model Manager, which means the same models you configure for Remote Tables and ETL are accessible via script, with no separate integration layer required.

5) AI Agents and Now Assist can call custom models as part of multi-step agentic workflows. If the use case involves an AI agent that needs to read or update SAP data during a conversation or automated task sequence, the model is the mechanism that makes that possible.

Install Zero Copy Connector for ERP from the store