Descartes Pacejet can accept additional values from NetSuite when the standard integration does not include the data you need. One option is to map those values into Pacejet user fields. This approach can work for simple use cases, but it comes with important limits and reserved field ranges that you need to understand before you configure anything.
For most new implementations, custom data is the better choice. Custom data is easier to scale, easier to label clearly and less likely to conflict with existing platform behavior. Use the user fields only when they are the right fit for a specific requirement.
Overview
User fields are placeholder fields in Descartes Pacejet that can store values at the shipment, package, or product level. In a NetSuite integration, you can send NetSuite values into these fields so they can be referenced in rules, paperwork, or other downstream processes.
You do not need to expose a user field in the User Interface unless someone needs to see it or edit it manually. A mapped value can still be used by platform logic even when the field is not displayed.
Note: Before you assign any user field for a customer workflow, confirm that the field is not already in use. If you are unsure, contact Descartes Customer Support.
When to Use User Fields
User fields are most useful when you need to pass a small amount of NetSuite data into Descartes Pacejet without creating a larger custom data design. They can support shipment-specific logic, package-specific details or product-specific output, depending on where the field is mapped.
If you are starting a new integration design, custom data is usually the better option. It gives you more flexibility and avoids many of the constraints described in this article.
Reserved User Fields
Some user fields are reserved by Pacejet and should not be used for customer mappings. The reserved ranges depend on the data level.
Level |
Reserved Fields |
Available Fields |
|---|---|---|
Shipment |
UserField1 through UserField3 and UserField13 through UserField15
|
UserField4 through UserField7 UserField9 through UserField12 |
Package |
None by standard convention |
UserField1 through UserField15 |
Product |
UserField1 through UserField4
|
UserField5 through UserField15 |
These ranges come from the existing Pacejet API guidance and should be treated as the default rule when you plan a NetSuite mapping.
Warning: Do not map NetSuite data into reserved user fields. Doing so can conflict with existing Pacejet behavior and may cause unexpected results.
Limitations and Considerations
User fields are intentionally limited. They work best for lightweight values and should not be treated as a general-purpose data structure.
Each level supports up to 15 user fields.
Each user field value is limited to 100 characters.
If an API import sends more than 100 characters, the import can fail.
API handling for these failures does not provide reliable error checking.
These limits matter in NetSuite because field values often look simple in the form but may resolve into longer text during export. Validate the actual value length before you depend on a user field in production.
User fields are also less suitable when you need many fields, more descriptive labels across multiple processes or a design that may expand later. In those cases, custom data is the safer long-term approach.
NetSuite Setup Approach
The exact mapping method depends on how your NetSuite integration is configured, but the general approach is straightforward.
Identify the NetSuite field whose value you want to pass, then map that value into an allowed user field at the correct level.
Identify the NetSuite value you want to send at the shipment, package, or product level.
Choose an available Pacejet user field that is not reserved for that level.
Map the NetSuite value into that user field through your integration logic.
Test the result with a new transaction and confirm the value arrives as expected.
After the mapping is working, you can decide whether the field also needs to be shown in the user interface for manual review. If it is only used by automation or output logic, you can leave it hidden.
When to Choose Custom Data Instead
Choose custom data instead of user fields whenever possible, this is the preferred tool going forward. This is especially true for new NetSuite implementations where the data will be used in multiple places or may grow over time.
Custom data is usually the better fit when you need more than a few fields, want meaningful field names throughout the platform, or expect the integration to evolve. It also avoids the reserved-field constraints described above.
Best Practices
A small amount of planning will prevent most user field issues in NetSuite integrations. Keep the design narrow, document which fields are assigned, and test with real transaction values before deployment.
Use User custom data whenever possible; this is preferred over user fields.
Use only non-reserved user fields.
Keep values under 100 characters.
Use user fields for small, targeted needs rather than broad data modeling.
Document the field purpose and level for each mapping.
Prefer custom data for new or expanding requirements.
Related Guidance
If you need a more flexible setup, review the NetSuite custom data guidance and plan the integration around custom data instead of user fields. That approach is usually easier to maintain and extend.