The company level in FSM is where most of the settings and configurations are maintained. In this unit, we will discuss many of the possibilities available to us.
A company has several static attributes as part of its header data. These are mainly commercial and administrative properties. This data can be maintained under Admin → Company → Company and under Admin → Company → Company Information. Here, some of the following information can be set:
- Company Time Zone
- Default Language
- Company Logo
- Contact Info
- Bank Account Info
- several preferences
This information can then be used as generic data on reports, or referenced by business rules.
The company settingsscreen provides a comprehensive list of settings and parameters for the company. These settings enable, configure or otherwise modulate company-specific features and system behavior.
Over 250 Settings are available. Some examples include:
- Track technician’s geolocation
- Enable push notifications
- Set maximum attachment size
- Generate reports automatically
- Configure checkout conditions
The settings can be maintained under Admin → Company → Company Settings. The search function helps in finding specific settings. For most of the settings, a short explanation is provided. In the SAP Help documentation, the company settings are explained in the context of the features to which they apply.
Many of the company settings can also be maintained on the FSM web UI (as opposed to the admin console). The relevant section is Home → Settings and Configuration. Here, the settings are grouped in tabs, according to the main features to which they apply.
The content of both tools is partially overlapping, so not all settings are currently available in both places. Currently, the admin console is more comprehensive whereas the FSM Shell UI provides a more guided interaction with the options covered therein.
Depending on the topic, the corresponding settings can be maintained in different places. Where possible, the settings and configurations app should be used. This is because the topics are logically grouped here and better consistency checks are in place.
Service Workflows are predefined sets of process steps, checkpoints or milestones to guide technicians through the service work. Using Workflows standardizes processes and allows improved transparency between back-office teams and field employees, as the Workflow Step symbols are visible on the Planning Board.
Workflow Steps can be of many types, focusing the Technician on, for example:
- Allowing the technician to set the assignment as accepted.
- Showing the Activity Address.
- Prompting the recording of Mileage, Efforts or Material Consumption.
- Automatically add a certain smartform instance to the activity.
- Prompting to reviewing and completing associated Smartforms.
- Performing a Checkout by generating a Report and capturing signatures (with either a "report" step or a "checkout" step, depending on the type of checkout report being used.
There is no limit on steps that can be defined, although the best approach is to keep it simple. The steps "new" and "closed" are mandatory and can't be removed or changed.
The service workflow features are activated by setting the company setting CoreSystems.Assignment.IsWorkflowDriven to TRUE. Different Workflows can be assigned to Activities depending on predefined criteria, by using Business Rules. If no business rules are defined, the workflow marked as default will be applied.
The service workflow steps can be understood as a sub-status to the activity status, when the activity is IN EXECUTION. For reference, an activity has the following execution stages:
- IN PLANNING: An activity record has been created and is currently in the activity list.
- IN DISPATCHING: The activity is currently on the dispatching board, but has not yet been released to the technician.
- IN EXECUTION: The activity has been released to the technician and can now be viewed and completed on the mobile application. It is in stage that the service workflow steps apply.
- CLOSED: The activity has been completed and closed by the assigned technician. Activities can also be closed for other reasons.
Thescreen configuration screen configuration tool allows you customize supported screens located in both the mobile and browser-based applications to meet your needs. Many (but not all) screens are supported. With the tool, you can structure the layout and order of fields on the respective screen. This includes editing field names, hiding fields, making fields required, making fields editable, and configuring validation settings.
To see the list of available configurations, go to Admin → Company → Screen Configurations
Basic field properties are static and include flags like visible and required for the field.
Advanced field properties allow the use of Javascript functions to define the required behaviour. These functions are then dynamically evaluated at runtime. The value of the Javascript expression is evaluated at runtime against actual values in the app, which is what makes them "dynamic". With this feature, it is possible to, for example, predefine field values when creating a new record. It could also be used to set advanced conditions for field visibility.
For example, it is possible to define something like "the remarks field is visible only if the subject is greater than 20 characters". As soon as the user types more than 20 characters into the subject field, the remarks field appears automatically.
Since the default screen configuration cannot be changed when a custom screen configuration is defined, the system automatically creates a copy of the default, and marks the new one as custom. Per screen, only one custom configuration may be created. Configurations with non-standard names are not recognized by the application. Custom configurations must be set to activated before they take effect in the applications.
Note
The screen configuration tool is currently optimized for Google Chrome. Using another browser may result in latencies and rendering issues.The custom objects screen is used to create custom fields and objects in order to extend the data model in SAP Field Service Management. With custom objects and fields it is possible to fit scenarios that align more closely with your own business needs. The data is stored in the cloud and available for purposes like automation, validation, and reporting. In addition, you can also set the classification level for custom field definitions to help ensure personal and sensitive data remains secure.
The standard FSM Data Objects can be extended with user-defined fields (UDF). Additionally, completely independent user-defined tables (UDO) can be created, combining one or more user-defined fields, possibly including reference fields pointing to records in other tables.
With certain limitations, custom fields and tables can be used in the following:
- Screen configurations
- Reports
- Smartforms
- Business rules
To maintain custom fields, custom tables, and to see standard field definitions, navigate to Admin → Company → Custom Objects.
Records in custom tables can be created and maintained from within the UI, under Admin → Company → Custom Objects → Custom Objects. If there is a need to create large numbers of records in custom tables, it is advised to explore the possibilities to do this through integration.
In case of integrated solutions, it is advised to create custom object definitions and custom records by the integration/from the back-end system. This helps to ensure data consistency between FSM and the back-end system.
FSM standard functionality can be extended with extension, web containers, and by launching 3rd-party apps:
An Extensions application is an independently developed application designed to extend any of the service processes that are covered by our SAP Field Service Management solution. Extension apps with their own user interface can be embedded in outlets that are placed in various Field Service Management screens, or can be run as full-screen apps from the home menu. Extensions make use of the FSM Shell. This is the common UI framework for standard SAP Field Service Management web apps.
SAP customers can develop and implement their own extensions. Alternatively, you can opt for several extensions that have been developed by SAP partners. The extension directory can be found under FSM Shell → Foundational Services → Extensions → Directory.
Web Containers are containers stored in the mobile application (iOS and Android) that can be configured to read and display data from an external source and allow the user to access an external website from within the FSM mobile application.
3rd-party apps on the technician's mobile device can be launched from a dedicated Service Workflow Step or from the side menu. This capability reduces context switching for your field service engineers and enables you to streamline their workflow when there is a need to interact with multiple applications. However, passing data back to Field Service Management or the FSM mobile app is currently not possible.
SAP Field Service Management covers a number of predefined user languages. On the web UI (shell, not admin) and the windows mobile application, the user can select the language they want to use. The mobile device language for iOS and Android is based on device/OS language.
Only the languages listed in the web UI drop-down are supported. It is not possible to add additional languages. It is, however, possible to create custom translations for specific field labels and for specific field values, for example, to adapt certain terminology to the customer's standards.
The Translations menu under Admin → Company → Translations is used to create and manage custom translations. We distinguish two translations types:
- Label Translation - custom translation of labels
- Value Translation - translations of Objects field such as name, description etc.
Custom label translations use translation keys to allow for alternative text strings/translations for that field label in a given language. Custom translations are company-specific. At the same time, translations can be client-specific. Only fields and labels that have a translation key are supported. Custom translation keys can be created for text snippets, to use in business rules, notifications, custom fields and objects.
Custom value translations let you specify translations for specific fields of specific objects. For example, for the Name field on the object type Checklist Instance, with a given object ID, you can specify a translation value for Polish, another translation value for French, etc. Not all fields and objects are supported for value translations. For master data objects, the support for translations is limited and differs per client (due to historical or technical reasons). An example of this is with the names of items (materials). Check the supported object types in the SAP Help Portal.
The process to translate labels of standard fields is the web UI is as follows:
- From the drop-down list Language, select the entry System (show translation keys). The web page reloads and now shows the field translation keys instead of the field names.
- On the screen, locate the desired field and copy its translation key. For example, in the Planning and Dispatching app, the translation key for the Service Call list is Service Calls.
- Navigate to Admin → Company → Translations → Label Translations and choose Create.
- Select the target language, enter the translation key, and enter the desired custom label translation. For example, for English and the translation key Service Calls, enter the translation value Orders.
- From the drop-down list Language in the end user web UI, select the entry English. The web page reloads and now shows the new translation for the field we just created a translation for: Orders instead of Service Calls.
Translation Keys
Take note that for most fields, translation keys appear as a technical designations, delimited with underscores. Some fields however have translation keys that are very similar to their regular field names in English. If the translation key is not completely visible, it is possible to see the whole key by right-clicking and choosing inspect(or the equivalent feature in your browser). Titles of cards (groups of fields in screen configuration) are auto-capitalized. To see the correct cases of the key you can also use the right-click and choose inspect.
Creating Custom Translation Keys
In addition to overwriting standard translations contained in the applications, you may also create text snippets and their translations, which can then be used in business rules and notifications. In case the defined language does not exist for the key, the most frequently-used language will be used. In order to ensure there is always a fallback language, it is recommended to define the default language used in the company for each key. Check the SAP Help Portal for more details.
Detailed explanation: How to show translation keys by FSM client
The methods to show translation keys vary between the different FSM apps. The variations are listed below (check the SAP Help Portal for details):
- Web UI (excluding the admin module): From the Language dropdown in the user account/personal settings tab, select the System (show translation keys) option located at the bottom.
- Mobile apps - Android:
- Long-press anywhere on the login screen of the SAP Field Service Management for Android application (do not long-press on buttons or input fields).
- The application will display a view where you can enable the showing translation keys feature.
- Record the name of the key you wish to overwrite with a custom translation.
- When completed, you can then disable the feature again from the settings menu.
- Mobile apps - iOS:
- Sign into the SAP Field Service Management for iOS application.
- Navigate to the iOS Settings.
- Enable the Show translation keys toggle button.
- When you have found the key name you wish to overwrite with your own custom translation, shut down the app. When you log into the application the next time, the setting will be disabled.
- Mobile apps - Windows:
- From the Windows application, navigate to Settings → Application Settings .
- Check the Show Translation Keys checkbox.
- When completed, you can then disable the feature again from the settings menu.
- Customer Self Service:
- Log in to the Customer Self-Service Portal as a customer (with an end-customer login).
- Open the Developer Tools in the browser (this depends on your browser - Google Chrome or other Chromium-based browsers are recommended).
- Under the Application → Local Storage, find the cs.now.language key and manually enter the value xx-xx.
- Reload the browser. The translation keys will now be visible in the Portal.
- In a new tab, log in to the FSM Administration console, and maintain the desired translation.
- In the Developer Console, delete the value xx-xx that you previously entered for the key cs.now.language. Reload the browser, and the custom translation will now be visible.
Business Rules are pieces of custom logic, used to extend the FSM solution for customer specific cases. They run on top of the standard FSM logic. The standard FSM logic itself can not be changed.
A business rule consists of the following sections:
- Trigger: Event or scheduled
- Variables
- Conditions
- Actions
Business Rules can be triggered by certain events or run on a schedule. Some examples of business rules are as follows:
- Sending an SMS to the customer when the technician selects the workflow step like Accept, Travel, or Work.
- Automatically adding requirements (skills) to newly-created service calls that are of a specific type.
- Sending a Qualtrics survey e-mail at service checkout (the technician completes the activity).
- Generate a report when a smartform is completed.
- Assign a workflow to an activity upon release.
Note
Business rules are covered in more detail in the unit entitled "Developing Effective Business Rules".
