Before using an already existing netsuite connection, refresh metadata needs to be done on it. Make sure the last refresh status is complete for the connection.
This feature exposes custom fields for standard objects as named fields in the mapper and during netsuite endpoint creation for advanced search and saved search operations. This feature applies to all basic(except delete) and search operations of netsuite. And for both sync and async processing modes.
For Basic CRUD operations, the custom fields is exposed on the mapper as a named field. The custom field name is derived from the name given to custom field in netsuite. This makes it easier to map without needing to know the internalId and scriptId of a particular custom field for standard object. For eg, here is the mapping done for netsuite update operation. The image below shows a request mapping from Rest(trigger) to Netsuite Update operation on Customer Standard Object .
You can check that there are two fields that have been mapped for the netsuite update operation. ICSEmailId and AdvertisingPreferences. ICSEmailId is a simple type custom field, no further work is required on the part of the integration developer. Just use it like any other simpletype field. AdvertisingPreferences is a complex type custom field. It correlates to a multiselect custom field in netsuite. For complex type custom fields, listitemId correlates to the internalId of the listItem. For the invoke request to netsuite update operation to succeed, integration developer needs to ensure listItemId value is mapped. For mapping more than one listItem, just repeat the ListItem and do the required mapping.
Here is how to get the internalid of list Item of a complex type custom field on netsuite UI
. Go to customization menu->Lists,records,Fields->Lists->Go to the particular custom field in question.
Below image provides an example of response side mapping for Customer Standard Object for netsuite get operation.
For search operations. The approach to be taken by the integration developer for each of the operation type is as follows.
1) Basic Search. On the request side, mapper will surface all discoverable custom fields under customFieldList element under the standard object. The customer does not need to provide internalId or scriptId for the customfield. However it is required to provide the custom field specific search values as well as operator values. For select and multiSelect type customField, searchValue element under the named customfield needs to be used. If more than one listItem needs to be specified, searchValue element needs to be clone. The internalId for the listItem can be obtained from netsuite UI as discussed before in the blog. The response side for basic search is same as described above for the get operation response. The response payload from netsuite wil contain named custom fields in the response.
Diagram showing request mapping for basic search custom field for a standard object.
Diagram showing custom field search for Advertising Preferences which is a multiSelect custom Field, specifiying two list members(by cloning the searchValue element)
For joined Search, on the request side, the mapping to be done remains more or less same as for Basic Search. The only difference being that we can also make use of discovered custom fields in the mapper for joined business object. On the response side for joined search, the response is the same as one for basic search/get operation. One can make use of for-each operation shown below to extract the discovered custom field 3) for Advanced Search and Saved Search, the request side mapping to be done, remains same as for basic and joined search. In addition to above, we can also select discovered custom fields for response sub-object during endpoint creation. Diagram below shows that.
Please note that customers can still use the old way of mapping custom fields for all the operations. By using internalId and scriptId as before.