FSM Mobile File References and Relationships

Field Service Management (FSM) Mobile uses separate relationships for file references, native attachments, and upload folders. For the capability and prerequisites, see FSM Mobile File and Image Fields.

File content and its uses are held in different places.

Record or Relationship

Role in This Capability

Native File Cabinet file (file)

Stores the content and native file metadata. Its ID identifies the file referenced by the element.

Resource record or sublist field

Stores the mapped file reference. The file or image content is not stored as binary data in that reference field.

Native attachment

The standard upload path attaches each newly created file to the saved resource record. That record can differ from the current CRM Task or Project Task.

FSM Mobile event, Asset, and employee context

Supplies the standard upload folder context. The requested Asset takes precedence over the event's Asset when supplied. Folder context does not create corresponding native relationship fields.

Field Service File (customrecord_nx_file)

A separate custom association. Standard field uploads do not automatically create this record. For the record definition, see FSM File Record.

The standard upload folder is beneath /Field Service Management/upload/ and is identified by the current event, requested or event Asset, and FSM Mobile employee. It is not identified by the resource name. Field uploads and Files-tab uploads can therefore use the same folder. Existing displayed files can remain in other File Cabinet folders. Loading a reference does not move them.

Files-tab selection can match either its upload-folder rules or the event's native attachment search. Asset matching then selects the relevant subset. History uses its own upload-folder and qualifying-task rules. Service reports and notification attachments use their own file selection and access requirements. Saving a file reference in a field does not automatically make the file available in Files, History, service reports, or notification attachments.

For example, an expense receipt can have a reference on an Expense Report line and a native attachment to that Expense Report. Its folder identifies the current service task. It can qualify for another consumer through that folder context, but its line reference alone does not establish visibility there.

Replacing or clearing a field can leave the previous file eligible for Files, History, or a report because those consumers can select it independently of the current field value. See FSM Mobile Files Tab and FSM Service Reports and Notifications for the related behavior.

Supplied examples

The supplied FSM Mobile resources illustrate different uses of file and image elements.

Example

Behavior

Persistence or Relationship

Contact image

Displays an existing image as a read-only link.

Reads the Contact's native image reference. It does not capture a replacement image.

Asset image

Displays the linked Item's thumbnail, falling back to its display image, as a read-only link.

Reads Item image data through the Asset's Item relationship. It does not create or update an image field on the Asset.

Expense-line Receipt

Provides an editable Image element within each expense row.

The explicit line mapping writes the file ID to expense.expmediaitem. In the standard upload path, a newly uploaded receipt is also attached to the Expense Report. Its upload folder uses the current FSM Mobile job context.

Form-generated Document and Image fields provide another source of these elements. Form loading and automatic mapping are described in FSM Mobile Resource Properties Reference.

Related Topics

General Notices