Configuring FSM Mobile File Management
Configure the supplied files resource under "routes/mobile" for job uploads. For more complex jobs, you can configure several labeled Files views beneath parent tabs for specific kinds of work. Use the same categories to select photographs for reports. A separate read-only resource can provide reference documents from related records.
FSM Mobile File Management describes the supplied Files behavior. Reuse files for upload-capable views so that its native file operations remain available.
Configuration References
The following table lists references for common settings and syntax. The following examples contain only the values needed for their Files arrangements.
|
Configuration Detail |
Reference |
|---|---|
|
Editing, merging, and applying configuration; selecting resources for CRM tasks or project tasks |
|
|
Resource labels, hierarchy, permissions, article definitions, and numeric-suffix reuse |
|
|
File picker, accepted types, size limits, image resizing, description fields, and element validation |
|
|
Resource options, template tags, and expressions that combine element values |
|
|
File searches, nested attachment searches, mappings, and retrieval limits |
|
|
Report data, image mappings, and PDF templates |
|
|
Report email selection, recipients, and automatic sending |
To change a supplied Files setting, set the corresponding property under routes/mobile.files. For example, use element.document.accept for picker choices or delete for the Delete action in FSM Mobile. For definitions, defaults, and limits, see the configuration references.
Changing File Organization for More Complex Jobs
These three patterns are adapted from customer production configuration files. They are fragments to combine with the supplied configuration and the account's existing rules. They are not complete account exports. Keep the other resources and conditions in each matching rule; see Selecting Resources.
Category-Labelled Files Tabs
An ordinary Files tab can have a child labeled Files (Internal). The child reuses files and supplies filecategory: "INTERNAL". Use this option in the Files elements, read mapping, and search. Adding the option to a resource rule alone does not classify files.
First, merge this fragment into the supplied routes/mobile.files definition. It adds the category fields and their selection logic while inheriting the upload input, native file identity, asset mapping, and event attachment defaults.
This example selects FSM uploads for the current event and employee, with the inherited asset matching. It replaces the Files search with that folder scope, including for the ordinary Files view. Native attachments stored elsewhere and project reference documents require additional selection branches; those branches are outside this example. Folder selection also avoids relying on the native file join that is unavailable for project tasks.
{
"routes/mobile": {
"files": {
"element": {
"description": {
"hidden": "${ options.filecategory != undefined }",
"required": "${ options.filecategory == undefined }",
"value": "filecategory.value + userdescription.value"
},
"filecategory": {
"type": "text",
"hidden": true,
"readonly": true,
"value": "${ options.filecategory != undefined ? '[' + options.filecategory + '] ' : '' }"
},
"userdescription": {
"type": "text",
"label": "Description",
"column": 2,
"pattern": "^[^\\r\\n]+$",
"hidden": "${ options.filecategory == undefined }",
"required": "${ options.filecategory != undefined }",
"value": ""
}
},
"article": {
"filters": [
[
"formulatext:case when {folder} like '${ event.id }-%-${ user.internalid }' then 'T' else 'F' end",
"is",
"T"
],
"and",
[
[
"formulatext:'${ options.filecategory == undefined ? 'T' : 'F' }'",
"is",
"T"
],
"or",
[
"description",
"contains",
"[${ options.filecategory || '' }] "
]
]
],
"map": {
"userdescription": "formulatext:regexp_replace(regexp_replace({description}, '[\\r\\n]*{[^}]*}$', ''), '^\\[[^\\]]*\\] ', '')"
}
}
}
}
}
Then include these entries in the resources object of the matching CRM task rule at routes/mobile.event.article.task.resources. The same arrangement can be used in a matching project task rule under .projecttask.resources.
{
"array": true,
"parent": [
"files"
],
"files": [
{
"id": "files-1",
"label": "Files (Internal)",
"parent": "files",
"filecategory": "INTERNAL"
}
]
}
The following table shows how the configuration uses each value.
|
Value |
Configuration Behavior |
|---|---|
|
|
Becomes |
|
Hidden |
Builds |
|
|
Captures the technician's text and is required in a categorized view. |
|
|
Combines the prefix and text, for example |
|
|
Removes the capture-metadata trailer and the first bracketed prefix when reopening the file, leaving the editable text. |
|
|
Applies the folder scope and the bracketed category match. Without a category option, the category restriction is bypassed. |
The supplied file operation adds its capture-metadata trailer after the combined description. Editing the user description recalculates the combined value while retaining the selected category. An ordinary Files view keeps its usual description input and can also contain categorized files.
The categorized examples use a single-line description. The current file-update operation can retain old text when updating an existing multiline description; the pattern prevents new multiline descriptions in these views. Existing multiline files require that limitation to be resolved before description editing is enabled for them.
Use fixed category tokens consistently in the instance options and report filters. Changing a token does not recategorize existing files. Existing descriptions must follow the same prefix convention to be selected and restored correctly.
The Files (Internal) label and description filter do not create an access-control boundary. History, reports, and notifications have their own file selection.
Work Groups and Category-Specific Reports
For more complex project task configurations, you can place categorized Files views beneath parent tabs for different kinds of work. In the historical L+O Technologies production configuration, this arrangement covers damage, new unfinished work, resolved work, Post Rough-in, and Appliance Install. The parent tab organizes the FSM Mobile interface; the category option determines the Files selection.
Use the category-enabled Files definition from the previous example. For this three-group arrangement, merge these parent resources under "routes/mobile". These parents display instructions and have no record-backed article. The customer's full configuration also places custom forms beneath its parents; those account-specific records and forms are separate from this Files setup.
{
"routes/mobile": {
"damagereportdummy": {
"label": "Damage Report",
"readonly": true,
"element": {
"instructions": {
"type": "text",
"label": "Note",
"readonly": true,
"value": "Record damage with supporting photographs."
}
}
},
"newutasksdummy": {
"label": "New Unfinished Tasks",
"readonly": true,
"element": {
"instructions": {
"type": "text",
"label": "Note",
"readonly": true,
"value": "Record new unfinished work with supporting photographs."
}
}
},
"completeutasksdummy": {
"label": "Unfinished Tasks (to be completed)",
"readonly": true,
"element": {
"instructions": {
"type": "text",
"label": "Note",
"readonly": true,
"value": "Record work resolved from a previous visit."
}
}
}
}
}
Include the following entries in the resources object of each applicable rule at routes/mobile.event.article.projecttask.resources. Use the account's project task conditions. This fragment supplies the three parents and their child Files instances.
{
"array": true,
"parent": [
"damagereportdummy",
"newutasksdummy",
"completeutasksdummy"
],
"files": [
{
"id": "files-1",
"label": "Damage Photographs",
"parent": "damagereportdummy",
"filecategory": "DAMAGE_REPORT"
},
{
"id": "files-2",
"label": "Unfinished Work Photographs",
"parent": "newutasksdummy",
"filecategory": "UNFINISHED_TASK"
},
{
"id": "files-3",
"label": "Resolved Work Photographs",
"parent": "completeutasksdummy",
"filecategory": "RESOLVED_UTASK"
}
]
}
The resources files-1, files-2, and files-3 reuse the supplied files definition. For example, entering Cracked panel beneath Damage Photographs stores [DAMAGE_REPORT] Cracked panel before the capture metadata. The other children use their own prefixes. File upload and attachment still use the current event; the parent resource in FSM Mobile does not become the native attachment destination.
The following table lists the additional category groups.
|
Category |
Parent Resource |
Purpose |
|---|---|---|
|
|
|
Photographs beneath the account's Post Rough-in custom-record resource. |
|
|
|
Photographs beneath the Appliance Install grouping resource. |
Those additional parents must be defined before adding their child instances. The Post Rough-in parent requires its account-specific record, fields, and form; a category option does not supply them.
Selecting the Same Categories for Reports
A report does not inherit a child Files tab's filter. Its own contents.image search must select the intended event and category, and the XML template must display that data. L+O's report definitions illustrate several choices:
|
Historical Report |
Additional File Selection |
Caption Data |
|---|---|---|
|
Damage Report |
Description contains |
User description with the category prefix removed. |
|
Unfinished Task Report |
Description contains |
Description with capture metadata removed; the category remains. |
|
Underground Report |
No category restriction. |
User description with the category prefix removed. |
|
Appliance Report |
No category restriction in the standard version; the restricted version selects |
User description with the category prefix removed. |
The corresponding XML templates iterate the image collection and use img.url for the image and img.userdescription for its caption. Their forms, report definitions, and email rules are account customizations.
To apply the damage-photo selection to the existing core Project Task service report, merge the following fragment. It retains the report's inherited image address mapping and XML template, restricts the search to the selected project task's upload folders and supported image types, and adds the category condition. Its description mapping removes the category prefix because the core XML uses img.description for captions.
{
"notification": {
"projectTaskEmail": {
"servicereport": {
"attachments": {
"servicereport": {
"contents": {
"image": {
"filters": [
[
"formulatext:case when {folder} like 'projecttask-${ projecttask.id }-%-%' then 'T' else 'F' end",
"is",
"T"
],
"and",
[
"filetype",
"anyof",
[
"BMPIMAGE",
"GIFIMAGE",
"JPGIMAGE",
"PJPGIMAGE",
"PNGIMAGE",
"TIFFIMAGE"
]
],
"and",
[
"description",
"contains",
"[DAMAGE_REPORT] "
]
],
"map": {
"description": "formulatext:regexp_replace(regexp_replace({description}, '[\\r\\n]*{[^}]*}$', ''), '^\\[[^\\]]*\\] ', '')"
}
}
}
}
}
}
}
}
}
This changes the image collection of the existing service report. The report can include photographs uploaded by other employees for that project task, because its folder match has a wider employee scope than the FSM Mobile example. It leaves the report's other data, email recipients, and sending rules inherited. It does not create L+O's separate Damage Report form or PDF.
For a separately named report, use Selecting a Custom Report Template and Supplying Report Data. Use FSM Notification Configuration for selecting and sending that report.
Separate Read-Only Sales Order Files
A separate resource can show reference documents from sales orders linked to the current case while files handles job uploads. This pattern searches for native file IDs attached to those orders and supplies download mappings. It is read-only and does not require the supplied Files write operations.
Merge this custom resource under "routes/mobile", then add sofiles to each applicable event rule's resource list using Selecting Resources. The nested sales order search uses custbody_nx_case; event.supportcase must supply the current case's internal ID. A missing case resolves to the nonmatching ID 0.
{
"routes/mobile": {
"sofiles": {
"label": "Sales Order Files",
"icon": "paperclip",
"readonly": true,
"element": {
"name": {
"type": "text",
"title": true,
"column": 1,
"hidden": true
},
"document": {
"type": "file",
"label": "Download",
"readonly": true
},
"description": {
"type": "textarea",
"column": 2
},
"size": {
"type": "number",
"unit": "byte",
"column": 3
}
},
"article": {
"record": "file",
"filters": [
"internalid",
"anyof",
{
"array": true,
"default": "@NONE@",
"salesorders": {
"record": "salesorder",
"filters": [
"custbody_nx_case",
"anyof",
"${ event.supportcase || 0 }"
],
"map": "formulatext:{file.internalid}"
}
}
],
"map": {
"name": "name",
"document": {
"id": "internalid",
"url": "formulatext:'mobile/file/'||{internalid}"
},
"description": "formulatext:regexp_replace({description}, '[\r\n]*{[^}]*}$', '')",
"size": "formulanumeric:{documentsize}*1024|"
}
}
}
}
}
The outer search retrieves only the native file IDs returned by the linked sales orders' attachment search. It does not select all files in those orders' folders. readonly: true removes create, edit, and delete actions in FSM Mobile. Making this independently defined resource editable would require an established write implementation; matching the Files record type and elements does not supply its specialized operations.
Related Topics
-
FSM Mobile File Management
-
Configuring FSM Mobile Service History
-
FSM File Record