Our NetSuite tips are designed to help you get the most out of using NetSuite. This month’s guide is all about using some of the more advanced features of custom fields so that you can make them work exactly the way you need them to.
Custom fields can be added to your records and transactions in order to make them more specific to your business.
Our last guide explained what custom fields are and the different types available; how you set them up and assign them to the desired forms; how you set the display properties; and how you edit them.
This guide takes this a step further and explains how to set the validation and defaulting properties. It also covers how to set the sourcing and filtering criteria as well as how to set any access restrictions to the fields.
Setting validation and defaulting properties
Validation options are constraints that can be placed on your custom fields to help control the information that is entered into the field.
Defaults are values you specify for your custom fields that populate automatically when a record or transaction is first created.
To set validation and defaulting properties:
1. In your custom field set-up page (Customization > Lists, Records, & Fields > [Custom Field], where [Custom Field] is the desired field type.)
2. Click the Validation and Defaulting subtab.
Possible validation options include:
- Mandatory: Information must be entered in the custom fields before a record or transaction can be saved. (Note: When using the same custom field on different forms, consider setting the fields to mandatory when customising the form rather than on the field itself. This is useful in cases where in one form the field information is required, but not in another.)
- Minimum Value: Set the minimum number that can be entered in the custom field. A record or transaction cannot be saved with a value below the minimum that is set here.
- Maximum Value: Set the maximum number that can be entered in the custom field. A record or transaction cannot be saved with a value above the maximum set here.
- Maximum Length: Set the maximum number of characters that can be entered in the custom field. A record or transaction cannot be saved if the information entered in this field exceeds the number of allowed characters.
- Allow Delete of List/Record Values: Indicates how the system handles deletions of records referenced by this custom field. Select Prevent and Return Error to prevent deletions and return an error message stating that the record could not be deleted due to dependencies and providing a link to dependent records. Select Allow and Set Dependent Field Values to Null to allow deletions, null out field values that use the deleted record, and log system notes for deletions.
- Formula: Enable to validate SQL formula expressions when this field is defined as a formula field.
- Search: Select a summary search from this dropdown if you want values for this custom field to be based on search results. Only available for kinds of custom fields and data types that support summary search-derived values.
- Field: If you want values for this custom field to be based on summary search results, you can optionally select a comparison field to join related records in cases where you want to put the custom field on a form for a record type that is different from the summary search record type. Only available for kinds of custom fields and data types that support summary search-derived values.
4. If desired, enter default parameters for this field.
5. In order to set values into an Inline Text or Disabled field, you must specify a default value or source the information for the field from another field.
6. Depending on the field type, various default values can be specified. Possible options include:
- Default Checked: Tick this box to indicate that the check box custom field should be checked by default. The custom fields can still be cleared on individual transactions and records.
- Default Value: If desired, enter a value to display in this field by default. The value can still be changed on individual records and transactions if the field is not locked.
- Dynamic Default: Dynamic default allows you to select from preset defaulting options specific to the kind of field you are creating. There are three types of dynamic defaults:
– Current Date/Time: For date fields – select this to have your custom field automatically filled with the current date or time.
– Current User: For Employee List/Record fields – select this to have the name of the employee entering the record or transaction automatically filled in this field.
– Current User’s Supervisor: For Employee List/Record fields – select this to have the name of the supervisor selected on the employee record automatically filled in this field.
- Default Selection: Set a selection list to display in the custom field by default. The choices are limited to the list selected in the List/Record field when creating this custom field.
7. Once you have validation and defaulting properties, you should now set any sourcing criteria.
Customising delete behaviour for records referenced by custom fields
List/Record and Multiple Select custom fields provide a list for users to select value(s). This list of values is populated by records of the list/record type set in the custom field definition. Since these types of fields are dependent on these referenced records, deletion of these records can be problematic.
For custom field definitions that have a type of List/ Record or Multiple Select and have the Store Value option enabled, the Allow Delete of List/Record Values option is provided. This option permits overrides of the default system behaviour when a delete is attempted of a record referenced by values in this custom field.
Default settings for this option are based on the record type selected in the List/Record field:
- For entity, item, event, and transaction type records: the default is Allow and Set Dependent Field Values to Null. When a deletion of a referenced record sets a dependent custom field value to null, a system note is logged on the record containing the dependent custom field value. The note specifies the user who deleted the referenced record as the Set by value, and Unset as the Type.
- For other record types (including custom records): the default is Prevent and Return Error. When a deletion of a referenced record is prevented due to dependent custom field values, the error message includes a link to a page listing the dependent records. The Dependent Records page includes the name of the referenced record at the top of the page. The list on this page includes a line for each dependent custom field, with the following details: kind of custom field, name of custom field, name of record containing the custom field with a clickable link to the record.
Setting sourcing criteria
A custom field can source information from another record in your account. Sourcing enhances your NetSuite forms by reducing data-entry errors and ensuring that your customers and employees always have the most current information.
The information populated into the custom field is dependent on fields associated with a record selected on another field within that form. For example, a custom field for Sales Reps is placed on a custom case form. When a company record is selected in the Company field, the Sales Rep already defined in the selected company record is sourced to the Sales Rep field on the case form.
You can source from both standard and custom fields.
Storing the value
When setting up sourcing, you have the option to store the value.
When the field is not stored, the information is not saved in the custom field. A custom field that does not store the value enables you to look at data that is stored elsewhere when you are setting up searches and reports.
By storing a sourced field, the sourcing will autofill the field with a value when the master field is changed. You can then change the value of the custom field. The value is stored independently and has no impact on the source field, so any changes made in the custom field are not updated in the source.
To set sourcing and filtering criteria:
1. Edit the custom field that you want to add sourcing and filtering criteria to.
2. If you do not want to store the value, clear the Store Value box. In most cases you do not want to store the value.
3. Click the Sourcing & Filtering subtab.
4. In the Source List field, select the field that references the record you would like to source information from.
5. When working with entity fields, you can also define the field to source from a field on the parent record by selecting Parent in the Source List dropdown.
Note: You CANNOT source information for a Multiple Select field type.
6. In the Source From field, select the field you want to source from. Any fields available on the record you select in the Source List field can be selected. The field selected here must be consistent with the Type selected for the custom field.
7. If your field is a List/Record field, you can filter the choices that can be selected.
8. When a List/Record Type field is defined, you can choose to populate the custom field with values that meet specific parameters in the sourced list or record.
First, select the desired item to filter by in the Source Filter by field. Then choose an item from the Source List and, optionally from the Source From field. When you choose an element from the Source List, it will fill your custom field with all elements where the Source Filter by field matches the Source List (or the Source From field of the Source List).
Please note: the field selected within the List/Record field must have options or fields if it is a record, otherwise the Source Filter by dropdown will be blank.
9. The record you are sourcing from must be associated with the type of record you want to appear in your custom field.
Note: The field selected for the Source Filter by field MUST be in the record type selected as the List/Record.
10. Once you have set the sourcing criteria, you should set any filtering criteria.
Note: A custom field with a sourcing relationship is not available for mass updates or inline editing.
Understanding the ‘Source Filter By’ Field
Following are some examples of how you can use the Source Filter by field to create dynamic custom fields.
Example 1: Linking Two Transactions
Suppose that you want to link two transactions, such as an invoice and a subsequent credit.
First, add a transaction custom field to customer credits (using a custom form to limit it only to the credit form). The field should be a List/Record Transaction Type and Source Entity in the Source List and Source Filter By Fields. When you select a customer on the credit memo, it will populate the new list field with only invoices from that customer.
Example 2: Combining Static and Dynamic Filtering
Suppose that you want to create a Linked Order field on a Sales Order that allows you to choose another Sales Order from that customer.
First, add a transaction custom field to sales order forms. The field should be a List/Record Transaction Type and source Entity in the Source List and Source Filter by fields. Add a static filter to narrow the drop-down to only transactions of a particular type (Sales Orders). When you create a new sales order, select a customer, and the Linked Order drop-down populates with sales orders from that customer.
Example 3: Filtering Against the Source From Value
Suppose that you want to have a field on a task record that lists all of the subordinates of a Sales Rep associated with a selected opportunity.
First, add a custom field to a Task record. The field should be a List/Record Entity Type (for example Employee). Since you want only the Sales Reps associated with the selected opportunity, define the field Source List as Opportunity. Then filter the Source From by Sales Rep and the Source Filter By as ‘Supervisor’. The resultant list filters down to cases where the Source Filter by value (Supervisor) equals the Sourced From value (Sales Rep).
Setting Filtering Criteria
When creating a list/record or multiple select custom fields, you can filter the choices available in that field on records and transactions based on selections made in other fields. This allows you to tailor the exact choices offered to users entering records and transactions.
Note: Filtering only applies to lists of records. It does NOT apply to custom lists.
To filter a list/record or multiple select custom fields:
1. Click the Sourcing and Filtering subtab.
2. In the Filter Using field, choose a field to filter on.
3. The field you choose here is a field on the record you selected in the List/Record field.
4. The field selected limits the results according to the filter criteria you define. For example, if you were limiting an employee list field to only show sales reps, you would select the [Is] Sales Rep field in this column since that is the name of the field on the employee record.
Note: If you specify two or more filters, the custom field uses a popup list, not a dropdown list.
5. If the field chosen in the Filter Using column is a check box, tick the Is Checked box to show only records with that box checked.
6. In the Compare Type column, select how you want the information compared to the criteria you set. For example, select equals to ensure that the information you set as criteria matches the selections available in the list exactly.
7. In the Compare Value to column, enter the value you want to filter the list by.
8. If the field chosen in the Filter Using field is a list, choose the value you want to show in the Value Is column.
9. Tick the Is Not Empty box to include all records with a value entered in your filter field. (This option is not available for check box fields.)
10. Tick the Is Empty box to include all records with no value entered in your filter field.
11. In the Compare To Field column, choose which field on the record selected in the List/Record field you want to compare to the field in the Filter Using column.
12. Click Add/Edit.
13. Repeat these steps to add filters to this custom field. The more filters you add, the fewer choices are offered in the field. Each selection must match each filter to be included.
14. Click Save.
Next, you can define who has access to your custom field.
Restricting access to custom fields
You can control who can access the information in custom fields, allowing you to maintain the security of your business information. The access you define determines how it can be accessed both on the record as well as through search results and reports.
Access to a field can be based on role, department, or subsidiary. The following custom access levels can be assigned to each department and subsidiary:
- Edit – The field and its contents can be viewed and changed.
- View – The field can be seen, but its contents cannot be changed. (This permission level affects how the form is accessed on records.)
- Run – The field can be seen through reports and search results, but its contents cannot be changed. (This permission is only applicable to reports and searches.)
- None – The field cannot be seen, and its contents cannot be changed.
For cases when different access levels are defined for a user’s role, department, or subsidiary, the highest level of access is granted. For example, if an employee is assigned to a department that has edit access to a custom field, and the employee’s role has been granted view access. The employee has the higher level of access – in this case, edit access.
In addition to search and reporting, the access level granted to a custom field includes instances where it is referenced by online forms, mail merge operations, and when it is sourced by other custom fields, or referred to by formula fields.
You can set the level of access you want to grant by default to custom fields. The default access level applies to the roles, departments, and subsidiaries, that you do not define on the Role, Department, and Subsidiary subtabs.
To set default access, edit the custom field record, and click the Access subtab. In the Default Access Level, set the level of access you want to give by default. In the Default Level for Search/Reporting field, select the level of access you want to give through search and reporting.
However, the access you define on the Role, Department, and Subsidiary subtabs overrides the default access levels.
To set role, department, or subsidiary access restrictions:
1. Edit the custom field record.
2. Click the Access subtab.
3. In the Default Access Level field, set the access level you want to grant to roles, departments, and subsidiaries that you do not specifically define below.
4. In the Default Level for Search/Reporting field, set the level of access you want to grant through search and reports to roles, departments, and subsidiaries that you do not specifically define below.
5. Click the Role, Department, or Subsidiary subtab.
6. In the first column, select the role, department, or subsidiary you want to define access for.
7. In the Access Level column, select the level of access you want to grant.
8. In the Level for Search/Reporting column, select the level of access you want to give this role, department, or subsidiary via search and reporting.
9. Click Add.
10. Repeat these steps for each role, department or subsidiary.
11. Click Save.
The above procedure describes how to limit access to a custom field. You also can tick the Apply Role Restrictions box to limit access to an entire custom record, according to a custom field’s values. This setting extends access restrictions based on class, department, location, or subsidiary, that are set on role definition pages.
Access level history
For auditing purposes, you can view any changes that have been made to custom field access levels.
To view custom field access changes, open the custom field record. Click the Access subtab, and click the History subtab.
You can view the date and time a change was made, the user who made the change, and the changes that were made.
Bundling fields with access restrictions
If you include a custom field in a bundle that has access restrictions, custom roles that you have given access to are not automatically included in the bundle.
If, however, you include those custom roles in the same bundle, the access restrictions are preserved.
The access level assigned to standard roles is preserved when you bundle a custom field that has access restrictions.
Custom field restrictions based on subsidiaries or departments are not carried over into the target account since departments and subsidiaries cannot be included in a bundle.
Creating display-only custom fields
You can create custom fields that display information but do not store that information with any record or transaction. You can create a display-only field of any type with any display, default, validation or sourcing options.
A display-only field is especially useful when used in addition to sourcing information. Fields that use sourcing with a display-only field always display the most accurate information. This is because the field is not stored so the information must be retrieved from the source field every time the page is loaded.
To create a display-only custom field:
1. Either edit a custom field, or create a new custom field.
2. Clear the Store Value box.
3. Click Save.
The information entered in this custom field is no longer stored in your account.
Tracking changes to custom fields
In the History tab for each custom field, information on every saved change is displayed with the following summary information:
- Field Type
- Record Type (if Type is List/Record)
- Store Value
Inactivating a custom field
If required, you can remove a custom field from a specific record type or delete the field completely. An alternative is to make a custom field inactive instead of deleting it. Data and associated forms for an inactive custom field are maintained in NetSuite, which is useful in cases where you may need to use a custom field again, or you simply want to preserve custom field data in the system.
When a custom field is inactive, it no longer appears on any forms, it is not available in searches, and it is not available to SuiteScript or SuiteAnalytics Connect, just like a deleted field.
You can make a custom field inactive on the record page for the custom field or in a list of custom fields:
- On a Custom Field record, tick the Inactive box to make a custom field inactive.
- A Show Inactives option is available on all custom field list pages, including the list of custom fields on each custom record type’s fields subtab. By default, the Show Inactives option is disabled, so that inactive custom fields are filtered out of lists. When this option is enabled, the list displays both inactive and active custom fields, and each custom field in the list has an Inactive check box next to it. You can tick this box to make a custom field inactive, and clear this box to reactivate an inactive custom field.
When a custom field is made inactive, it no longer appears on any forms or reports and it is not returned by global search – it is not available anywhere, just like a deleted field. However, data and associated forms for an inactive custom field are maintained in NetSuite, while a deleted field is completely removed from the system.
If an inactive field is later made active again, all of its data is restored, and the field appears on all of the same forms as before it was made inactive. Note that some settings are not maintained for inactive fields, including display formatting.
Warning: NetSuite does not check to see if custom fields are referenced in SuiteScripts. If you inactivate a custom field, update any SuiteScripts that reference the field, otherwise they will not work.
A custom field cannot be made inactive if other NetSuite records depend on it. For example, a custom field cannot be made inactive if it meets any of the following conditions:
- It is sourced by another custom field.
- It is used in lead conversion mapping.
- It is used in the Parameter, Values section for a workflow action.
- It is used in a workflow definition condition.
- It is used in a filter or a condition for a saved search.
- It is used in a filter or a condition for a saved search.
In addition to the above examples, there are other dependencies that may prevent you from making a custom field inactive. When you try to make a custom field that has dependencies inactive, an error message is returned, with a link to a Dependent Records page, where you can review details about these dependencies.
You can use the Check Inactivate Dependencies option under the Actions menu on each custom field record to proactively check for dependencies before you try to make the custom field inactive.
Note: Script custom fields cannot be made inactive.
I hope this has been a helpful walkthrough for using the more advanced features of custom fields in NetSuite. If you would like to find out more about how NetSuite works, please don’t hesitate to get in touch with our team of experts or view our other ‘NetSuite tips’ guides below.
Feel free to share this guide with your colleagues or comment below.