Models 101: Platform vs ERP Models

[Enevoldsen]

Open Zero Copy Connector for ERP, go to create a model, and the first decision you hit is the model type. Platform or ERP. It looks like a minor configuration choice, and it isn't. The type you pick decides what the model can do for the rest of its life, so it's worth understanding the difference before you commit to one.

The short version is that the two differ in whose data structure they follow. A Platform Model maps the ERP's fields onto a platform table you already have, so the data comes through in ServiceNow's standardised shape. An ERP Model follows the ERP's own structure instead, keeping the formats and relationships the source system defines. Most of what matters follows from that one distinction, including which operations each one supports.

What a Platform Model actually is

A Platform Model takes the input and output fields of an ERP read and maps them onto a platform table that already exists on your instance. You pick the table when you create the model, point the ERP fields at it, and from then on the data is expressed in ServiceNow's own structure rather than the ERP's. The data itself stays in the ERP and is read in place through a Data Fabric or remote table. The model isn't copying anything across; it's lining the ERP's fields up against a table you already understand.

The point of doing this is standardisation. SAP speaks in technical field names and its own data shapes, and a Platform Model translates that into ServiceNow's common model, the ODM tables your other applications already use. That's what closes the ontology and semantics gap: a cost center read through a Platform Model lands in the same shape as every other cost center on the platform, so anything built on top of it doesn't need to know or care that the source was SAP. You can map onto an existing ODM table or onto a table definition of your own, and the outcome is the same either way. The trade is that this works for simple, flat data and for reading, not for writing back or for anything with nested structure to it.

That suits a surprising amount of work. Most of the time a workflow touches ERP data it's to check something or to fill something in. A request form confirms a cost center exists and is still active before it lets the request through. An incident form pulls an asset's acquisition date and depreciation status out of SAP so the technician isn't typing it by hand. A procurement flow checks whether a vendor is on the approved list. None of these change anything on the ERP side. They ask a question, take the answer, and carry on. For that read-and-standardise pattern a Platform Model is both the right tool and the simpler one.

Where Platform Models run out

The moment your workflow needs to put something back into the ERP, a Platform Model can't help you. The same is true the moment the data stops being flat.

ERP data frequently isn't flat. A purchase order isn't a single row, it's a header with a set of line items hanging off it, each line carrying its own material, quantity, and account assignment. An employee in SuccessFactors can hold several assignments at once, each with its own effective dates. A request that covers different kinds of materials needs different fields depending on what's being ordered, so the shape of the input changes from one submission to the next. None of that collapses cleanly into a single flat ServiceNow table, and a Platform Model is a single flat table by definition. That is the wall you eventually hit, and it's where the ERP Model earns its place.

What an ERP Model gives you

An ERP Model holds onto the ERP's own structure instead of flattening it, and it supports create and update operations alongside read. That is the real reason to reach for one. You can build a new record in the ERP from ServiceNow, you can change an existing one, and you can carry nested or conditional data without pretending it's simpler than it is.

Take the purchase order again. Your approval runs in ServiceNow, and when it clears you want the PO created in SAP with everything attached: the header, every line item, the account codes. That's a create, and a nested one, so it has to be an ERP Model. The model describes the input the way SAP expects it, points at the BAPI that creates the order, and hands back the confirmation or the error. SAP's own validation runs server-side, so material codes and quantities get checked there, and you don't rebuild any of that logic on the ServiceNow side.

Onboarding is the same problem from the update angle. Provisioning a new hire means setting hire date, manager, cost center, and employment type in SuccessFactors together, and those fields lean on one another in ways the system enforces. An ERP Model lets you update them in one operation and lets SuccessFactors apply its rules. The variable material request is a third version of the same idea: because an ERP Model can carry conditional input, one form can ask for shelf location on a hand tool and certification codes on a hydraulic press without you maintaining a separate model for every variation.

What you pay for this is proximity to the ERP. The structure is richer, there's more to map, and you're working with the system's own shape rather than ServiceNow's tidied version of it. In exchange you get the write operations and the fidelity a Platform Model doesn't have.

Choosing between them

The question that settles it nearly every time is whether you need to write back to the ERP. If you're creating or updating records, it's an ERP Model and there's little more to decide. If you're only reading, the next question is how the data is shaped. Flat and simple points you at a Platform Model. Nested or variable points you back at ERP. And if there's no standard ServiceNow table that fits what you're pulling, you'll land on an ERP Model regardless of whether you're writing.

Getting this right early matters because the two mistakes aren't equally cheap. Choose a Platform Model and then find halfway through that you need to write back, and you're rebuilding it as an ERP Model and reworking whatever you'd already wired to it. Choose an ERP Model where a Platform Model would have done, and nothing breaks, but you've taken on more mapping than you needed and your data sits in the ERP's native shape rather than the standardised ODM form that everything else on the platform speaks. The first mistake costs a rebuild. The second costs you that standardisation and some extra work. Both are avoidable by asking the write-back question, and then the data-shape question, before you start.

A note on content packs

If you'd rather see the distinction in practice than read about it, the shipped content packs are the easiest place to look. Sales Orders, source-to-settle, the SuccessFactors content: they're assembled from both model types, and the split follows exactly the logic above. The plain reads are Platform Models. The creates and the complex structures are ERP Models. They're built to be cloned and adapted, so you can take one apart, work out why each model was made the way it was, and lift the pattern onto your own use case.

Starting out

If you're new to this, build a Platform Model first, against something undemanding. Read a cost center out of SAP, get it onto the instance, wire it into a flow, and confirm the whole path works end to end before you do anything ambitious. Once that's solid and you genuinely need to write back, moving to an ERP Model is the same sequence of steps with more structure to define: the inputs, the outputs, the protocol you're going over, all tested against real data. The mechanics carry across. What changes is the shape of what you're modelling, and the fact that you can now create and update rather than only read.