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

# Netsuite Provisioning

*Lumos offers several NetSuite connectors, each its own integration card. This article covers **NetSuite Provisioning**, complete user management (sync plus create, update, deactivate, and delete). For visibility only, use NetSuite Read-Only. To also import SaaS invoices into Lumos Vendors, use NetSuite Read-Only (with Invoice Ingestion).*

## After this article

You will be able to connect NetSuite to Lumos to sync employees, roles, and permissions, manage role assignments, and create, deactivate, or delete users during offboarding.

## Capabilities

| Functionality | Type | Sync | Provision | Description |
| :- | :- | :- | :- | :- |
| Users | Account | Yes | Yes | User accounts (employee records). Lumos can create, update, deactivate, and delete employees |
| Permissions | Permission | Yes | No | Permissions in NetSuite |
| Roles | Permission | Yes | Yes | Roles to manage access in NetSuite. Lumos can assign and remove roles |

| Deprovisioning Action | Type | Description |
| :- | :- | :- |
| Deactivate | User | Removes access (`giveAccess: false`), and with **Mark Users Inactive When Deactivating** enabled also clears all roles and marks the user inactive |
| Delete | User | Permanently deletes the employee record (destructive, cannot be undone) |

**Provisioning behavior:**

* **Create:** Lumos creates the employee over the REST API with the email, first and last name, and the roles from the request. An email and at least one name (first or last) are required, and Lumos expects at least one role. Password, numeric subsidiary ID, custom attributes, and user status (`ACTIVE`/`SUSPENDED`, case-sensitive) are optional. When roles are included, NetSuite grants login access and emails the user to set a password, unless the request includes a password, in which case Lumos sets it directly.
* **Create is idempotent:** if an employee with the same email already exists, Lumos links the existing record and makes no changes to it.
* **Assign a role:** an additive update on the employee record. Assigning a role to an employee without login access also grants access.
* **Remove a role:** Lumos reads the employee's current roles and writes the remaining set. Removing the last role also revokes access (`giveAccess: false`), since NetSuite users need at least one role to retain access. Removing a role the employee doesn't hold returns an error.
* **Update:** Lumos updates the employee record with only the fields in the request. Omitted fields are left unchanged.
* **Reactivate:** there is no standalone activate action. The custom **Create or activate account** action covers this. It creates the employee if the account is absent, and otherwise restores login access and replaces their roles with the ones in the request. Roles held before deactivation are not restored.

Known limitations: login activity is limited to a 90-day lookback. Limited information is available for vendor-type users. Custom user fields may not be synced, and users with multiple roles may show the primary role only.

## Required plan and roles

* **NetSuite features:** enable SuiteTalk web services (REST and SOAP) and **Token-Based Authentication (TBA)** on the **Setup > Company > Enable Features** page, under the **SuiteCloud** tab. The integration authenticates with credentials (Consumer Key, Consumer Secret, Token ID, and Token Secret) taken from an integration record in the **Enabled** state.
* **Token role permissions:** create a role for the integration, and select **All** under **Accessible Subsidiaries**. Under the **Permissions** subtab, grant:
  * **Lists > Vendors: View**
  * **Lists > Currency: View**
  * **Lists > Accounts: View**
  * **Lists > Employee Record: Edit**
  * **Lists > Employees: Edit**
  * **Setup > Login using Access Tokens: Full**
  * **Setup > REST Web Services: Full**
  * **Setup > User Access Tokens: Full**
  * **Setup > Bulk Manage Roles: Full**
    The three **Setup: Full** permissions (Login using Access Tokens, REST Web Services, User Access Tokens) are required to authenticate. **Employee Record** and **Employees** need **Edit** rather than View because provisioning writes to employee records. **Bulk Manage Roles: Full** is what lets Lumos provision or deprovision roles and auto-generate AppStore role permissions. Add access to **Login Audit** records if you want login-activity data.
* **Permission scoping:** all write operations run over NetSuite's SuiteTalk REST API and require the `rest_webservices` OAuth scope plus the role permissions above. If you don't want Lumos to change anything in NetSuite, use NetSuite Read-Only instead.

## Read-only access vs provisioning

**Is read-only possible?** Yes, but not through this connector. NetSuite Provisioning is built to create, update, deactivate, and delete NetSuite users, and its token role needs Employee Record and Employees set to Edit plus Bulk Manage Roles set to Full to do that. If you don't want Lumos to change anything in NetSuite, connect the separate NetSuite Read-Only card instead.

**What read-only requires.** The same OAuth 1.0a TBA credential type (Consumer Key, Consumer Secret, Token ID, Token Secret, Account ID), generated against NetSuite Read-Only's narrower role, which asks for View rather than Edit on the Employee Record and Employees permissions and View rather than Full on Bulk Manage Roles. Follow the NetSuite Read-Only article for that setup.

