Valiopt
← Back to Blog

How to Connect Zendesk and Epicor for Customer, Order, and Service Workflows

A Zendesk–Epicor integration can give support one place to identify a customer, explain an order, check inventory, follow a shipment, clarify an invoice, track a return, and coordinate after-sales service.

Those workflows span much more than warranty and repair. Epicor Kinetic organizes core operations across CRM, sales and order management, supply chain, financial management, and service management. A useful Zendesk integration should reflect that broader operating model and prioritize the questions that create the most everyday contact with support.

Valiopt helps businesses configure and operate these integrations through a managed approach tailored to their Epicor setup, Zendesk workflows, permissions, policies, and highest-volume contact reasons. That can include read-only agent context, approval steps, controlled ERP actions, event-driven ticket updates, monitoring, and ongoing adjustments as the underlying operation changes.

The Epicor workflows that matter most in customer support

Epicor's Order Management documentation centers the process from order entry through shipment, including releases, allocations, promise dates, multiple ship-to addresses, multiple plants and warehouses, drop ships, and backorders. Its Supply Chain Management suite adds inventory, warehouse operations, shipping and receiving, container tracking, and automatic invoicing after shipment. These capabilities create the bulk of the ERP context needed for common “where is it?” and “what happens next?” conversations.

CRM provides customer, contact, interaction, and case context. Financial Management covers accounts receivable, payment processing, credit-card payments, accounting transactions, and billing. Service & Asset Management covers RMAs, contracts, warranties, cases, field service, and repairs. Together, these areas support seven practical integration categories:

WorkflowTypical questionsEpicor contextZendesk outcome
Customer and accountWho is this customer? Which account, contact, and ship-to apply?Customer, contact, ship-to, terms, account statusVerified identity and account context
Product and quoteIs this item available? What can we promise or substitute?Part, revision, availability, lead time, quote, price contextAccurate availability or a sales handoff
OrderWas the order accepted? Can an address, date, or quantity change?Order, lines, releases, holds, allocations, change stateOrder summary and an approved change path
Fulfillment and deliveryWhat shipped, what remains open, and where is the delivery?Pick, pack, shipment, tracking, backorder, proof of deliveryLine-level shipment status and next commitment
Invoice and paymentWhich invoice applies? Was payment received? Why is there a balance?Invoice, credit memo, payment, terms, open balanceBilling explanation or finance handoff
Return and RMAIs the return authorized? Has it been received or credited?RMA, receipt, inspection, disposition, replacement, creditReturn status and the next required step
Service and warrantyIs the product covered? What repair, visit, or part is required?Asset, serial, contract, warranty, service case, repair, partsEntitlement and service progress

See Epicor's official overviews for Order Management, Supply Chain Management, CRM, Financial Management, and Service & Asset Management.

How the systems should divide responsibility

Zendesk should remain the workspace for the customer conversation and support ownership. Epicor should remain authoritative for customer accounts, orders, inventory, fulfillment, invoices, RMAs, and service records. A workflow layer resolves identity, applies authorization and policy, calls both platforms, and records each cross-system operation.

ZendeskRequester, ticket, channel, assignment, comments, and public status
Workflow layerIdentity, mapping, policy, authorization, retries, approvals, and audit
EpicorCustomer, commercial, fulfillment, financial, return, and service records

Epicor describes Kinetic's Open REST API as structured access to ERP services, data, and business logic through the same service architecture used by Kinetic. It includes OData v4 queries, Epicor Functions, API keys, scopes, and interactive REST help. Use the Open REST API overview for architectural background, then validate the exact services and methods in your own environment's interactive help.

1. Customer, contact, and account matching

Nearly every workflow begins by finding the correct customer. Epicor CRM manages customer and contact information and records interactions, while Zendesk identifies a requester and organization. Store immutable Epicor customer, contact, and ship-to identifiers on the corresponding Zendesk records after a verified match. Include the Epicor company and site when identifiers can repeat across companies.

A safe matching sequence is:

  1. Use an existing verified Epicor customer or contact ID.
  2. Use a signed-in application account's internal customer ID.
  3. Use an order, invoice, shipment, or serial number with a second attribute.
  4. Show candidate accounts to an agent when several records remain possible.
  5. Require stronger verification before exposing personal, delivery, or financial data.

Keep match confidence separate from the matched ID. Values such asverified, agent_confirmed, candidate, and unmatched let the workflow limit what it displays and which actions it permits. Email and company name are useful search inputs; both require corroboration before an account-level action.

2. Product availability, quotes, and promise dates

Product questions often arrive before or alongside an order: Is the item available? Which revision applies? Can another item substitute? When could it ship? Epicor's sales and supply-chain capabilities connect parts, quotes, inventory, allocations, planning, and capable-to-promise dates. A Zendesk lookup can bring the approved subset of that context into the conversation.

Show the part and revision, applicable customer part number, availability timestamp, warehouse or plant, current lead time, and any allowed substitute. Keep “on hand,” “available,” and “capable to promise” distinct. A quantity in a warehouse does not guarantee that support can allocate it to a new request. Commercial pricing and margin should remain hidden unless the agent's role and workflow require them.

