Section E · Production / Cloud

Customer Integrations

The enterprise stack FDE-DE meets at every deployment — ERPs, procurement suites, warehouses, BI tools, identity systems. API shapes, auth patterns, refresh cadences, and the political layer behind each one.

The enterprise data stack you'll meet

You don't have to know every system deeply, but you should be able to name the major players and what they're for. The mental map:

Source documents: SharePoint, Box, OneDrive, Google Drive, NetDocuments, iManage. Sometimes a homegrown file share.
Contract lifecycle (CLM): Ironclad, DocuSign CLM, Conga, Icertis, Agiloft, ContractWorks.
Procurement / source-to-pay (S2P): SAP Ariba, Coupa, Oracle Procurement Cloud, Jaggaer, Zycus.
ERP / financial system of record: SAP (ECC, S/4HANA), Oracle Fusion, Workday Financials, NetSuite, Microsoft Dynamics 365.
Warehouse: Snowflake, BigQuery, Databricks, Redshift.
BI: Looker, Power BI, Tableau, Hex, Mode, ThoughtSpot.
Identity: Okta, Microsoft Entra ID (formerly Azure AD), Ping, Auth0.
Observability / on-call: Datadog, PagerDuty, New Relic, Splunk.

A typical deployment touches 4–6 of these. Knowing which is on the customer's roadmap vs entrenched matters: a customer migrating from SAP ECC to S/4HANA is in a different conversation than a customer settled on either.

ERP systems

The system of record for finance. ERP integration is high-value and high-risk — political and technical.

SAP (ECC, S/4HANA)

The 800-pound gorilla. Largest customers run it.

Access patterns: BAPI (Business APIs — function-call style), IDoc (document-based async messaging), OData services (S/4HANA modern REST), SAP RFC.
Read first: pull supplier master, PO data, GL postings.
Write second: when (and if) the customer trusts you with writeback.
Watch out for: custom Z-tables (every SAP shop has them), heavy customization, slow approvals from the customer's SAP team.

Oracle Fusion / Cloud ERP

Modern REST APIs. Custom flexfields per customer mean schemas vary across deployments.

Workday Financials

SOAP web services + REST. Strong API surface but verbose.

NetSuite

Mid-market favorite. SuiteScript (server-side JavaScript) for custom logic; SuiteTalk REST/SOAP for integration. Custom record types per customer.

Microsoft Dynamics 365

Common in Microsoft-shop enterprises. Power Platform connectors are useful.

Procurement / S2P suites

Often where the customer's procurement team lives day-to-day. Integrating here means insight lands in their workflow.

SAP Ariba: the procurement-side counterpart to SAP ERP. Sourcing, contracts, supplier risk modules. APIs are workable but documentation is sparse.
Coupa: modern REST APIs, well-documented. Common at companies that didn't go all-SAP.
Oracle Procurement Cloud: similar tradeoffs to Oracle Fusion overall.
Jaggaer, Zycus, Ivalua: specialty procurement suites, more common in specific industries.

For document-AI platforms, the procurement suite is often the "where does the customer want supplier insights to land" target. Pushing renewal alerts, risk flags, or off-contract spend warnings into the procurement workflow is high-value.

Warehouses

Refer to 08-warehouse-and-integration for delivery patterns. The major systems:

Snowflake: most common in modern enterprises. Strong data-sharing model. Use Snowpipe or Streams + Tasks for ingestion.
BigQuery: Google-shop enterprises, AI/ML-leaning teams. Cheap for bursty workloads.
Databricks: when the customer's stack is Spark-heavy or ML-platform-flavored.
Redshift: AWS-shop enterprises, sometimes legacy. Slower-evolving than Snowflake.

Know each one's SQL dialect quirks at least at a "where to look it up" level. The biggest ones:

Snowflake: QUALIFY clause for filtering window-function output without a subquery.
BigQuery: arrays + structs are first-class; UNNEST is everywhere.
Redshift: limited window-function support compared to Snowflake; some functions are surprising.
Databricks: full Spark SQL; lots of overlap with Snowflake but the function names sometimes differ.

BI tools

Where business users actually look. Refer to 08 §bi for tradeoffs. Two notes specific to FDE:

Match what they have. Don't introduce a new BI tool unless the customer is explicitly looking for one. Resentment from the existing BI team kills deployments quietly.
Hand off the semantic layer. Build dbt or LookML models that the customer's analysts can extend. Document the joins; document the SLAs on the underlying data.

Identity / SSO / SCIM

Often the slowest part of a deployment to get sorted, because it goes through the customer's IT team rather than the data team.

Okta: most common at mid-to-large enterprises.
Microsoft Entra ID (Azure AD): Microsoft-shop default.
Ping Identity: regulated industries (finance, healthcare).
Auth0: more common at younger companies.

The minimum you'll set up

SAML SSO — customer's IdP authenticates users into the platform UI.
SCIM provisioning — auto-create / auto-disable platform users as employees join / leave.
Service accounts — for machine-to-machine traffic (your pipeline → their warehouse).
Audit logging — who did what when, in a form the customer's security team can review.

Start identity in week one

Don't wait until you're ready to ship a UI. Identity setup involves the customer's IT and security teams, who move on their own schedule. Get the SSO / SCIM tickets filed in week one, even if you don't need them until week six.

The integration playbook

Approach a new integration in this order:

