NetSuite Integration Register: Owners, Credentials, Controls

Executive Summary

A NetSuite integration register is the operational record that lets an organization identify, run, secure, transfer and retire every integration without depending on one person's memory. NetSuite's native tools do not supply that record on their own. Oracle's integration record "represents any app that sends web services requests or calls RESTlets" ^[1], but "some integration record capabilities are limited for RESTlet activity" ^[1]. The RESTlet execution log "only shows data from those using token-based auth" ^[2], and user credential (NLAuth) calls "aren't logged on any integration record" ^[3]. Comma separated value (CSV) imports, scheduled scripts and file drops sit outside integration records, so a register must be assembled from several NetSuite lists plus the owners' own knowledge.

Three lifecycle facts raise the stakes as of October 2026. Oracle states that SOAP (Simple Object Access Protocol) web services will be removed with the 2028.2 release ^[4], and that new SOAP integrations ^[4] and new token-based authentication (TBA) integrations ^[5] stop being possible from 2027.1. Existing TBA integrations are tentatively supported until 2028.2 ^[5]. A register that records channel and authentication method per integration turns those dates into a work list.

Credential and evidence facts drive most fields. TBA tokens "do not expire" ^[6], and Oracle calls revocation after some time "a good practice" ^[6], so credential age must be tracked by the organization. Resetting consumer credentials "invalidates the old ones" ^[7], and a sandbox refresh deletes sandbox token keys and secrets ^[8]. Native activity logs are short: the SOAP execution log keeps 21 days in production ^[9] and script logs 30 days, or 60 days for system error logs ^[10], while system notes are not purged on a schedule ^[11].

The recommended design is one row per integration, an accountable business owner and technical owner for each, credential metadata kept apart from secrets, a quarterly orphan test (an active integration with no reachable owner), and a decommission sequence with sign-off. The National Institute of Standards and Technology (NIST) SP 800-53 catalog supplies control language for inventories with owners ^[12] and for least privilege ^[12]. This report is documentation-based: product behavior, permissions and log coverage must be retested in a current account, and Table 2 includes fields to record that test.

Introduction and Background

An interface list names the connections between systems. A register answers different questions: who is accountable for each integration, why it exists, which records move in which direction, under which identity, on what schedule, with which recovery contact, and when it will be retired. The distinction matters most for mature accounts that have accumulated CSV jobs, scripts, bundles, middleware connections and vendor SuiteApps over many years. This report examines how to build and operate that register in NetSuite, using Oracle's own documentation for platform behavior and independent standards for control design.

The audience is the group that inherits or governs such an account: chief information officers, controllers, platform owners, security teams, internal audit and managed-support leaders, who must decide whether every integration can be identified, operated, secured, transferred and retired without one person's memory.

Scope is deliberate. API method details, OAuth (Open Authorization) setup steps and concurrency limits are covered in Oracle's own pages and in separate operating references, and are not repeated here. Concurrency is governed at account level for web services and RESTlets together ^[13], so it is recorded as a register dependency rather than explained.

Oracle's overview lists four integration channels: CSV import, REST (Representational State Transfer) web services, RESTlets and SOAP web services, and says that "SuiteTalk REST web services with OAuth 2.0 authentication is the preferred technology for new integrations" ^[14]. Independent guidance points the same way on the need for an inventory. The OWASP (Open Worldwide Application Security Project) API Security Top 10 observes that a "lack of assets inventory and retirement strategies leads to running unpatched systems" ^[15], and CISA (the US Cybersecurity and Infrastructure Security Agency) calls asset visibility "a basic pre-condition" for managing cybersecurity risk ^[16]; that directive binds US federal agencies, so it is cited as rationale only.

Disclosure: this article is published by Houseblend, a Montréal NetSuite consultancy that is one possible provider of the stewardship described here; the same register can be built and run in house. Where professional opinion is needed, for example on records retention obligations, readers should consult internal audit, legal counsel or compliance.

Key Changes Affecting the Register