3. Order lookup and approved order changes

Order status is usually the broadest Zendesk–Epicor workflow. Load the order header, lines, releases, requested and promised dates, quantities, fulfillment state, allocations, holds, ship-to details, and related documents. Summarize the affected lines in Zendesk instead of copying a large ERP payload into ticket fields.

Order changes need current-state checks. An address, date, quantity, cancellation, or line change that was safe at ticket creation may become unsafe after allocation, picking, production, shipment, or invoicing. Expose narrow operations such as check_order_change andapply_approved_address_change. Re-read Epicor immediately before the write, apply company policy, and return the updated order or a precise reason that the change now needs review.

Epicor Order Management supports multiple releases, ship-to addresses, plants, warehouses, drop shipments, buy-to-order lines, and automatic backorders. The Zendesk view should preserve these distinctions. A single header-level “open” or “shipped” label can conceal the line the customer actually cares about.

4. Fulfillment, shipment, and delivery

Fulfillment questions need line-level detail: quantity allocated, backordered, picked, packed, and shipped; shipment date; carrier and tracking reference; ship-from site; destination; and the next open commitment. Epicor's supply-chain documentation covers automated fulfillment, warehouse operations, shipping and receiving, container tracking, and proof-of-delivery options.

Map operational states to a small support vocabulary without discarding the underlying evidence. “Partially shipped” should identify which lines moved and what remains open. “Delivered” should carry the shipment and delivery evidence available to the agent. Recordepicor_checked_at so nobody mistakes an earlier snapshot for live ERP state.

Event-driven updates are especially valuable here. A posted shipment, backorder, changed promise date, or confirmed delivery can update the ticket and prompt an approved message before the customer contacts support again.

5. Invoice, payment, and account-balance questions

B2B support teams frequently receive questions about invoice numbers, shipment charges, tax, credits, payment receipt, payment terms, and open balances. Epicor Financial Management covers accounts receivable, payments, billing, and accounting transactions, while Supply Chain Management can create invoices following customer shipments.

Give support the minimum financial context required to explain the issue: invoice number and date, related order and shipment, document status, total, open balance, payment or credit status, currency, and terms. Mask payment instruments and restrict sensitive account information by role. Disputes, write-offs, credit decisions, and ledger adjustments should follow an explicit finance handoff or approval path.

Link the Zendesk ticket to the Epicor invoice or credit reference so the customer does not have to repeat it at every handoff. When finance acts, a status event can update the ticket with an internal note or an approved public explanation.

6. Returns and RMA status

An RMA workflow should confirm the customer, order line, quantity, return reason, item condition, serial or lot number when applicable, return location, and desired outcome. It should detect an existing RMA, credit, or replacement before creating another obligation.

Epicor describes unique RMA numbers and tracking across return and disposition processes. After authorization, write the RMA number to a dedicated Zendesk field and explain the next step. Later updates can reflect receipt, inspection, disposition, replacement, or credit status. Customer-facing language should translate Epicor's internal state while retaining the authoritative RMA reference.

7. Service, warranty, repair, and replacement parts

After-sales service is one important category within the wider integration. Epicor Service & Asset Management covers customer assets, cases, contracts, warranties, field service, repairs, RMAs, and maintenance. A support workflow can load an asset or serial number, coverage dates, contract, prior cases, available remedy, parts context, and current service status.

Return entitlement as a structured result: eligible, ineligible, missing evidence, or requires review. Include the contract or warranty reference, coverage period, allowed remedy, and reason. If service is needed, a controlled operation can create the correct Epicor case, service call, repair, or parts request and return its document number to Zendesk.

Classification software can extract a serial number or categorize the reported symptom. Deterministic policy and authorized Epicor data should decide coverage, approve parts, and create ERP records.

Keep Zendesk current when Epicor changes

Epicor-driven events should update Zendesk when a change matters to the customer or the ticket owner: an order hold, revised promise date, shipment, delivery, invoice, payment, RMA receipt, credit, appointment, parts delay, or service completion. Epicor Automation Studio, powered by Workato, is one low-code integration path. A custom service can use the Open REST API and Epicor Functions when the workflow needs tighter control. Epicor's integration overview describes both packaged integration and API-based customization.

The consumer should locate the Zendesk ticket through a stored ticket ID or correlation record, update structured fields, and add either an internal note or a public comment according to a defined communication rule. A scheduled reconciliation job should compare important open records and repair any events that were missed.

Zendesk tickets support custom fields and an external_id for linking a ticket to another record. The update API also supportssafe_update with an updated_stamp to detect collisions when an agent and an integration update the same ticket. See Zendesk's Tickets API reference.

Choose an integration pattern for each direction

Zendesk → Epicor

Use a Zendesk sidebar app or middleware endpoint for request-time lookups. Use a Zendesk webhook when ticket changes should start asynchronous work. Send writes through named, policy-aware operations.

Epicor → Zendesk

Publish approved business events through Automation Studio, an Epicor Function, or a custom integration service. Add reconciliation polling for records whose current state must eventually reach Zendesk.

