FSM Mobile File and Image Field Dependencies and Limits
The chosen record type, destination fields, searchable field joins, permissions, and attachment support must match the resource's save design. Form generation and Automap don't establish that these dependencies are valid. Required, hidden, disabled, and read-only combinations must allow the necessary values to be supplied. For more information, see FSM Mobile Element Validation Rules.
This topic includes the following sections:
The standard record-resource upload path creates new File Cabinet files before saving the mapped record, then attaches those new files to the saved record. Uploads are recognized from new file objects containing upload data and no existing file ID. A value already carrying a file ID is not uploaded or newly attached by that path.
Use an attachment-capable destination for this path. The supplied Field Service File record (customrecord_nx_file) has attachments disabled in its record definition. Don't substitute it for the inspection example and assume the native-attachment step will succeed. For information about its separate file-association service, see FSM File Record.
File creation, field persistence, and native attachment are separate operations. A record-save failure can leave an uploaded file without a saved reference. An attachment failure can occur after the record and its file reference have been saved. Saving locally, seeing a file name, or validating the configuration JSON doesn't confirm that all synchronization stages completed.
Several Uploads in One Synchronization
All new file and image values on one article, including values within table rows, are processed during that article's synchronization request. Each file to upload adds file creation and native-attachment work to the request. The same request also saves the record and performs other resource processing. The standard path doesn't automatically divide those values into separate upload requests.
NetSuite limits a Suitelet execution to 1,000 usage units for its combined operations. Many new files can exhaust that shared processing budget before the request completes. The practical count depends on the resource's other operations and the account's processing. For information about script execution limits, see Script Type Usage Unit Limits.
Resource max controls article count. File maxsize and image downsample control individual input size or dimensions. These settings don't establish how many new files can finish in one synchronization. Existing values that already identify native files skip new-file creation through this path. A failed multi-file request can leave earlier files or record changes saved, as described earlier in this topic.
Upload Storage and File Relationships
The following table distinguishes upload storage, field references, and native record attachments.
|
Relationship |
Standard Field-Upload Outcome |
|---|---|
|
File Cabinet folder |
Uses the FSM Mobile upload root, followed by the current event ID, requested Asset or event Asset, and employee ID. The standard root is |
|
Mapped record field |
Stores the native file ID through the configured write mapping. The inspection examples store it on the inspection record. |
|
Native record attachment |
Attaches each newly uploaded file to the record saved by the resource. |
Field uploads and Files-tab uploads can share the upload-folder context. In the inspection examples, native attachments belong to the inspection record, rather than the CRM Task referenced by its parent field. The supplied Files tab attaches to its configured event destination.
A parent link, an Asset selected for folder context, and a native attachment destination are separate relationships. These relationships don't automatically attach the file to every related Task, Case, or Asset.
A field upload can appear in the Files tab through its matching upload-folder context, even when its native attachment belongs to a different record. Appearance in the Files tab, History, or reports depends on the searches and context used by each destination. Don't assume every uploaded file appears in all three.
For information about file selection and display setup, see the following topics:
Synchronization Boundaries by Resource
The following table lists resource arrangements and the synchronization boundaries to preserve for each arrangement.
|
Resource Arrangement |
Boundary to Preserve |
|---|---|
|
Standard record resource, including the supplied Details and Asset resources |
File and Image inputs need compatible mappings and the record-upload prerequisites described earlier in this topic. Adding an input alone doesn't add its field mapping. |
|
Existing standard transaction resource |
Its specialized processing can call the standard upload path. Preserve its transformations, fulfillment, inventory-detail handling, related-record updates, standard definition, and required mappings when extending it. |
|
Supplied |
Uses specialized native-file creation, description updates, and deletion. Making its existing document element editable doesn't implement file-content replacement. |
|
New resource under a different ID |
Establish its own record model, maps, selection, and synchronization. Copying visible Files or transaction JSON doesn't copy the source definition's executable operations. |
|
Numeric-suffix instance of an existing resource |
An ID such as |
The supplied Contact and History resources are read-only views. Removing their read-only controls is not an upload setup. Their displayed values don't establish writable destination fields or an appropriate editable model.
Replacing and Clearing File and Image Fields
In an editable mapped field, selecting replacement content can create a new native file and update the stored field reference. Clearing the input supplies null. A writable primary-ID mapping clears the field after the record saves successfully. The record's validation requirements still apply.
Neither action deletes the earlier native file or removes its native attachments in the standard field-upload path. A read-only mapping has no field to clear. Removing or hiding an element also doesn't delete saved files or their attachments.
Deleting a file through the supplied Files tab is a separate native-file deletion action and can affect any field still referencing that file.