Four documented platform changes determine which fields a register must carry in 2026 and 2027. Dates below are Oracle's announced timeline as of October 2026 and may change; recheck them against current release notes before planning. Oracle also states that from the 2026.1 release all newly built integrations should use REST web services with OAuth 2.0, and that from 2027.2 only the last SOAP endpoint is supported, with older endpoints available but unsupported until SOAP removal in 2028.2 ^[4].

SOAP web services are being retired

Oracle's SOAP removal FAQ states that "The 2025.2 SOAP endpoint is the last planned SOAP endpoint" ^[4], that "only the last endpoint will be supported and have any potential bugs fixed" ^[4], and that support continues "until the final removal of SOAP web services with the 2028.2 NetSuite release" ^[4]. At that point endpoints "will be disabled, and SOAP-based integrations will stop working" ^[4]. A register therefore needs a channel field and, for SOAP, the endpoint (WSDL, Web Services Description Language) version in use. Oracle's Application Performance Management (APM) dashboard can surface integrations that "still use unsupported WSDL versions" ^[17], which gives the register a native cross-check.

New TBA integrations end in 2027.1

Oracle's TBA end-of-support page states that "you will no longer be able to create new integrations that use TBA" ^[5]. Support for existing integrations ends later, "tentatively NetSuite 2028.2" ^[5]. Oracle also notes that "third-party and app connectors that still rely on TBA may require an updated configuration" ^[5]. The register should hold authentication method as a first-class field so TBA integrations can be sorted by criticality and migration date.

RESTlets lose user credential support in 2027.1

For RESTlets, Oracle states that "support for user credentials for RESTlets ends in NetSuite 2027.1" ^[18] and that "support for TBA for RESTlets ends in NetSuite 2028.2" ^[18]. A RESTlet caller using user credentials is both the least visible in native logs ("aren't logged on any integration record" ^[3]) and the first to reach end of support, so discovery relies on script deployment records and the callers' owners.

OAuth 2.0 is the direction for new integrations

Oracle's FAQ states that "only new integrations must use OAuth 2.0, starting with the 2027.1 NetSuite release" ^[4], so existing REST integrations on TBA are not forced to migrate immediately. OAuth 2.0 is not available everywhere: "OAuth 2.0 cannot be used with SOAP web services" ^[19]. The register records which flow each integration uses, because credential artifacts differ.

What NetSuite Natively Inventories, and What It Does Not

The register cannot be generated from one report. Oracle's documentation describes several inventories, each covering a different slice, and some channels have no integration record at all. Table 1 below summarizes the channel coverage found in Oracle's documentation as of October 2026.

The native inventories are partial and mostly short lived. The register is the durable layer: its fields are refreshed from the native lists on a schedule and extended with facts no native list holds, such as business purpose, owner and recovery contact. RESTlet callers using user credentials, and any file drop, depend on human knowledge, which is the memory risk the register is meant to remove. Coverage claims in this table come from Oracle documentation and have not been retested; the test record in Table 2 is meant to close that gap.

Discovery sources, in order of reliability

• Manage Integrations list: the starting point for SOAP, REST and token-based RESTlet callers. Oracle notes that "each application can be represented by its own integration record" ^[2], so one row per application is a reasonable register unit.
• Script deployments and the Scripted Record page: the latter lists records that have scripts "associated with a record" ^[27]; deployment records cover RESTlets, Suitelets and scheduled scripts.
• Saved CSV Imports and job status: anyone with Job Status page access "can see all import jobs" ^[23].
• Installed Bundles: the list shows who installed each bundle ^[26], and SuiteScript can query installed bundle information programmatically ^[26]. Middleware vendors document in-account dependencies, such as a SuiteApp Boomi installs by bundle ID ^[28] and one Zapier states "must be installed from the SuiteApp Marketplace" ^[29].
• Middleware consoles: connections are created outside NetSuite. Celigo documents a mode in which its platform generates the role and tokens ^[30], and Make notes that "only admin can obtain the Consumer Key and Secret values and assign roles" ^[31], so the middleware owner and the NetSuite owner are often different people.
• Auto-installed records: Oracle notes that "any user with account access can trigger auto-installation, not only account administrators" ^[32], and that the Require Approval preference governs whether an installed record is enabled automatically ^[32]. The list therefore needs periodic review.

