NetSuite Integration and Custom Development

What companies connect to NetSuite

NetSuite tends to become the financial center of a growing company, which means every other system eventually needs to talk to it. The integrations Tepia is asked for most often follow a few patterns:

• Ecommerce orders: Shopify, BigCommerce or Amazon orders become NetSuite sales orders, with item fulfillments and tracking flowing back to the store.
• CRM handoff: a closed won opportunity in Salesforce or HubSpot creates or updates the NetSuite customer and sales order, and open balances flow back so reps see credit status.
• Warehouse and 3PL: fulfillment requests go out, ship confirmations, lot numbers and serial numbers come back.
• Payments and payouts: Stripe or bank activity posts as customer payments and deposits for reconciliation.
• Payroll and expenses: summarized journal entries by department and subsidiary.

The details are where NetSuite projects succeed or stall. OneWorld accounts add subsidiaries and intercompany rules. Multi currency changes how amounts post. Matrix items, kits and assemblies change what an order line means. Tepia inventories these features in Discovery, because a connector that ignores them works in a demo and fails on the first real order.

Choosing the right NetSuite interface

NetSuite offers several ways in, and choosing well affects speed, reliability and how easy the integration is to maintain. Tepia selects per flow:

Authentication is set up with token based authentication or OAuth 2.0 against a dedicated integration role with only the permissions the flow needs. Tepia never runs an integration under a person’s login, so it keeps working when that person leaves.

Custom development inside NetSuite

Some needs are better solved inside NetSuite than beside it. Tepia writes SuiteScript 2.x for the cases where native configuration runs out:

• User event scripts that validate a sales order before save, for example blocking an order that exceeds a customer’s credit terms unless a manager has approved it.
• Map/reduce scripts that process thousands of records, such as nightly recalculation of commitment dates on open orders or bulk updates to item records, without hitting governance limits.
• Suitelets that give staff a purpose built screen inside NetSuite, such as a pick exception console for the warehouse.
• Custom records and fields for data NetSuite does not model, such as equipment serviced under a contract.
• SuiteFlow workflows for approvals that stay entirely inside NetSuite. When approvals span NetSuite and other systems, our workflow and approval apps are usually a better fit.

Tepia keeps scripts in source control and deploys them through the SuiteCloud Development Framework, so every change is reviewed, versioned and repeatable between sandbox and production.

Building apps and portals on NetSuite data

NetSuite’s own interface is built for back office users at a desk. Field sales reps checking availability in a customer’s parking lot, technicians recording parts used, or trade customers reordering at night need something faster. Tepia builds those front ends in React Native or React and connects them to NetSuite through a thin service layer rather than calling NetSuite directly from every phone.

That layer caches items, availability and customer terms, queues writes so they respect NetSuite’s concurrency limits, and keeps NetSuite credentials off devices entirely. A rep’s order is accepted immediately, then created in NetSuite within seconds, and any rejection comes back to the rep with a plain explanation. Offline support matters here too: a rep in a basement stockroom can still build an order from cached items and customer terms, and it submits when signal returns.

Customer facing portals follow the same pattern. Trade customers see their own order history, open balances and shipment tracking pulled from NetSuite, reorder from past orders, and download documents, while Tepia limits each customer to its own records at the service layer. That keeps the portal fast during busy periods because most pages are served from the cache rather than from live NetSuite queries. For related builds, see our field sales rep app and B2B ecommerce portal pages.

How Tepia approaches NetSuite integration

Tepia applies its six phase process to NetSuite work, led by a US based project manager.

1. Discovery: a review of your NetSuite configuration, including subsidiaries, custom fields, existing scripts and current integrations, plus interviews with the controller and operations leads. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a warehouse lead releasing a held order.
2. Design: field mappings, the choice of interface for each flow, governance and concurrency estimates at peak volume, and wireframes for any Suitelet or app screens.
3. Development and Testing: builds in a sandbox refreshed from production, an Alpha with replayed historical transactions, and a Beta where results are reconciled against NetSuite saved searches.
4. Training: hands on sessions for admins on monitoring script logs and for staff on any new screens.
5. Launch: deployment through SuiteCloud tools, backfill of in flight orders and a monitored first close.
6. Support: fixes after NetSuite’s twice yearly releases, bug tracking and new flows as you add channels.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month. If you are still deciding on the platform itself, read NetSuite vs custom ERP, or contact Tepia about your account.

Frequently asked questions