**What full provisioning requires.** The TBA credential values and the nine role permissions listed below, including Employee Record and Employees set to Edit and Bulk Manage Roles set to Full, plus SuiteTalk web services and Token-Based Authentication enabled in NetSuite. Follow the steps below.

**Watch out for.** Provisioning and read-only are separate integration cards, each with its own access token bound to a different NetSuite role, so switching modes means creating a new connection rather than changing a setting on this one. Granting this Provisioning card a narrower, View-only role instead of using the Read-Only card's own role will break provisioning rather than making it safely read-only, since the connector still expects Edit and Full permissions to be present.

## Instructions

**Phase 1: Prepare NetSuite**

1. Log into NetSuite with an Admin account. Note your subdomain from the account URL (for `https://1234567.app.netsuite.com/` the subdomain is `1234567`).
2. Enable SuiteTalk web services (REST and SOAP) and **Token-Based Authentication** on the **Setup > Company > Enable Features** page, then open the **SuiteCloud** tab.
3. Create a role for the integration at **Setup > Users/Roles > Manage Roles > New**. Name the role, select **All** under **Accessible Subsidiaries**, add these permissions under the **Permissions** subtab, then click **Save**:
   * **Lists > Vendors: View**
   * **Lists > Currency: View**
   * **Lists > Accounts: View**
   * **Lists > Employee Record: Edit**
   * **Lists > Employees: Edit**
   * **Setup > Login using Access Tokens: Full**
   * **Setup > REST Web Services: Full**
   * **Setup > User Access Tokens: Full**
   * **Setup > Bulk Manage Roles: Full**
4. Attach the role to a user. Go to **Lists > Employees > Employees**, click **edit** next to the user, open the **Access > Roles** subtab, add the role you just created, and click **Save**.
5. Create an integration record at **Setup > Integration > Manage Integrations > New**. Choose any name and uncheck the **TBA: Authorization Flow** and **Authorization Code Grant** boxes, then click **Save**. Copy the **Client ID** (Consumer Key) and **Client Secret** (Consumer Secret) shown on the page. You can't recover them after navigating away.
6. Create a token-based authentication token at **Setup > Users/Roles > Access Token > New**. For **Application Name**, **User**, and **Role**, select the integration, the user you attached the role to, and the service role. The **Token Name** fills in automatically. Click **Save**, then copy the **Token ID** and **Token Secret**. You can't recover them after navigating away. NetSuite access tokens don't expire, but they can be manually revoked.

**Phase 2: Connect in Lumos**

1. Open the **NetSuite Provisioning** integration card in Lumos.
2. **Account ID:** the subdomain part of your NetSuite URL. For `https://1234567.app.netsuite.com/` the Account ID is `1234567`. For a sandbox it may look like `1234567-sb1`. Enter the full value and use a dash (`-`) as the separator, not an underscore.
3. Enter the Consumer Key, Consumer Secret, Token ID, and Token Secret.
4. Optional setting: **Mark Users Inactive When Deactivating** (default disabled). When enabled, deactivating a user in Lumos also marks the user inactive in NetSuite in addition to disabling login access. When disabled, only login access is removed and the employee record stays active.
5. Click **Connect**.

## API Endpoints Used

<Note>
  The API endpoints this integration uses are available to logged-in Lumos customers. [Log in](/login) to view them.
</Note>

## Troubleshooting

**Authentication failures ("Invalid login credentials" / "Token authentication failed").** Verify Token-Based Authentication is enabled in NetSuite features. Confirm all four credentials are correct with no extra spaces. Check the integration record is Enabled, the access token hasn't been deleted or revoked, the token's user account is still active, and the user's role has the necessary permissions.

**Users not syncing.** Verify the token's role has read permissions for Employee and Vendor records, users have email addresses, and users aren't inactive. This connector intentionally includes users with **Give Access** disabled (they still have a NetSuite account worth tracking).

**Roles not appearing.** Verify read permissions for Role records and that roles are active and not restricted. A 400 **"Record role was not found"** error means the connecting role lacks the Bulk Manage Roles permission (or the wrong token is in use).

**Permissions not syncing.** Lumos queries the `rolepermissions` table, so only permission and level combinations currently assigned to at least one role will appear. Verify the missing permission level is assigned to at least one role, then trigger a new sync.

**Activity data not syncing.** Verify access to Login Audit records and that login audit logging is enabled. Only login events within the 90-day lookback are returned. If the LoginAudit record type isn't enabled or accessible for your account, the connector treats last activity as unavailable rather than failing.

**"Invalid Account ID".** Recheck the Account ID against your NetSuite URL. If a full value with a suffix fails, try the numeric account ID alone. For sandboxes verify you're using the correct sandbox account ID with a dash (not underscore) separator.

**API rate limit exceeded.** Reduce the concurrency limit, review other integrations consuming your API quota, or contact NetSuite to increase limits.