Register Design: Fields, Owners and the Orphan Test

Why one row per integration, and what a row contains

The register unit is one integration: a business purpose served through one channel under one identity. One vendor relationship can produce several rows (for example a nightly CSV import and a REST connection) because they fail, rotate and retire independently. Table 2 below gives the recommended template. It combines fields Oracle's pages make available with fields only the organization can supply. NIST's CM-8 discussion lists "software owners, software version numbers, hardware inventory specifications, software license information" among the inventory attributes ^[12], and OWASP advises that teams "inventory all API hosts and document important aspects of each one" ^[15].

Table 2 deliberately excludes secrets. The register holds credential metadata (type, owner, dates), never token values; Oracle states that "credentials are not shown in system notes" ^[33], and the register should not become a second place where they are exposed. The test record group matters because coverage facts in Oracle's pages depend on channel, authentication method and account type; recording account, features, role, channel and date lets a later reader reproduce the observation.

Business and technical owner model

Each integration needs two named humans, not a team alias. The accountable business owner, usually a controller or functional lead, decides whether the integration should exist and signs off its retirement. The accountable technical owner keeps it running, holds the recovery runbook and is the contact when credentials rotate. The RACI (Responsible, Accountable, Consulted, Informed) convention supplies the vocabulary: the University of Illinois toolkit describes Accountable as "takes ownership of the task" ^[38], and Cornell defines Responsible as the role performing "correct execution of the task/deliverable/decision" ^[34]. Table 3 below applies it to register activities.

In Table 3, A marks the single accountable role per row. A partner column is shown because many organizations outsource part of this work, and the accountable role stays with the organization's own owners even when execution is contracted out. The table is a starting template to adapt to the organization's governance model.

The orphan test

An orphan is an active integration, credential or identity with no business owner or no technical owner who is currently employed and reachable. The test is a query, not a judgment: list every row whose lifecycle state is active and whose business or technical owner field is empty, names a departed person, or names an inactive NetSuite user. NIST's account management control lists accounts "no longer associated with a user or individual" as a trigger to disable them ^[12], and OWASP's non-human identity (NHI) guidance warns of identities that "remain active without a new designated owner" ^[39] and recommends that teams "recertify NHIs to confirm they are still in use, actively needed, and have valid owners" ^[39], which is the quarterly attestation described below.

Credentials, Roles and Integration Records

Which artifacts exist, by channel

Credential artifacts differ by channel and must be recorded accordingly. For TBA, MuleSoft's documentation describes the Token ID as one "that represents the unique combination of a user and an integration record" ^[35]. For OAuth 2.0 client credentials, Workato documents that the flow "requires an EC private key and certificate" ^[40], and Oracle caps active certificates at five per combination of integration, entity and role, noting that an expired or revoked certificate means "you must create a new mapping for the integration record" ^[41]. For interactive OAuth 2.0 flows, users "can only list their own OAuth 2.0 authorized applications" ^[42], while a holder of the management permission can "view or revoke any OAuth 2.0 authorized applications in the account" ^[43]. The register's credential fields therefore name the artifact (token, certificate, authorized application), the identity it binds to, and the custodian.

Credential age without invented thresholds

Oracle publishes no rotation interval for TBA tokens. It states that "TBA tokens do not expire" ^[6] and that "it is a good practice to revoke a token after some time" ^[6]. Make's documentation likewise notes that "Make does not refresh the connection with NetSuite" ^[31]. OAuth 2.0 access tokens are short lived ("valid for 60 minutes" ^[44]), so the long-lived artifacts are the client certificate, the consumer secret and any stored token.