Map the customer's existing stack — name every system, who owns it, how they talk to each other.
Find the read source — where does the data you need live? Pull it before pushing anything.
Define the write target — where does your output need to land for the customer to act? Defer ERP writeback as long as possible.
File auth tickets early — the IT team gates more things than you think.
Stand up the read path first — get data flowing before you build dashboards.
Build downstream consumption — dashboards, alerts, integrations.
Loop in security review — before you ship to broad customer audience. Their objections at the end are deployment-killers.

Interview probes

Show probe 1: "Customer's stack is SAP + Coupa + Snowflake + Looker + Okta. Walk me through your week-one integration plan."

Day 1: map every system, owner, how they talk. Day 2: file Okta SSO + SCIM tickets with IT — they're the long pole. Day 3: design read paths — SAP supplier master via BAPI or OData; Coupa contract refs via REST. Day 4: agree with the customer's data team on Snowflake landing schema and delivery mechanism (direct write, share, or staging bucket). Day 5: scope the Looker semantic layer — what marts will analysts query, what dashboards do business users want. Identity and IT tickets are filed before any code is written; that's the senior signal.

Show probe 2: "Why defer ERP writeback?"

Three reasons. (1) Political — the ERP is the system of record; writing into it touches finance, IT, and procurement teams whose buy-in takes time. (2) Risk — a bad write into ERP can affect financial close, payables, audits. (3) Sequencing — most of the deployment's value lands in the warehouse and BI without touching ERP. Build that value first, then earn the right to write back. Doing writeback in week two erodes trust if the customer hasn't internally agreed.

Show probe 3: "What's the difference between Okta SAML and SCIM?"

SAML is the authentication protocol — when a user clicks "log in," the platform redirects to Okta, Okta verifies, and returns a signed assertion. SCIM is the provisioning protocol — when an employee joins the company, Okta automatically creates a user in the platform; when they leave, Okta disables them. SAML handles the runtime; SCIM handles the lifecycle. Most enterprise deployments need both.

Show probe 4: "Customer's BI is Tableau but you'd recommend Looker for the semantic layer. What do you do?"

Use Tableau. Imposing Looker means asking the customer to license and learn a new tool, which adds operational burden and earns no trust. The semantic layer can live in dbt models inside the warehouse rather than in Looker — Tableau queries them just fine. Push back only if the customer specifically asks "should we add Looker?", and even then, weigh in based on their existing analyst skill set, not your preference.

Show probe 5: "What goes wrong with SAP integrations?"

Five common issues. (1) Custom Z-tables that aren't documented anywhere — the customer's SAP team will need to explain them. (2) Heavy customization makes "standard" BAPIs unusable. (3) Customer's SAP team is overwhelmed and slow to respond. (4) Production access requires change advisory board approval, which adds weeks. (5) Data quality in SAP is sometimes worse than the customer admits — supplier master deduplication, currency normalization, posting-date vs document-date confusion. Plan for the people problems as much as the technical ones.

✓ Check yourself

Answer from memory before opening each one.

One customer runs SAP ECC and is mid-migration to S/4HANA. Another is settled on S/4HANA. How does that change the integration plan?

Show answer
Read paths built on older interfaces may be replaced during migration, so you ask about the roadmap, keep the integration thin and isolate it behind your own interface. The settled customer lets you invest in the modern interface directly. See the enterprise data stack you'll meet.
Why does the playbook read from the ERP before writing to it, and what do you expect to find on the read side?

Show answer
Reading proves you understand their data and carries little risk, while a write touches the financial system of record. Expect custom tables, heavy customization and a busy ERP team that answers slowly. See ERP systems.
Week six: the interface is ready and no user can log in. What should have been filed in week one, and which pieces?

Show answer
Single sign-on and user provisioning tickets, plus service accounts and audit logging. They go through the customer's IT and security team on their own schedule, so the queue was the long pole. See identity, SSO and SCIM.
An employee has left the customer, and their account on the platform is still active. Which mechanism is missing, and what does the other one do?

Show answer
Provisioning is missing: SCIM creates and disables accounts as people join and leave. SAML only authenticates a user who still exists in the identity provider's view. See identity, SSO and SCIM.
The customer's BI tool is Tableau, but you like Looker's semantic layer. Where does the layer live?

Show answer
In dbt models in the warehouse, which Tableau queries without issue. Introducing a tool the customer lacks adds cost and resentment from their BI team. See BI tools.
Why stand up the read path before dashboards, and why involve security review before wide release?

Show answer
Dashboards on data that does not flow yet produce rework, and the read path exposes surprises early. Security objections raised at the end can kill a deployment that was otherwise ready, so involve the reviewers before the audience widens. See the integration playbook.

Takeaway

A deployment touches four to six systems across sources, contract management, procurement, ERP, warehouse, BI and identity; know which are entrenched and which are migrating.
Read supplier master, purchase orders and ledger postings from the ERP first, and write only when trusted and through their change process.
The procurement suite is often where the customer wants insight to land.
Match the customer's warehouse and BI tool, and keep the semantic layer in dbt.
Identity runs through IT on its own schedule: SAML for login, SCIM for lifecycle, service accounts for machines, and audit logs. File the tickets in week one.
Work the playbook in order: map the stack, find the read source, define the write target, file auth tickets, build the read path, then consumption, then security review.

Next is how you run and change what you have deployed at the customer. → Ops & Rollout