Zero Copy Connector for ERP: frequently asked questions

[Enevoldsen]

A quick reference for the questions that come up most often about Zero Copy Connector for ERP: what it is, what it connects to, how the data moves, and how it sits alongside the rest of your ERP landscape. Where a question has a full walkthrough elsewhere, the answer points you to it.

The basics

What is Zero Copy Connector for ERP?

It is a scoped ServiceNow application that gives your workflows, agent and applications real-time read and write access to ERP data, without copying that data into ServiceNow and without a separate integration platform sitting in the middle. An approver sees live purchase order details on a ServiceNow task, a workflow creates a vendor in SAP when a request is approved, a technician confirms a maintenance order from Employee Center, and each of those runs against the ERP system of record. The connector targets multiple ERP systems. It installs from the ServiceNow Store.

Is this the same connector I use for Snowflake or Databricks?

No, though they share a name and an idea. The Zero Copy Connector you may know for data platforms like Snowflake, Databricks, or BigQuery gives read-only access to a data warehouse. Zero Copy Connector for ERP is a separate application built for ERP systems, and it reads and writes: it can create and update records in SAP, not only read them. Both follow the zero-copy principle of using data where it lives rather than syncing a copy, but the ERP connector is the one to reach for when your source is SAP, SuccesFactors or Workday and your workflow needs to write back. This FAQ covers the ERP connector; for the data-platform connectors, see the Workflow Data Fabric community.

Which ERP systems can it connect to?

• SAP ECC on NetWeaver 7.31 or later, and SAP S/4HANA on any version, both on-premise and cloud.
• SAP SuccessFactors connects over OData for HR data such as position management and org structure access.
• Workday connects over REST, which is the most recent protocol added to the connector.

There is a fuller breakdown in Supported ERP systems in Zero Copy Connector for ERP.

Does it copy my ERP data into ServiceNow?

By default, no. The connector reads data in place and renders it in ServiceNow as if it were local, and nothing is retained once the query is done. The one deliberate exception is the ETL extraction pattern, where you choose to pull a copy into ServiceNow tables on a schedule, usually to support search, reporting, or list views over large volumes. That is a decision you make per use case, covered in ETL Extraction using Zero Copy Connector for ERP. Everything else stays where it is, in the source system.

 

Connecting

 

Does it need middleware like MuleSoft or SAP BTP Integration Suite?

No. There is no need for MuleSoft, no need for SAP BTP Integration Suite, and no custom-built API layer between ServiceNow and your ERP. For on-premise SAP reached over RFC/BAPI, you do need a ServiceNow MID Server in your network running the SAP Java Connector (JCo), which is the same SAP-certified library other enterprise tools use. That MID Server is a lightweight ServiceNow component, not a separate integration product, and it needs no inbound firewall ports. For cloud sources reached over OData or REST, such as S/4HANA Cloud, SuccessFactors, or Workday, no MID Server is required.

Can I run it on top of existing middleware?

Yes. The previous answer is about whether you need middleware, and you do not. This is the other side of it: where you already have a middleware or API management layer in front of SAP, such as SAP BTP, MuleSoft, or an API gateway, the connector can sit on top of it rather than around it. That falls out of what the connector is underneath. At its core it is an abstraction over ERP APIs, so a model is defined against an API, whether a BAPI, an RFC, an OData service, or a REST endpoint, and turns that API into something you consume through configuration instead of code. For the HTTP protocols, OData v2 and REST, the endpoint a model points at can be a middleware or gateway URL just as easily as SAP itself, reached through the MID Server or directly for cloud sources. So an existing middleware investment is something the connector uses rather than something it makes you bypass, and where there is none, there is nothing to add.

 

Which connection protocols does it support?

Four, and which one applies depends on the system and the entity rather than a single system-wide setting. For SAP, RFC/BAPI and OData v2 are equal design choices made per entity, so it is normal for one system to use both: RFC/BAPI runs on-premise only and needs the MID Server and JCo, while OData v2 serves cloud with no MID Server and is also available on-premise wherever the OData service is activated. REST is the most recent protocol added, and it is the path for Workday as well as for the newer REST APIs that SAP and SuccessFactors expose. IDoc completes the set as a send-only path, used to push creates and updates into SAP. Pick the protocol that fits the entity and the operation rather than defaulting to one. For the SAP mechanics, see Connecting via RFC/BAPI and Model creation using an OData service.

 