Authoritative standards do not prescribe a universal interval either. NIST SP 800-53 leaves the period to the organization: its authenticator control requires that "a time period for changing or refreshing authenticators by authenticator type is defined" ^[12]. NIST SP 800-63B addresses human passwords and says verifiers should not "require subscribers to change passwords periodically" ^[45], on the stated basis that "humans have a limited ability to memorize complex, arbitrary secrets" ^[45]; that rationale does not transfer automatically to machine credentials. OWASP's non-human identity guidance flags secrets with "expiration dates that are too far in the future" ^[46]. The register therefore carries three neutral fields: created date, last rotated date and an organization-defined rotation interval set by policy and risk rating, not copied from this report. Age is the review date minus the last rotated date, and a row with no recorded date is reported as unknown rather than compliant.

What rotation and reset actually do

Resetting an integration record's consumer credentials "invalidates the old ones" ^[7], while "you can still use existing tokens and token secrets" with the new consumer pair ^[7], so every holder of the old pair must be updated in the same change window. Lost token values cannot be recovered ("you will need to create a new token" ^[6]), and Boomi adds that "after leaving the confirmation page, you cannot retrieve these values" ^[28]. Revocation is permanent ("inactive forever" ^[47]), although the token record stays "accessible for auditing purposes" ^[47]. Credentials cannot be reset on bundle-installed records ^[7]. Oracle states that "password rotation policies in your account don't apply to tokens" ^[19], so token rotation is a separate, organization-run process. Its NetSuite Connector guidance warns "don't delete or inactivate the user ID to avoid breaking the connection" ^[48]; Oracle's documentation does not give a general statement on every effect of deactivating a token user, so the register records the token user and the retest result rather than assuming behavior.

Roles and least privilege

NIST AC-6 states the principle ("employ the principle of least privilege, allowing only authorized accesses for users" ^[12]) and its discussion extends it to processes that "operate at privilege levels no higher than necessary to accomplish organizational missions or business functions" ^[12]. For NetSuite, the register records the integration role per row. Oracle distinguishes token permissions: a user with Access Token Management "can create, assign, and manage a token for other users" ^[49], and the User Access Tokens permission "does not also need the Log in using Access Tokens permission" ^[49]. Channel constraints apply too: "roles with the Web Services Only restriction will not work with RESTlets" ^[50].

Scheduled scripts carry a different identity. For scheduled script deployments the execute-as role "is always set to Administrator and can't be changed" ^[51], while other script types can run as "Current User, which runs the script with the logged-in user's permissions" ^[52]. A row for a scheduled script therefore records script owner and the privilege the script runs with, even though no integration user exists. OWASP warns of "lack of auditing and accountability due to indistinguishable activity between humans and automation" ^[53], which supports dedicated integration users, and Workato similarly states "we recommend creating a separate user for your integrations" ^[54].

Audit evidence for credential changes

A credential reset "is logged in the system notes as a Token-Based Authentication Credentials field update" ^[33]. Limits apply: system notes "are only created in the account where changes are made" ^[33], so evidence for a shared record must be collected from each account. The Login Audit Trail can be used "to track TBA tokens and users" ^[55], but Oracle's documentation states no retention period for it, so the register records where exported evidence is stored rather than assuming native retention.

Sandbox, Schedules, Dependencies and Monitoring

Sandbox and production differences

A register that lists production only will be wrong after the first refresh. Oracle's integration record guidance explains the shared ownership model: a record created in sandbox and installed in production means "you won't own it in production" ^[56], and in the receiving account "you can only edit the State and the Note fields" ^[56]. Consumer credentials can be regenerated only in the originating account ^[56], and Oracle warns that "regenerating Consumer Key or Consumer Secret in sandbox can break production integrations if shared" ^[8]. The register's environment fields therefore record where each integration record originated and whether it is shared.

