FSM Mobile Field Upload Lifecycle and Batch Size
File and image fields in Field Service Management (FSM) Mobile use the resource's synchronization behavior. This topic describes the standard field upload path. For the capability and prerequisites, see FSM Mobile File and Image Fields.
Local Save and synchronization are separate stages. For the standard field upload path, native file creation precedes the resource record's save and read-back. Native attachments for files created during synchronization are added after that record processing returns.
|
Stage |
Result or Failure Consequence |
|---|---|
|
Selection and local preparation |
The device reads the selected content and processes recognized image formats. A picker, decoding, or preview problem does not establish a server upload failure. |
|
Local Save |
FSM Mobile retains the proposed record values for synchronization. The locally saved file name or preview does not establish a native file or field reference. |
|
Native file creation |
The server creates files for selected content in the resource's upload context and obtains their native IDs. If a later stage fails, files already created can remain. |
|
Record save and read-back |
The record mapping writes the file IDs and retrieves the resulting record values. A record-save failure can leave uploaded files without the intended saved references. A read-back failure can occur after the record has already been saved. |
|
Native attachment |
The newly created files are attached to the saved resource record. Failure here can leave the file and mapped reference saved with an incomplete attachment. |
|
Response and subsequent display |
A successful response replaces proposed values with returned server values in FSM Mobile. An interrupted response does not prove that earlier server changes failed. Later file access can also fail independently. |
File creation, record saving, and attachment are separate operations. If a later operation fails, earlier changes can remain saved. A failure response does not establish that no file or record was saved. With several file values selected for upload, earlier files can be created before a later upload fails.
FSM Mobile tracks article synchronization and errors. Resource completion is a separate validation result. It is not a file-upload or attachment completion indicator. The capability has no separate per-field stage indicator that proves each server operation succeeded.
The Field Service Suitelet handles FSM Mobile resource requests, and standard file delivery uses the FSM file service and Field Service Restlet 2.x. File maintenance manages temporary download copies. It is separate from field upload processing and does not define retention of uploaded service documents. For script IDs and execution guidance, see FSM Script Reference.
Upload batch size
Synchronizing many newly selected files or images on one resource record can fail. The standard path processes the selected content together with that record's save and native attachments. File values within table rows also contribute to this work. Existing values that already identify native files do not trigger uploads through this path.
As a precaution, aim for no more than about 15 file and image values selected for upload or replacement in one record synchronization. Use smaller groups for large files or complex records. This is planning guidance, not an enforced limit or a guarantee of successful synchronization.
A fixed successful file count is not established. More uploads increase the request payload and server processing. NetSuite processing limits and request failures can prevent completion. A failure can leave some native files, record references, or attachments already saved, as described in Processing model and lifecycle.
Where record validation permits, save smaller groups and allow each group to finish synchronizing before adding more content. Repeated local Save actions made offline or before synchronization completes do not, by themselves, create separate server upload requests. Forms that require many file values together need a capture and validation design that accounts for this limitation.
This guidance concerns selected content in one record synchronization. It does not define the total number of file and image elements that can exist on a page, the total native attachments on a record, or the separate Files-tab upload behavior.