Supplying Additional Values When Creating FSM Records
This topic is intended for administrators and developers who supply additional field values when creating records.
A creation operation can obtain values from a source record and pass those values as attributes to a destination record model. The source search map determines which values are read and the attribute names supplied. The destination model map connects those names to the fields written on the new record. An additional mapping is useful when the supplied attribute name differs from the destination field ID. A mapping is also useful when normal model reads need that field under a defined attribute.
For example, an implementer wants a project created for a new asset to receive the department selected on the asset's item. The Item search in warranty.asset can return a department attribute. An additional Project model mapping then connects department to a custom Department field on the Project.
The following customization fragment illustrates this connection. Merge the fragment into the existing custom configuration. The inherited Item restrictions, type and date mappings remain in effect.
The custom field IDs in these examples are placeholders. Replace each ID with the corresponding Item source or Project destination field ID from your account. Both fields must already exist and accept compatible values.
{
"warranty": {
"asset": {
"item": {
"map": {
"department": "custitem_example_department"
}
}
}
},
"models/project": {
"prototype": {
"map": {
"department": "custentity_example_department"
}
}
}
}
Here, the Item source field supplies department, and the Project model writes that attribute to custentity_example_department. A Department selection normally supplies the Department internal ID. The source value must be valid for the destination field. The source is a direct Item search, so this example doesn't require an additional Item model mapping.
In the shared record-model write path, an attribute without an explicit mapping uses its own name as the destination field ID. This applies to standard and custom field IDs. For example, the Item search could instead supply the Project custom field ID directly:
{
"warranty": {
"asset": {
"item": {
"map": {
"custentity_example_department": "custitem_example_department"
}
}
}
}
}
With no existing Project mapping for custentity_example_department, the shared write path uses that name directly. No additional project mapping is needed to write this supplied value. An existing nonempty field mapping for the same attribute takes precedence.
Using a destination field ID doesn't automatically read a source field with that name. The source search still needs its own valid mapping. It also doesn't make every field available in normal model reads: add a model mapping when that field must be included in those reads. An unmapped field may be fetched by an explicit model attribute request, but merely naming it doesn't add it to every search.
The destination field must be available and writable on the record being created, and the supplied value must meet its type, permissions, and validation requirements. A model mapping used in normal searches also requires the field to be searchable. Adding a mapping doesn't create a NetSuite field or FSM Mobile element, initiate an operation, or keep records synchronized. Model mappings apply to other operations using the same model as well. For the new-Asset trigger and the effects on subsequent requests and existing projects, see Configuring FSM Automatic Project Creation for New Assets. For detailed mapping syntax, see FSM Searches and Field Mapping.