Refresh effects are documented in several places. Production integration records "are copied to sandbox with their settings" ^[56], and a record that existed only in sandbox "is removed during the refresh" ^[56]. TBA credentials do not survive: "after a sandbox refresh, Token Key and Token Secret are deleted and must be regenerated" ^[8], and OAuth 2.0 users "must authorize applications explicitly in the sandbox" after each refresh ^[57]. For client credentials, "each time a sandbox account is refreshed, the setup gets cleared" ^[41]. Scheduled scripts are treated conservatively: "scripts scheduled in production are disabled by default in sandbox accounts" ^[58], while scheduled map/reduce scripts "are copied to sandbox accounts, but are not scheduled by default" ^[58].

Middleware vendors document the same pressure: Make notes that NetSuite "will regularly rollback sandbox environments to their original state" ^[31], and Boomi advises that teams with several accounts or sandboxes "use a separate connection for each" ^[28]. Each environment has its own endpoint, since each account "has a unique account-specific domain" ^[36].

A post-refresh checklist for each integration row follows from these facts:

• Review records: block integration records that are unused or unwanted in sandbox, since copied records arrive with their settings.
• Reissue credentials: regenerate TBA tokens, repeat OAuth 2.0 authorizations and recreate client credential mappings, recording new created dates.
• Re-enable schedules deliberately: scheduled scripts arrive disabled and map/reduce deployments unscheduled; enable only what the test plan needs.
• Check the shared-record rule: do not regenerate consumer credentials in sandbox for a record shared with production.
• Update the register: record the refresh date, the person and the result.

Schedules and dependencies

The register's schedule fields capture when an integration runs and what it depends on. Native scheduling facts are scattered. Scheduled Script Status page details are deleted "after 30 days" ^[24], and Map/Reduce status details are likewise deleted after 30 days ^[59]. CSV imports share queues, and "accounts that have purchased a SuiteCloud Plus license, have five queues for import jobs" ^[60], so a register that records the queue and the order of dependent imports prevents silent overlaps.

Hidden dependencies deserve their own rows. Celigo documents that "as this bundle is a managed bundle, we will push the bundle in your account" ^[61], so the version running can change without an internal change ticket; record the bundle, its installer ^[26] and the vendor contact. Oracle states that Suitelets available without login "should not be used in integration use cases" ^[25], so any found during discovery is a review item.

Monitoring and reconciliation links

Each row should name where success and failure are observed, and which control totals prove completeness. Oracle's APM SuiteApp can "monitor performance of user event scripts, workflows, RESTlets, scheduled scripts, and Suitelets" ^[62], and its dashboard "highlights anomalies across record pages, scripts, saved searches, integrations, and processors" ^[62]. It raises alerts on "high error rates for integrations" ^[17]. APM data covers a limited window, since the tools "show data from the last 30 days" ^[37]. Script logs are purged after 30 days (user-generated) or 60 days (system error) ^[10], so monitoring evidence needed for a quarter-end or audit review must be exported to the organization's own store. Reconciliation (record counts and amount totals compared between source and NetSuite) is documented in the row as a control total linked to the owning team's procedure.

Implementation Considerations and Process Changes

Standing up the register

Implementation follows the discovery sources in order: export the Manage Integrations list and script deployments as draft rows; add Saved CSV Imports, Installed Bundles and middleware connections; interview process owners for integrations no native list shows, such as file drops and RESTlet callers using user credentials; assign two owners per row and run the first orphan test; and fill the credential fields with metadata only. Unknowns left by the first pass are themselves findings.

Several process changes follow. New integrations require a register row before an integration record or role is created; credential resets go through a change ticket that updates the row; sandbox refreshes trigger the checklist above; and leaver processes query for rows whose owner or token user is the departing person, aligning with NIST's account lifecycle of "create, enable, modify, disable, and remove accounts" ^[12] and its recognition that account types include "service" accounts ^[12].

Quarterly review

The review has five steps and a recorded attestation by each business owner for their rows:

