External IDs in NetSuite are unique identifiers assigned to records to facilitate integrations with external systems. They act as stable foreign keys, allowing references during imports, API calls, or data migrations without relying on NetSuite’s internal IDs, which can change. They are particularly valuable for maintaining relationships from legacy systems or third-party apps.
Key Best Practices
Here are consolidated best practices drawn from official documentation and expert guidelines:
- Ensure Uniqueness and Scope: External IDs must be unique within their record type and certain shared record groups (e.g., across entities like customers and vendors). To avoid conflicts, prefix values with an application-specific identifier (e.g., “hr:CUST-123” for HR-sourced customer records). Plan for long-term uniqueness by anticipating multiple integrations.
- Use a Single Maintenance Approach: Adopt one consistent method for setting and updating external IDs (e.g., CSV import, web services, or scripts) across your organization to prevent unintentional overwrites or duplicates. Limit updates to a single integrated application per record type to maintain data integrity.
- Leverage for Integrations and Imports: Use external IDs for efficient data imports, especially to establish relationships in a single operation (e.g., linking customers to sales reps) or during migrations to track legacy numbering. They enable upsert operations to avoid duplicates. In CSV imports, include an “External ID” column and select “Update” mode for edits.
- Handle Visibility and Search: External IDs are not visible on standard forms or included in global search. Expose them via custom fields (e.g., a formula field pulling the external ID value) or scripts (e.g., adding a dynamic field in the BeforeLoad user event). Use saved searches for lookups instead of global search.
- Scripting Considerations: When updating via SuiteScript, use AfterSubmit events (not BeforeSubmit) for changes. Setting external IDs to null is challenging in SuiteScript 2.0.
- Format and Sensitivity: Stick to alphanumeric characters (with underscores/hyphens allowed); they are case-insensitive in web services references for flexibility. Avoid overly complex or irrelevant values to keep them user-friendly.
- Strategic Use Cases: Apply them for linking to external records or streamlining CSV imports (e.g., mapping account numbers as external IDs to reduce errors). During migrations, consider custom fields for source system IDs if external IDs aren’t ideal.
Important Considerations
- Unsupported Record Types: External IDs are not available for types like Accounting Period, Budget Category, Custom Lists, Gift Certificates, Landed Costs, States, or various custom fields. Verify support via the SOAP Schema Browser before use.
- Avoid Overuse: Reserve external IDs for integration needs; don’t populate them indiscriminately to prevent bloat or maintenance overhead.
- Error Prevention: In multi-subsidiary setups, note that records like vendors can only have one external ID per record, not per subsidiary.