> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# NetSuite

> Connect your Oracle NetSuite account to Oleria to continuously discover users, roles, groups, access tokens, and login activity across your ERP.

Connect NetSuite to Oleria to gain continuous visibility into who can sign in to your NetSuite account and what they can do there. Oleria reads identity, role, and login data through NetSuite's REST web services. It maps every user, role, group, and access token in one place, so you can find dormant or over-privileged access and act on it directly from Oleria.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your NetSuite account:

* **Accounts** - every employee with NetSuite access, with their roles, department, subsidiary, title, and supervisor. Employees whose access was removed but who still hold roles are shown as disabled.
* **Roles** - all standard and custom roles, with each user's assigned roles. Administrator access is flagged, and each role notes the web services and setup permissions it grants.
* **Groups** - NetSuite groups, static and dynamic, with the employee members NetSuite lists for them. Members of dynamic groups (defined by a saved search) may not be listed.
* **Access tokens** - token-based authentication (TBA) access tokens, with the integration, user, and role each one was issued for, and whether it's active, inactive, or revoked.
* **Login activity** - successful and failed logins from the Login Audit Trail, including token-based and OAuth logins, with IP address, role, and user agent. Oleria also uses this to show each user's last login. On the first sync, Oleria reads up to 90 days of history.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview#sync-model).

## Prerequisites

* A NetSuite administrator to enable features, create the integration record, and set up the integration role.
* The **REST Web Services** feature enabled (**Setup** -> **Company** -> **Enable Features** -> **SuiteCloud**). For the recommended OAuth 2.0 method, also enable **OAuth 2.0**. For token-based authentication, enable **Token-Based Authentication**.
* A dedicated integration user. Oleria can't tell which employee its credentials belong to, so use an account that no one will deprovision from Oleria.
* A role for that user with these permissions:

| Permission | Level | Why |
| :- | :- | :- |
| Setup -> REST Web Services | Full | Required to call the API. |
| Setup -> Log in using OAuth 2.0 Access Tokens | Full | OAuth 2.0 client credentials only. |
| Setup -> Log in using Access Tokens | Full | Token-based authentication only. |
| Reports -> SuiteAnalytics Workbook | Edit | Required to run the queries Oleria uses. |
| Lists -> Employees | View (Full for remediation) | Required for accounts and roles. Full lets Oleria revoke access and change roles. |
| Setup -> View Login Audit Trail | View | Optional. Needed for login activity and last-login dates. |
| Setup -> Access Token Management | View | Optional. Needed for the access token inventory. |

If the role can't read the Login Audit Trail, access tokens, or groups, Oleria still connects and syncs everything else, and logs a warning for what it skipped.

Make sure the role isn't restricted to a subset of subsidiaries or departments, or Oleria only sees the employees inside that restriction.

You also need admin access on the Oleria platform to add a new integration.

<Note>
  The exact location of these settings can change over time. If the steps below don't match what you see, refer to NetSuite's documentation on [OAuth 2.0 client credentials](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_162686838198.html) and [token-based authentication](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4247337262.html).
</Note>

## Connect NetSuite to Oleria