1. Refresh from native lists: compare the register to the current Manage Integrations list, script deployments, Saved CSV Imports and Installed Bundles.
2. Run the orphan test: list active rows with a missing, departed or inactive owner and assign or retire each one.
3. Compute credential age: report rows by days since last rotation against the organization's own interval, with unknown dates reported separately.
4. Check lifecycle dates: list SOAP rows, TBA rows and RESTlet user credential rows against the announced Oracle timeline, flagging any without a migration plan or sunset date.
5. Review privilege and activity: compare each integration role to its documented need, check that tokens still map to active users, and review system notes and audit trails, which Oracle recommends doing "regularly" ^[63].

Decommissioning an integration

Decommissioning is a sequence, not an event. A suggested checklist, to be adapted to the organization's change process:

1. Confirm intent: the business owner approves retirement and the technical owner confirms dependents (downstream reports, bundles, scripts, other integrations).
2. Freeze: set the lifecycle state to frozen, announce a date, and stop schedules. For a SOAP caller, Oracle documents that an integration record can be used to "block SOAP web services requests" ^[2], which gives a reversible step before deletion.
3. Observe: monitor for unexpected callers during the agreed window, using available logs while they last (21 days for the SOAP execution log in production ^[9]).
4. Revoke credentials: revoke tokens, authorized applications and certificates; Oracle states revocation of a token is permanent, and revoking an OAuth 2.0 authorized application "invalidates all tokens associated with that application" ^[42].
5. Remove artifacts: disable or delete script deployments, saved imports, roles, integration users, the middleware connection and any bundle that served only this integration.
6. Handle data and secrets: dispose of exported files and stored secrets according to policy; NIST's media sanitization control requires sanitization "prior to disposal, release out of organizational control, or release for reuse" ^[12].
7. Check sandbox echoes: production records are copied to sandbox ^[56], and a refresh is one way sandbox-only records are removed ^[56].
8. Record evidence and sign-off: store the change ticket, system notes export, revocation confirmations and owner sign-offs, then set the row to retired and keep it.

A retired row is retained, not deleted. System notes for existing records are "never automatically deleted" ^[11], and revoked tokens remain "accessible for auditing purposes" ^[47], so the native trail persists even though logs do not. The retention period for the register's own evidence is set by policy and applicable law; NIST AU-11 frames retention as supporting "after-the-fact investigations of incidents" ^[12]. The reader should confirm required periods with legal counsel or internal audit rather than inferring them from this report.

Data Analysis and Evidence

The evidence in this report is documentary: platform facts that bound what a register can rely on. This report makes no prevalence claim because it draws only on vendor and standards documentation.

Retention windows (Oracle documentation, as of October 2026).

• SOAP execution log: 21 days in production ^[9] and seven days in sandbox ^[9]; the SOAP usage log can purge "earlier than 21 days" under heavy activity ^[64].
• Script logs: 30 days for user-generated logs and 60 days for system error logs ^[10], capped at 5 million logs per database instance ^[10]. Oracle's same page also states that all script execution logs are stored for up to 30 days, so treat 30 days as the planning figure, confirm actual retention in a current account, and note that the volume cap can purge logs sooner.
• CSV import status: 30 days, up to 1,000,000 jobs ^[23].
• APM: data from the last 30 days ^[37].
• System notes: no scheduled purge for existing records ^[11].

Credential lifetimes. TBA tokens do not expire ^[6]; OAuth 2.0 access tokens are valid for 60 minutes ^[44]; the refresh token validity setting for the code grant flow defaults to 48 hours ^[65]; client credential certificates are capped at five active per combination ^[41]. TBA is therefore the group where manually tracked credential age matters most.

Coverage and dates. Of the seven rows in Table 1, one (SFTP file drops) has no native inventory documented by Oracle and one (RESTlets) has a documented log limitation; this counts documentation findings, not a share of any account's integrations. The platform dates above convert into a count of affected rows once channel and authentication method are recorded. Two limits apply: Oracle's REST log page states no retention period, and the Oracle pages cited here show no revision date, so the as-of date for this article is 27 October 2026.