What does my SAP system need for this to work?

A service-type SAP user with a specific set of RFC authorisation objects, plus the SAP JCo library files staged on the MID Server. The exact authorisation objects differ between development and production or test systems, so rather than hard-code a list that goes stale, work from the current requirements page in the docs and have your SAP Basis team provision them. Installing and running the connector makes no changes to the SAP core. The Connecting via RFC/BAPI article covers the ServiceNow side, and the ERP integration documentation has the authorisation detail.

Can one MID Server handle more than one SAP system?

Yes for ERP systems, with one boundary to keep in mind. A single MID Server can connect to several ERP systems, so one MID Server can front more than one SAP landscape. What it cannot do is serve more than one ServiceNow instance: each MID Server registers to exactly one instance, and that link is set on the MID Server machine when the agent is installed. 

Models and data

 

What is the difference between an ERP Model and a Platform Model?

An ERP Model connects directly to the ERP system: data is read from and written to the source as the system of record, and the model preserves the native structure, including nested and complex fields. A Platform Model maps ERP input and output fields onto an existing ServiceNow platform table so that data from different ERP sources lands in a common, standardised shape. A Platform Model is about normalising the data onto a shared model, not about copying it. Models 101: Platform vs ERP models works through both with examples.

Are the content packs the limit of what I can build?

No. Content packs such as Enterprise Data Foundation, Quote to Cash, and Source to Settle are pre-built accelerators and worked examples, not the boundary of what the connector can do. You can build a custom model for any entity using any supported protocol, and it will surface in Flow Designer exactly like a pre-built one. As an example, the pre-built Sales Orders model uses RFC/BAPI, but if you would rather work over OData you can build your own model on SAP's API_SALES_ORDER_SRV service, provided it is activated in SAP. Start from Building custom models, and see Cloning and customising models for taking a content-pack model as a base.

Can it write back to ERP, or is it read only?

It writes back. ERP models support create, read, and update operations against the live system of record, so a ServiceNow workflow can create a vendor, update a sales order block, or write a maintenance confirmation into SAP in real time. Writes can go through a BAPI, REST, OData, or an IDoc, where IDoc is a send-only path, used to push creates and updates into SAP.

Once a model is built, how do I use it?

Five interfaces sit on top of the same model, and because they all run through the one ERP Connector engine, you choose the one that fits the use case rather than rebuilding anything.

• The Flow Designer action, called Use ERP Data, is the low-code and no-code route for dropping an ERP step into a workflow.
• When you want full control from a server-side script or business rule, call the model through its scriptable API.
• Remote Tables expose ERP data as virtual tables you can query like a local Glide table, which is what you want for form fields, list views, and live lookups.
• The extraction tool handles bulk movement into ServiceNow for large data and ETL scenarios.
• And the Trino connector gives analytical query access to ERP data for reporting and analytics workloads.

Use patterns to read live through when the value has to be current at the moment someone looks, such as a purchase order amount on an approval or a cost centre check at form submission. Extract on a schedule when you need ServiceNow-side search, reporting, or list views over large datasets and a short delay is acceptable. Live reads keep nothing in ServiceNow, while extraction stores a scheduled copy. See Customising Remote Tables for the live pattern, ETL Extraction for the scheduled one, and Scripted APIs for Zero Copy Connectors for the scripting route.

Security and governance

 

Where do security and access control come from?

Two places, working together. On the SAP side, the connector can only touch what the configured service user is authorised to touch, so your SAP authorisation model still governs what is reachable. On the ServiceNow side, ERP data respects standard ACLs and scoped roles, and model operations carry their own permissions. All access runs through ServiceNow's standard audit framework. 

 

Does any of this change my SAP core?

No. Nothing about installing or running the connector modifies the SAP core. That is the point of the approach for clean-core programmes: workflow and customisation logic moves onto ServiceNow while SAP stays standard, and net-new requirements can be built on ServiceNow rather than added back into the core as custom ABAP.

 

Where to go next

If you are standing up a connection for the first time, the Quick-Start Guide runs the whole path from install to a first working use case, and Common setup issues and fixes covers the handful of places a first setup usually stalls. For the wider picture and the exhaustive field and authorisation detail, the ERP integration documentation is the reference. Anything not covered here is worth raising in the Workflow Data Fabric community.