<Steps>
  <Step title="Create an integration record">
    In NetSuite, go to **Setup** -> **Integration** -> **Manage Integrations** -> **New**. Name it (for example, *Oleria*), and under **Authentication**:

    * For OAuth 2.0, select **Client Credentials (Machine to Machine) Grant** and the **REST Web Services** scope. Clear **Token-Based Authentication** and the authorization code grant.
    * For token-based authentication, select **Token-Based Authentication**.

    Save the record and copy the **Client ID** (OAuth 2.0) or the **Consumer key** and **Consumer secret** (token-based authentication). NetSuite shows them only once.
  </Step>

  <Step title="Create the credentials for the integration user">
    <Tabs>
      <Tab title="OAuth 2.0 client credentials (recommended)">
        1. Create a key pair and a certificate, for example with OpenSSL:
           `openssl req -new -x509 -newkey rsa:4096 -keyout private.pem -nodes -days 365 -subj "/CN=Oleria NetSuite integration" -out public.pem`
           (an EC key on P-256, P-384, or P-521 also works). NetSuite accepts certificates valid for up to two years, and each NetSuite account (including each sandbox) needs its own upload and mapping.
        2. Go to **Setup** -> **Integration** -> **Manage Authentication** -> **OAuth 2.0 Client Credentials (M2M) Setup** and select **Create New**.
        3. Select the integration user as **Entity**, the integration role as **Role**, the integration record as **Application**, and upload **public.pem**.
        4. Save and copy the **Certificate ID**. Keep **private.pem** for the next step.
      </Tab>

      <Tab title="Token-based authentication">
        1. Go to **Setup** -> **Users/Roles** -> **Access Tokens** -> **New**.
        2. Select the integration record as **Application Name**, the integration user, and the integration role.
        3. Save and copy the **Token ID** and **Token secret**. NetSuite shows them only once.

        NetSuite is retiring token-based authentication for new integrations from release 2027.1. Use OAuth 2.0 for new connections.
      </Tab>
    </Tabs>

    <Warning>
      Treat the private key, consumer secret, and token secret like passwords. Anyone who has them can act in NetSuite with the integration role's permissions.
    </Warning>
  </Step>

  <Step title="Find your account ID">
    Go to **Setup** -> **Company** -> **Company Information** and copy the **Account ID**, for example `1234567`, or `1234567_SB1` for a sandbox.
  </Step>

  <Step title="Find NetSuite in Oleria">
    Go to your Oleria workspace, select **Integrations**, select the **Available** tab, and search for **NetSuite**.
  </Step>

  <Step title="Connect in Oleria">
    Select the **NetSuite** card and fill in the connection form:

    | Field | Notes |
    | :- | :- |
    | Account ID | Required. From the previous step. |
    | Authentication method | Required. **OAuth 2.0 client credentials** or **Token-based authentication**. |
    | Client ID | OAuth 2.0 only. From the integration record. |
    | Certificate ID | OAuth 2.0 only. From the client credentials mapping. |
    | Private key | OAuth 2.0 only. The contents of **private.pem**. |
    | Consumer key and Consumer secret | Token-based authentication only. From the integration record. |
    | Token ID and Token secret | Token-based authentication only. From the access token. |

    Select **Authenticate**. Oleria checks the credentials against NetSuite before saving the integration, and reports which permission is missing if a required read fails.
  </Step>
</Steps>

## Verify the integration

Confirm the new instance appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered accounts, roles, groups, access tokens, and login activity in your Oleria workspace.

<Note>
  If you revoke the access token or the client credentials mapping, or the certificate expires, update the integration in Oleria by editing it and entering the new credentials.
</Note>

## Remediation actions

Beyond discovery, Oleria can act on NetSuite access to remediate risk. All remediation actions need the **Lists -> Employees** permission at **Full**.

| Action | Reversible? |
| :- | :- |
| Revoke NetSuite access | Yes - reversed by restoring access. Oleria clears the employee's **Give Access** box and keeps their roles, so restoring access brings back the same roles. |
| Restore NetSuite access | Yes - reversed by revoking access again. |
| Assign role | Yes - reversed by removing the role. |
| Remove role | Yes - reversed by assigning the role again. Oleria won't remove a user's only role; revoke their access instead. |

A few safeguards apply to every action:

* NetSuite only lets an administrator change an administrator's record. With a non-administrator integration role, Oleria can't revoke access for, or change the roles of, employees who hold the Administrator or Full Access role, and can't assign or remove those two roles. NetSuite rejects the change and Oleria reports the failure; nothing is partly applied.
* Oleria checks the employee's current state first and makes no change if it's already as requested.
* Oleria confirms every change by reading it back from NetSuite.
* A reversal only undoes the change Oleria made. If someone changed the same user in NetSuite in the meantime, Oleria leaves it as is.

## Known limitations

* **Records and transactions aren't discovered.** This integration covers identities, roles, groups, access tokens, and login activity, not access to individual records, subsidiaries, or saved searches.
* **MFA and SSO status is limited.** NetSuite requires two-factor authentication for Administrator and other highly privileged roles, so Oleria reports MFA as required for administrators. For other users, two-factor enrollment and SSO settings aren't available through the API and show as unavailable, not as disabled.
* **Customer, vendor, and partner center users aren't discovered.** Only employees are listed as accounts. Their access tokens and logins still appear.
* **Record changes aren't included.** Login activity comes from the Login Audit Trail. Changes to records, roles, and settings aren't synced as activity.
* **OAuth 2.0 client credentials mappings aren't inventoried.** Only token-based authentication access tokens are listed.
* **API access is matched by permission name.** Oleria marks a user as having API access when one of their roles grants a web services or access token permission.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.