Implications and Future Directions

The immediate implication is a time-boxed migration inventory: a register with channel and authentication fields turns the announced 2027.1 and 2028.2 dates into counts and owners. Existing TBA integrations can continue under Oracle's stated timeline, so ordering is a business decision driven by criticality and vendor readiness, and Oracle's note that connectors relying on TBA may need updated configuration ^[5] argues for including middleware vendors in the review.

The second is shared responsibility: Celigo states that inadequate role permissions "could lead to unwanted errors when executing the data flows" ^[66], and Zapier describes a method in which "users only need their Account ID to connect" ^[29]. Credential and ownership artifacts live in more than one system, so a NetSuite-only list will miss them.

The third is that evidence should be designed rather than discovered: because native logs are short, export system notes, integration record snapshots and monitoring summaries on a schedule, with retention set by policy. Oracle's timelines may shift, and log coverage differs by channel and authentication method. Organizations that prefer outside help can engage an implementation or managed-support partner for discovery and ongoing stewardship. The template here is usable by any team, whether run in house or with outside help.

Frequently Asked Questions (FAQs)

What is a NetSuite integration register, and how does it differ from an inventory template?

A register is the owned, reviewed version of an inventory: it adds accountable owners, credential metadata, lifecycle state, review dates and evidence to the list (Table 2).

How should integration owners be assigned?

Assign one accountable business owner and one accountable technical owner per row, with a named backup, and keep a single accountable role per activity ^[34]. Run the orphan test to catch rows whose owners left.

How do NetSuite TBA credentials get rotated?

Oracle publishes no interval: tokens "do not expire" ^[6]. Create a new token for the integration user and role, update the secret store, confirm traffic, then revoke the old token. Resetting consumer credentials "invalidates the old ones" ^[7], so coordinate that change with every holder, record the dates and set the interval by policy.

How is data flow mapped for each integration?

Record direction, record types, schedule, control totals and downstream consumers per row; NIST AC-4 frames the control basis as information flow "between connected systems" ^[12]. Use one diagram key (symbols for channel, direction and trust boundary) across the portfolio.

How do you decommission a NetSuite integration?

Follow the eight-step checklist above, from confirming intent through freezing, revoking credentials and removing artifacts to storing evidence with sign-offs.

What belongs on an integration audit checklist?

Every active row has two owners, a purpose, a channel and an authentication method; credential dates are recorded; roles follow least privilege ^[12]; sandbox post-refresh actions were done; and system notes were reviewed ^[63].

How should least privilege be applied to integration users?

Use a dedicated user and role per integration, grant only what the channel needs, and avoid permissions such as Access Token Management that let a user manage tokens for others ^[49].

How are RESTlets and Suitelets inventoried?

Start from script deployment records ^[21], then add callers by interview, because user credential calls "aren't logged on any integration record" ^[3].

What is integration governance in this context?

The rules that keep the register accurate: a required row before go-live, quarterly owner attestation, credential and lifecycle fields, and decommission sign-off.

Conclusion

A NetSuite integration register is feasible, but it must be assembled and maintained deliberately because the platform's native inventories are partial and its native logs are short. Integration records, script deployments, Saved CSV Imports and Installed Bundles each cover a slice, and file drops and some RESTlet callers fall outside all of them. The register is the durable layer that joins these lists to owners, purpose, credentials and lifecycle.

The design choices that matter most are small and testable: one row per integration, two named owners, credential metadata without secrets, a computed credential age against an organization-defined interval, a sandbox checklist that reflects Oracle's documented refresh effects, and a quarterly orphan test with owner attestation. The announced changes to SOAP, TBA and RESTlet authentication give the register an immediate, dated purpose. As of October 2026, the remaining uncertainty is coverage by channel and account type, which the test record fields in Table 2 are meant to resolve. Each organization should retest the behaviors cited here in a current account and set retention and rotation intervals through its own policy and professional advice.