Zendesk webhooks send HTTP requests in response to configured activity and include signatures that receivers can verify. Zendesk's webhook documentation covers event subscriptions, retry behavior, monitoring, authentication, and verification. Persist a verified event, acknowledge it promptly, and process longer ERP work asynchronously.

Define record ownership and write direction

Record or fieldOwnerIntegration rule
Customer, contact, and ship-to masterEpicorZendesk stores stable Epicor keys and support-facing context
Order, allocation, shipment, inventory, invoiceEpicorRead current state when answering or authorizing an action
Conversation, requester, channel, assignmentZendeskPass ticket references to Epicor only when an operational record needs them
RMA, service case, warranty, repairEpicorZendesk displays a mapped status and the authoritative Epicor reference
Integration correlation IDWorkflow layerWrite it to both systems for tracing and idempotency
Customer-facing updateZendeskGenerate from approved ERP states and record when the data was refreshed

Assign a source of truth and a write direction to every synchronized value. If Epicor owns shipment state and Zendesk owns the public summary, the workflow can safely derive the latter from the former. Two systems writing the same status without a conflict rule creates update loops and makes stale data difficult to diagnose.

Authentication, authorization, and data exposure

Use a dedicated identity for each integration direction. Zendesk supports OAuth access tokens and API tokens; OAuth provides scoped access and is well suited to an app authorized by multiple Zendesk accounts. Zendesk's guide to OAuth and API tokens explains the operational differences. Epicor should have its own integration identity and the minimum company, site, service, and method permissions required for each workflow.

  • Keep credentials in a secrets manager and rotate them without code changes.
  • Separate read-only access from order, inventory, return, financial, and service writes.
  • Filter Epicor responses before they reach Zendesk; exclude cost, margin, internal notes, and unrelated customer data.
  • Check authorization again immediately before every consequential write.
  • Record the initiator, policy version, request fields, Epicor reference, and outcome.
  • Redact credentials, payment data, and unnecessary personal information from logs and failed-event records.

Make writes idempotent and recoverable

A timeout can occur after Epicor accepts an order change, RMA, or service request. Generate an operation ID before the first write and persist it with the Zendesk ticket ID, requested action, payload hash, state, and Epicor document number. Reuse it on retries and check for an existing result before creating another record.

Deduplicate inbound events by source event or business-transition ID, preserve the Epicor timestamp, reject updates older than the current state, and keep a review path for failed records. Reconciliation should compare current Epicor state with the last state successfully reflected in Zendesk.

Roll out from visibility to controlled action

StageScopeMeasure
1. Read-only contextCustomer, product, order, shipment, invoice, RMA, and service lookupMatch rate, lookup latency, agent time saved, and data accuracy
2. Assisted actionsPrepare order changes, returns, billing handoffs, and service requestsApproval rate, correction rate, time to action, and exception causes
3. Controlled automationExecute approved low-risk changes and send event-driven updatesResolution time, repeat contacts, action failures, and duplicate prevention

Read-only workflows reveal identity gaps, Epicor customizations, latency, and data-quality problems with limited operational risk. Assisted actions then test policy and payload quality. Automated writes should begin with a narrow case that has clear eligibility, low exposure, and a practical correction path.

Implementation checklist

  • Inventory the Epicor product, version, companies, sites, modules, custom fields, Functions, and REST services.
  • Measure your support contact reasons and choose the first workflow from real ticket volume.
  • Define the inputs, output, latency target, permissions, and failure behavior for that workflow.
  • Create and verify stable Zendesk-to-Epicor customer, contact, and account keys.
  • Assign an owner and write direction to every synchronized field.
  • Design separate operations for lookup, eligibility, preparation, approval, execution, and status retrieval.
  • Map Epicor states to concise agent-facing and customer-facing states.
  • Add least-privilege authentication, webhook verification, redaction, and credential rotation.
  • Implement idempotency, collision handling, retries, failed-event review, and reconciliation.
  • Test partial shipments, multiple companies, shared emails, order holds, duplicate RMAs, payment restrictions, and timeouts after writes.
  • Monitor match rate, lookup latency, API failures, queue age, duplicate prevention, agent corrections, and repeat contacts.

Configure the integration around your Epicor operation

Epicor implementations accumulate company-specific business rules, custom fields, Functions, security groups, and approval processes. Your highest-value Zendesk workflows will also depend on your own contact mix. A manufacturer with complex configured orders may begin with order lines, releases, and promise dates. A distributor may begin with availability, backorders, shipments, and invoices. A service-led business may give more weight to assets, contracts, and field service.

Valiopt configures these workflows around the systems and policies already in place. The result gives support a small set of dependable ERP tools, preserves record ownership, and carries enough context across Zendesk and Epicor to resolve more requests without internal handoffs.

Turn Zendesk and Epicor into one support workflow

Valiopt configures the customer, order, fulfillment, billing, returns, and service workflows that connect your Zendesk operation to Epicor. Give agents and AI workflows useful ERP context while keeping permissions, ownership, and auditability clear.