Oracle Field Service Cloud
What's New
  1. Update 19A
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Administration
        1. Extended Support for OpenID Connect
        2. Customer-Provided Coordinates in Pre-Calculation of Travel Time
    2. APIs
        1. Support for Parts Catalog REST API
        2. Support for ‘formSubmitted’ Event
        3. Enable Cross-Origin Resource Sharing (CORS) in REST API
    3. Core Application
        1. Improvements in Parts Catalog
        2. Support of Forms
        3. Date Picker and Barcode Scanner
        4. Landing Page: Improve Plug-Ins Presentation
        5. Disable Coordinates Gathering for Personal Activities
        6. Improved Calendars
    4. Plugin Framework
        1. Improved Navigation and Configuration for Plug-Ins
    5. Mobility
        1. Improve Routing on Mobility Design
        2. Find Nearby Resources and Broadcast a Message
        3. Improvements of Search Functionality in Oracle Field Service Cloud

Update 19A

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
01 MAR 2019

Improvements of Search Functionality in Oracle Field Service Cloud

Updated document. Delivered feature in update 19A.

22 FEB 2019

Support for Parts Catalog REST API

Updated document. Revised feature information.

22 FEB 2019

Support for ‘formSubmitted’ Event

Updated document. Revised feature information.

22 FEB 2019

Enable Cross-Origin Resource Sharing (CORS) in REST API

Updated document. Revised feature information.

31 JAN 2019

Improved Navigation and Configuration for Plug-Ins

Updated document. Revised feature information.

18 JAN 2019   Created initial document.

Overview

This guide outlines the information you need to know about new and improved functionality in Oracle Field Service Cloud, Update 19A. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you. For a listing of browsers supported by Oracle Field Service Cloud, log in to our support site and access Answer ID 8215.

Give Us Feedback

We welcome your comments and suggestions to improve the content. Please send us your feedback at  https://documentation.custhelp.com/ci/documents/detail/5/4/12.

Feature Summary

Action Required to Enable Feature

Feature

Automatically Available

End User Action Required

Administrator Action Required

Oracle Service Request Required

Administration

Extended Support for OpenID Connect

Customer-Provided Coordinates in Pre-Calculation of Travel Time

APIs

Support for Parts Catalog REST API

Support for ‘formSubmitted’ Event

Enable Cross-Origin Resource Sharing (CORS) in REST API

Core Application

Improvements in Parts Catalog

Support of Forms

Date Picker and Barcode Scanner

Landing Page: Improve Plug-Ins Presentation

Disable Coordinates Gathering for Personal Activities

Improved Calendars

Plugin Framework

Improved Navigation and Configuration for Plug-Ins

Mobility

Improve Routing on Mobility Design

Find Nearby Resources and Broadcast a Message

Improvements of Search Functionality in Oracle Field Service Cloud

Administration

Extended Support for OpenID Connect

Earlier, when you used OpenID Connect, you could select only Google as the provider. Starting with 19A, you can use various OpenID Connect providers to establish authentication. You can choose from Oracle Identity Cloud Service (IDCS), Microsoft Azure, Google, or other providers that follow the specification of OpenID Foundation.

To use OpenID Connect:

  1. Create or register Oracle Field Service Cloud as an application in your identity provider.
    1. Get the Configuration URL, Logout URL, Client ID, and Client secret from the identity provider. Further, define an attribute that will be used for the username.
  2. Create a Login Policy in Oracle Field Service Cloud that uses OpenID Connect.
    1. Click Configuration and then click Login Policies.
    2. Click Add New.
    3. In the Label field, add a label for the policy.
    4. Under Policy Name, provide a name for the policy in the appropriate language field.
    5. In the Authenticate Using field, select OpenID Connect.
    6. Complete the following fields:

Field

Description

Max sessions

The maximum number of simultaneous sessions allowed to the user.

Configuration URL

The Identity Provider URL to start authentication.

Logout URL

URL to which the user is redirected after logout. It may be the URL for logout from the Identity Provider. If this field is empty, then the logout settings of your users are controlled by the OpenID Connect provider.

Attribute containing

username

The name of the OpenID Connect attribute which the Identity Provider uses as the username (login name for Oracle Field Service Cloud). Choose one of these: 'email', 'name', 'given_name', and 'family_name'. Example: email

The attribute must have a unique value for each user.

Client ID

The value of the field containing data from the registered OpenID provider (for example, Client ID).

Client secret

The value of the field containing data from registered OpenID provider (for example, Client Secret).

  1. Click Save. The login policy with OpenID Connect is saved.
  1. In your OpenID application, configure a link back URL to https://login.etadirect.com/openid-connect-linkback. Your Identity Provider uses this link to redirect users to Oracle Field Service Cloud upon successful login.

MIGRATION OF EXISTING OPENID LOGIN POLICIES

After the Update 19A, OpenID login policy settings will remain same, you will not have to apply any changes to let your users continue to sign in to Oracle Field Service Cloud.

For this kind of login policies drop-down list containing 'Legacy (deprecated)' and 'Recommended' values will be displayed along with the 'OpenID Connect settings' section. 'Legacy (deprecated)' will be selected for all OpenID login policies created before upgrade.

We advice all customers to switch to recommended settings to get an advantage of new capabilities of integration with OpenID connect providers.

To do so you have to select 'Recommended' value from the drop-down list and populate correct end points into 'Configuration URL' and 'Attribute containing username' fields. Then to make integration work it will be required to change linkback URL in your OpenID application.

Steps to Enable

No steps are required to enable this feature.

Tips And Considerations

MIGRATING EXISTING OpenID CONNECT LOGIN POLICIES 

After you upgrade to 19A, your OpenID Connect login policy settings remain the same. A drop-down list with options 'Legacy (deprecated)' and ‘Recommended’ appears on the Edit Policy screen. The 'Legacy (deprecated)' option displays all the login policies that you have created before the upgrade. We advice our customers to switch to the recommended settings to take advantage of the new capabilities of integration with OpenID Connect providers.

To switch to the recommended values:

  1. Select 'Recommended' from the drop-down list.
  2. Enter the values in the 'Configuration URL' and 'Attribute containing username' fields.
  3. Change the link back URL in your OpenID Connect Identity Provider.

Key Resources

Customer-Provided Coordinates in Pre-Calculation of Travel Time

Currently, when pre-calculating the travel duration when an activity does not exist, only the pending activities with an accuracy value = 9 for the Address field are considered. With 19A, geo-coordinates that are provided by customers during the activity creation (with an accuracy value of zero) are considered as highly accurate and will be used for the pre-calculating travel time process. 

Similarly, coordinates with an accuracy level of 8 (intersection) will also are considered for pre-calculating travel time. Hence, all activities that have valid coordinates with an accuracy value of either 8, 9, or 0 are considered as valid inputs for the process. 

In addition, the Pre-Calculated Travel Statistics process has been updated to:

  • Provide estimates on 3,000 pairs
  • Travel Keys will be considered for estimation when they have at least 4 pending activities or 12 regular activities

Steps to Enable

No steps are required to enable this feature.

Key Resources

APIs

Support for Parts Catalog REST API

The Parts Catalog API supports RESTful operations (such as create, update, and delete items from existing catalogs), so that the catalog can be synchronized from an external data source using the Oracle Integration Cloud (OIC) adapter. You must grant permissions to the Parts Catalog API from the Configuration, Applications (API Access) screen.

The following set of operations are implemented in Parts Catalog API:

  • Create Catalog
  • Create Catalog item
  • Delete Catalog item

CREATE CATALOG

Use this operation to create a new catalog with the specified catalog label and with the specified language.

The following request parameters are supported:

  • Label—The catalog label when used in the request URL creates a new catalog with the specified label.
  • Language—The language code when used in the request URL creates a new catalog with the specified language code. 
  • fieldSchemas—The array of structures wherein each structure describes a catalog field.
  • name—The name of the catalog. This is a mandatory parameter.
  • typeSchemas—The array of structures wherein each structure describes an item type.

The 204 response is displayed if the operation is successful.

EXAMPLE

Request:

 PUT /catalogs/my_catalog/en/RG5-7691-250CN

{

     "type": "parts","type": "parts",

     "weight": 12,

     "fields": [

          {

                "label": "part_number",

                "value": "RG5-7691-250CN"

           },

          {

                "label": "vendor",

                "value": "HEWLETT PACKARD"

           },

          {

                "label": "descr",

                "value": "110V FUSER ASSEMBLY"

           },

          {

                "label": "price",

                "value": "943.80"

           }

      ],

     "tags": [

           "Printer",

           "Cartridge"

      ],

     "linkedItems": [

          {

                "itemLabel": "RG5-7691-250CN",

                "data": "1"

           },

          {

                "itemLabel": "RG5-7691-250CF",

                "data": "2"

           },

          {

                "itemLabel": "RG5-7691-250CZ",

                "data": "3"

           }

      ],

     "images": [

          {

                "imageURL": "http://www.storage-service.com/rg5_7691_250cz.png"

           },

          {

                "imageURL": "http://www.storage-service.com/rg5_7691_250cf.png"

           }

      ]

}

Response:

204 Response

Operation completed successfully

CREATE CATALOG ITEM

Use this operation to create or replace an existing catalog item with the specified catalog label, specified language, and the specified item label.

The following request parameters are supported:

  • Label: The catalog label when used in the request URL updates or creates a catalog item with the specified label.
  • Language: The language code when used in the request URL updates or creates a catalog item with the specified language code.
  • itemLabel: The item label when used in the request URL updates or creates a catalog item with the specified item label.
  • fields: The list of fields that allow you to filter data in your catalog. This is a mandatory parameter. 
  • type: The list of fields that allow you to define the type of data in your catalog. This is a mandatory parameter.  
  • tags: The list of item tags. This is an optional parameter. 
  • linkedItems: The list of linked items. This is an optional parameter.
  • Images: The list of images of an item. This is an optional parameter.

The 204 response is displayed if the operation is successful.

EXAMPLE

Request:

PUT /catalogs/my_catalog/en/RG5-7691-250CN

{

     "type": "parts",

     "weight": 12,

     "fields": [

          {

                "label": "part_number",

                "value": "RG5-7691-250CN"

           },

          {

                "label": "vendor",

                "value": "HEWLETT PACKARD"

           },

          {

                "label": "descr",

                "value": "110V FUSER ASSEMBLY"

           },

          {

                "label": "price",

                "value": "943.80"

           }

          ],

     "tags": [

                "Printer",

                "Cartridge"

      ],

     "linkedItems": [

             {

                "itemLabel": "RG5-7691-250CN",

                       "data": "1"

              },

             {

                "itemLabel": "RG5-7691-250CF",

                "data": "2"

              },

             {

                "itemLabel": "RG5-7691-250CZ",

                "data": "3"

              }

      ],

     "images": [

             {

                "imageURL": "http://www.storage-service.com/rg5_7691_250cz.png"

              },

             {

                "imageURL": "http://www.storage-service.com/rg5_7691_250cf.png"

              }

      ]

}

Response:

204 Response

Operation completed successfully

DELETE CATALOG ITEM

Use this operation to delete an existing catalog item with the specified catalog label, specified language, and the specified item label.

The following request parameters are supported:

  • Label: The catalog label when used in the request URL deletes a catalog item with the specified label.
  • Language: The language code when used in the request URL deletes a catalog item with the specified language code.
  • itemLabel: The item label when used in the request URL deletes a catalog item with the specified item label.

EXAMPLE

Request:

DELETE /rest/ofscPartsCatalog/v1/catalogs/{catalog}/{language}/{itemLabel}

Response:

204 Response

Operation completed successfully

Steps to Enable

You must grant permissions to the Parts Catalog API from the Configuration, Applications (API Access) screen. Since the Parts Catalog API is not related to a resource in Oracle Field Service Cloud (OFSC), you can ignore the Allow access only to certain resources parameter.

Key Resources

Support for ‘formSubmitted’ Event

Starting with 19A, a new Core API Event with type ‘formSubmitted’ is generated when a form is submitted. This event contains information about the form values and the entity values that are submitted with the form.

CREATE SUBSCRIPTION OPERATION

An integrated external system can subscribe for the formSubmitted event and receive all the submitted data of forms using the Create Subscription operation of the Event API. A subscriber can use the filterExpression option to specify form labels and create a separate subscription channel to receive the necessary data.

The monitorChanges parameter (if specified) does not influence the behavior and is ignored. You cannot change the snapshot of data generated when a form is submitted. The 'fields' parameter cannot be used.

The formSubmitted event contains all the information that was submitted.

GET EVENTS OPERATION

When a form is submitted in Oracle Field Service Cloud, it is registered as a formSubmitted event. The subscribers can subscribe to the event through the GET Events operation.

The GET Events operation contains the following attributes:

  • eventType—The type of the event. For example, the value 'formSubmitted' is used for the event when the form is submitted.
  • formSubmitId—The unique ID generated when a form is submitted.
  • formLabel—The label of the form.
  • time—The datetime in UTC when the form was submitted. For example, 2016-04-25 12:36:11.
  • user—The username of the user who submitted the form.
  • formDetails—The object that contains the submitted form field values. This is an optional parameter.
  • activityDetails—The object that contains the submitted activity field values. This is an optional parameter.
  • inventoryDetails—The object that contains the submitted inventory field values. This is an optional parameter.
  • resourceDetails—The object that contains the submitted resource field values. This is an optional parameter.
  • requestDetails—The object that contains the submitted service request field values. This is an optional parameter.

FILE CONTENT ACCESS

During form submission, the files can be recorded, and you can use the URL provided within the event body to access the content of files. The URL does not represent a standalone API operation and it should be used as provided.

API INTEGRATION FOR SERVICE REQUEST OBJECTS

The FormSubmitted event maintains backward compatibility with the service request operations.

If a control in the submitted form is associated to a service request field then a service request event is created to provide backward compatibility.

Also, the message scenario flow configured with the 'Manual' launch condition is also triggered.

EXAMPLE

{

     "eventType": "formSubmitted",

     "time": "2018-11-22 13:13:55",

     "user": "login",

     "formIdentifier": {

                "formSubmitId": "19",

                "formLabel": "form432_invoice"

             },

     "activityDetails": {

                "activityId": 4225430,

                "apptNumber": "appt_255_000_v1",

                "customerName": "John Doe",

                "startTime": "01:50 AM",

                "endTime": "02:15 AM",

                "House or Door photo": {

                          "filename": "Console.jpg, 26K",

                          "href": "https://api.etadirect.com/rest/ofscCore/v1/forms/19/activityFiles/House+or+Door+photo"

                            }

             },

     "formDetails": {

                          "some_form_element1": "value",

                          "some_form_element2": "value",

                          "form_signature_element": {

                                    "filename": "image.jpg, 26K",

                                    "href": "https://api.etadirect.com/rest/ofscCore/v1/forms/19/files/form_signature_element"

                                }

               }

}

Steps to Enable

No steps are required to enable this feature.

Key Resources

Enable Cross-Origin Resource Sharing (CORS) in REST API

Starting with 19A, you can set up a list of Cross-Origin Resource Sharing (CORS) domains from which the requests can be made to Oracle Field Service Cloud REST API. The following guidelines apply:

  • CORS requests that go directly to the customer's unique subdomain (for example, https://ofsc1q1q1q1.test.etadirect.com) are validated against this list. The requests are rejected if they fail CORS validation.
  • CORS requests that go to https://api.etadirect.com cannot be validated because the CORS check is done before we know the instance ID.

VALIDATION 

Validation of the domain names on the 'Configuration ? Applications' screen include the following processing rules:

  1. Each domain name should not be longer than 253 characters.
  2. Total number of items in the list should not exceed 100.
  3. The leading and trailing whitespace should be stripped from each domain, to fix invisible char errors.

Special value

The single asterisk char "*" can be used to specify that any domain is allowed. This value is by default assigned to all applications with upgrade from previous versions in order to maintain backward compatibility.

Wildcards (special characters within domain names) are not supported.

NOTE: The changes made to the list of domains need some time to be populated across the system, normally it should take from a few seconds to three minutes at max.

MIGRATION 

Existing integrations will not be impacted with the update. All applications will initially allow all requests to ensure backwards compatibility.  

REST API UPDATES 

The following set of operations in Metadata REST API are modified to handle CORS:

  • Create/Update application
    • Get application
    • Get applications

Create/Update Application 

The following request body parameter is supported.

allowedCorsDomains (optional):

You can specify the list of origin domains from which the requests can be made to Oracle Field Service Cloud REST API.

cURL command example:

curl -u 'clientId@instance:clientSecret' \

-X PUT \

--url https://api.etadirect.com/rest/ofscMetadata/v1/applications/test_app \

--data-binary '{

     "name": "test1",

     "status": "active",

     "tokenService": "ofsc",

     "resourcesToAllow": [

           {

               "resourceId":"resourceExternalId1",

               "resourceInternalId":12

            },

           {

               "resourceId":"resourceExternalId2",

               "resourceInternalId":123

            },

           {

               "resourceId":"resourceExternalId3",

               "resourceInternalId":127

            }

      ],

     "IPAddressesToAllow": [

               "10.321.112",

               "10.321.112"

            ],

     "allowedCorsDomains": [

               "https://best.customer.01.dot.com",

               "https://example.com"

            ]

       }'

Example of Response Header:

HTTP/1.1 200 OK

Content-Type: application/json; charset=utf-8

Example of Response Body:

{

     "label": "test_app",

     "name": "test1",

     "status": "active",

     "tokenService": "ofsc",

     "resourcesToAllow": [

          {

               "resourceId":"resourceExternalId1",

               "resourceInternalId":12

           },

          {

               "resourceId":"resourceExternalId2",

               "resourceInternalId":123

           },

          {

               "resourceId":"resourceExternalId3",

               "resourceInternalId":127

           }

      ],

     "IPAddressesToAllow": [

           "10.321.112",

           "10.321.112"

      ],

     "allowedCorsDomains": [

           "https://best.customer.01.dot.com ",

           "https://example.com"

      ],

     "links": [

          {

               "rel" : "canonical",

               "href" : "https://api.etadirect.com/rest/ofscMetadata/v1/application/test_app"

           },

          {

               "rel" : "apiAccess",

               "href" : "https://api.etadirect.com/rest/ofscMetadata/v1/application/test_app/apiAccess"

           }

      ]

}

Get Application 

The following response parameter is returned.

  • allowedCorsDomains (optional): The list of origin domains which are allowed to send requests to Oracle Field Service Cloud REST API.

Get Applications 

The following response parameter is returned.

  • allowedCorsDomains (optional): The list of origin domains which are allowed to send requests to Oracle Field Service Cloud REST API.

WHAT IS VALIDATED

For the REST API functions if there is a request header "Origin" present then it is compared with the configured list. The browser sends protocol, domain name and (optionally) port as the origin.

If there is a match found or if there is a special value "*" configured then the request is accepted.

For all API calls that fail CORS validation error 403 will be returned.

Steps to Enable

To configure the list of origin domains for CORS:

  1. Click Configuration, Applications, and then select Additional restrictions.
  2. Select the Allow cross-origin resource sharing (CORS) from the following web domains checkbox.
  3. Add the list of domains in the text box.
  4. Click Save.

Key Resources

Core Application

Improvements in Parts Catalog

Starting with 19A, the following improvements are implemented for Parts Catalog:

  • The Application screens configuration includes the new 'Parts details' context layout.
  • The Plugin API Framework includes a new entity “partsCatalogItem”.
  • The Parts Details screen includes more details for Field Resources.
  • Field Resources can find out the availability of an item with any of the nearby technicians. Sometimes, after resources start the work at a customer’s location, they may determine a need for few spare parts. In such cases, resources can broadcast a message other resources located nearby and find out whether they have those parts.
  • Plug-ins can be used to create business workflows related to parts. For example, order a part or find a part at nearby warehouses. 

PARTS DETAILS CONTEXT LAYOUT SCREEN

Now users of Core application, iOS and Android apps can run plugins or call the 'Find Nearby Inventory' from links in action bar. These links are available if configured on the 'Parts details' context layout. The Application screens section on the Screen configuration tab includes the new link, Parts details, as shown here:

Add Action Dialog

When you click the Part details link from the Application, the Part details screen is displayed.

In the Part details screen, click Add action link. The Add action dialog is displayed. Two type of actions can be configured for 'Parts details':

  • Link to the 'Find Nearby Inventory' standard action - the link calls the "Find Nearby Inventory' functionality and allows a user to identify nearby technicians that have desirable parts in their trucks and broadcast a message containing parts details to them.
  • Links to plugins - all type of plugins supported in Oracle Field Service Cloud can be opened from the 'Parts details' screen.

Add Action Dialog

PLUGIN API FRAMEWORK UPDATES 

It's possible now to open Plugins from Parts Catalog Item Details screen. A new entity "partsCatalogItem" will be used for "open" message, so with collections will be sent ID of Parts Catalog and ID of Parts Catalog Item.

New entity "partsCatalogItem"

Screen

Entity Field Value

Available Collections

Inventory Search -> Parts Catalog Item Details partsCatalogItem

resource activitiyList inventoryList partsCatalogItem

Entity data collections are as follows:

  • resource—An element in the resource tree representing a defined company asset
  • activity—An entity of the Oracle Field Service Cloud system that represents any time-consuming activity of the resource
  • activityList—Activity list
  • inventory—An equipment that can be installed or deinstalled during an activity
  • inventoryList—Inventory list
  • user—User who has currently logged in to Mobility and opened the Plugin
  • partsCatalogItem—Information that identifies the parts catalog item, so it can be retrieved via getParts procedure

Format of the "partsCatalogItem" field

Field

Example Value

Description

Mandatory

catalogId

17

A unique identifier of a catalog which contains the item.

Is returned by the getPartsCatalogsStructure procedure and is required by getParts procedure

Yes

itemId

979 A unique identifier of a part within a catalog. Is required by getParts procedure. Yes

Example of "open" message

{   

"apiVersion"

: 1,

    "method"

"open"

,

    

"entity"

"activity"

,   

"partsCatalogItem"

: {        

"catalogId"

: 2,     

"itemId"

: 117

},

"resource"

: { 

"pid"

: 5000038,       

"pname"

"RAYNER, Faye"

,        

"external_id"

"55038"

,

"gender"

"1"

},

"activityiList"

: {  

"3956534"

: {      

"WO_COMMENTS"

"AUTOMATIC TRANSFER WORK ORDER\n\n"

,        

"astatus"

"started"

,           

"aid"

: 3956534    

}

},

"inventoryList"

: {     

"20997919"

: {       

"invid"

: 20997919,      

"inv_aid"

: 3956534,     

"inv_pid"

: 5000038,     

"invpool"

"install"

,  

"invsn"

"SABDFWKNZ"

}

}

}

PARTS DETAILS SCREEN

The 'Parts details' screen was re-designed in provide users with access to more information including images, parts details and information on related parts (if provided). Here is an example:

The following were included in this update:

  1. Image for a Parts catalog item becomes a mandatory element on the screen. If a picture is not provided a Default picture will be shown. This is the Default Image:

  1. 'Linked items' section is renamed to 'Recommended'

FIND NEARBY INVENTORY

The Find Nearby Inventory link allows resources to identify nearby technicians that have the required parts in their trucks and broadcast a message containing parts details to them. For more details, see the Find Nearby Resources and Broadcast a Message section in this document.

Steps to Enable

The Application screens section on the Screen configuration tab includes the Parts details context layout. You must configure the context layout to access the Find Nearby Resources link.

Key Resources

Support of Forms

Earlier, when you had to use complex Forms that had to be completed by Field Resources, you would use Service Requests. The Service Request option helped you capture the information on a pre-configured screen and expose the information through an API or a Daily Extract report. 19A includes new Forms capability in the Core Application, iOS and Android apps, which is simple to configure and use.  This feature includes the following enhancements:

  • New Forms and Plugins screen that replaces the Action Management configuration screen.
  • Updated Visual Form Editor screen enables the configuration of a Form.
  • New Form Fields element allowing fields to be created for a specific Form, without requiring a custom property to be created.
  • A visual display on the Forms and Plugins screen that provides an overview of all the configured Forms and Plug-ins.
  • New 'Teamwork’ resource hierarchy visualization that helps you find and locate resources easily when creating teamwork in the GUI.
  • Plugins can be linked to directly from a User Type configuration screen without any need to add extra action links.
  • Separate Hints context layouts control the appearance of activity and resource hints on Core Application and the Legacy Manage screens.

The addition of this functionality will enable your operation to simplify:

  • screen configurations by supporting new elements that don't require pre-configured properties
  • ongoing system administration by managing forms in one location where changes can be made without having to go to each individual user type
  • the configuration of plugins by removing the need to configure additional action links

DEFINITION OF A 'FORM'

From a business perspective, Forms are paper documents that Field Resources fill in, while performing their work. From Oracle Field Service Cloud perspective, a Form is a pre-configured screen that can be configured using data elements that exist only in the context of a Form.

Forms are represented in three ways in Oracle Field Service Cloud:

  • A configuration screen where all the required elements are added.
  • A screen on a mobile device or a computer where technicians and dispatchers fill in data.
  • A submitted Form result that represents every sample of the completed Form. These results are available to users on separate screens and can be retrieved through APIs.

FEATURES OF FORMS

  • Administrators may create as many Forms as needed for the business.
  • Forms are not User Type specific; they are independent screens that are connected to User Types screens through links/buttons that are configured on a context layout.
  • The Form Field data elements, which can be added to Forms are not associated or “bound” to a specific field or custom property.
  • Forms are available only in Core Application, iOS and Android apps; they are not available in the Legacy Manage application.
  • Contents of a submitted Form cannot be changed, even if a related entity or Form configuration has changed. Put another way, the sumbitted Form cannot be changed but you can open the form, update the data and submit the form again.

LIFE CYCLE OF A FORM

The life cycle of a Form is as described here.

  1. A user opens a Form on a device.
    1. All screen elements, except those that have auto-calculated default values or values filled through predefined parameters are blank.
    2. Form elements bound to fields and properties inherit their values.
  2. The user fills in data and submits the Form.
  3. Data is stored:
    1. All submitted data is stored as a Form snapshot.
    2. Values of fields and properties bound to screen elements are populated and saved separately.
  4. Data is available to customers:
    1. On the user interface.
    2. In an event of Events API.
    3. As a service request, if conditions match.
  5. User goes to step1 if there is a need to fill the Form again.
    1. All Form field elements, except those that have auto-calculated default values or values filled through predefined parameters are blank.
    2. Form elements bound to fields and properties inherit actual values.

OTHER CHANGES IMPLEMENTED AS PART OF THIS FEATURE

Changes to Context Layouts - Hints and Views

Earlier, there were two layouts for hints--'Activity hint' and 'Resource hint'. These layouts controlled the appearance of hints on different screens, such as:

  • Shared context layouts defined appearance of hints in Dispatch console and over Resources tree in both Legacy Manage and Core Application.
  • 'Mobility' context layouts controlled representation of hints on other screens.

Now these layouts are transformed as follows:

  • Separate context layouts are available for hints on Core Application screens and Legacy Manage screens.
  • Shared contexts are removed from the list of Application screens.
  • Actions links from the shared contexts are copied to remaining context layouts.

Actions on hints are available within the Dispatch Console and Resource Tree, same as earlier.

Visible List Columns

The following changes are implemented for the Visible list columns context layout:

  • The 'Visible list columns' context layout, which defined the configuration for both Application screens and Legacy Manage, is no longer a shared context layout. Now the context layout that is located under the Application screens controls the columns of the List view in the Dispatch console for Core Application, iOS and Android apps.
  • The 'Visible list columns' context layout for Legacy Manage controls the columns of List view in the Dispatch console for Manage.

Team Work Screen Redesign

The Team Work screen is redesigned. Now when you click ‘Assists to’, a context menu appears and displays the hierarchy of the Resource Tree up to the specific technician that you can select as assisting. You can also search for a specific field resource. Search results will display all resources matching the search query, sorted in alphabetical order.

Assists to Pane

Assists to Pane Showing Search Results

Assists to Pane Showing List of Resources

Changes to the Visibility of Fields

The following changes are implemented to the visibility of fields:

  • Earlier, auto-generated and auto-calculated fields could be displayed on screens with ReadWrite or Mandatory visibility. However, these fields could not be updated from any of the interfaces. Now, to prevent unexpected system behavior and redundant synchronization conflicts, the application sets these fields as ReadOnly, regardless of the configured visibility. The fields will not be shown on 'add' screens such as 'Add activity' and 'Add inventory', as ReadOnly fields are not displayed on these types of screens. The list of the fields is described below:
Entity Field Description
ACTIVITY ETA  
INVENTORY inv_aid Activity Id
REQUIRED INVENTORY required_available_quantity Quantity in Resource Pool
RESOURCE alerts (always hidden)
SERVICE REQUEST appt_ident Activity
USER last_login  
  acoord_status Coordinate Status
  acoord_x  
  acoord_y  
  activity_alerts  
  activity_capacity_categories  
  activity_compliance  
  activity_workskills  
  aid Activity ID
  astatus Activity status
  atravelarea Travel Area
  atype Activity Type
  auto_routed_to_date  
  auto_routed_to_provider_id  
  auto_routed_to_provider_name  
  aworkzone Work Zone
  c_zid  
  date  
  delivery_window  
  end_time  
  eta_end_time  
  first_manual_operation  
  first_manual_operation_interface  
  first_manual_operation_user_id  
  first_manual_operation_user_login  
  first_manual_operation_user_name  
  service_window  
  time_delivered  
     
  inv_change_invid Changed Inventory ID
  inv_pid Resource Id
  invid Inventory Id
  invpool Inventory pool
     
  required_model Model
  required_quantity Quantity
  required_type Type
     
  srcreated Created
  srdate Date
  srid Request Id
  sr_aid Activity Id
  sr_invid Inventory Id
  sr_pid Resource Id
  sr_uid User Id
  uname    User
                
  calendar  
  oncall_calendar  
  pcapacity_bucket  
  pending  
  pid ID
  pinitial_ratio  
  p_rprid  
  queue_status  
  reactivated  
  resource_capacity_categories  
  resource_effective_workskills  
  resource_time_slots  
  resource_workskills  
  resource_workzones  
  skip_days_for_stats  
  total  
  pcolor (always hidden)
     
  last_password_change  
  login_attempts  
  login_blocked_to  
  main_resource_id  
  mobile_activity_count  
  mobile_inventory_count  
  mobile_provider_count  
  show_placeholder_id  
  sucreated  
  sustatus  
  suupdated  
  uid User ID
  • ReadOnly elements are now visible on former service requests screens that have been transformed to Forms. This applies to all the forms in the application.
  • The internal rules that controlled the visibility of links for Inventory service request, apart from the configured ones, are removed:
    • activity_status   in   started
    • day_status   not_in    past,future
    • inventory_pool    in    customer,install

Changes to the Navigation of Screens

Earlier, when service requests were submitted, users were navigated to the 'Requests history' screen. Now, when Forms are submitted, users are sent to the previous screen.

Transformation of Service Request Screens

The following context layouts from the User Types application screens are removed in 19A:

  • Add/View resource request
  • Send/View activity request
  • Add/View inventory request

Configuration of these context layouts has been transformed into Forms.

Legacy Manage: The “Identify service request by” context will only control service request identifiers in Legacy Manage. The structure of identifiers for Forms in the Core Application are persistent and cannot be configured.

Watch a Demo

Steps to Enable

The ability to add Forms is available by default, however, you have to create and configure the required Forms per your business needs.

PROVIDE ACCESS TO THE FORMS & PLUGINS SCREEN

Users with access to the Forms & Plugins screen can add and modify custom Forms and plug-ins. The Forms and Plugins icon is available on the Configuration screen.

Configuration Screen Showing Forms and Plugins Icon

To provide access to Forms & Plugins:

  1. Click Configuration, User Types.
  2. Select the type of user for which you want to provide access.
  3. Go to the Screen configuration tab.
  4. In the Main menu tree, click Configuration.
  5. Click Click to Add and select the Forms & Plugins check box.
  6. Click OK.
  7. Click Forms & Plugins and then click Add new visibility.
  8. Select Read-write and click Save.
  9. Click Close.

All the users of the selected User Type now have access to the Forms & Plugins screen.

Forms and Plugins Screen

CONFIGURE A FORM

To configure a Form:

  1. Create the Form.
  2. Configure the Form elements.
  3. Add the Form to an applicable user type’s screen context.

Create a Form

You should create a Form so that data can be captured for the appropriate corresponding entity.

  1. Click Configuration, Forms & Plugins.
  2. Click Add Form. The Add Form screen appears.
  3. In the English field, add a name for the Form in English.
  4. Add the names in other required languages.
  5. In the Label field, add a label for the Form.
  6. Click OK. The Form is saved. The next step is to add elements to the Form.

Configure the Form Elements

After you create a Form, you must add elements to it. Form elements are the fields that can display or capture data.

  1. Click Configuration, Forms & Plugins.
  2. Click the stack icon and click Modify content for the Form that you want to edit. The Visual Form Editor screen appears.
    • If you are configuring a screen and there is a button that is configured to open a Form, then you can use the "Modify Form content" option. In this case, a new editor session is opened with the specified Form content. Ensure that you have saved all the changes to the screen configuration before you click "Modify Form content".
  3. Click on the element you want to add, then drag and drop it where you want to add it to the Form. For example, add a section, a text box, an input element, a check box, or a file element, among others. Some of the new elements that you can add, which were not available in the earlier releases are:
    • Form Field: Adds a field such as text box, list, check box and so on, to the Form. This type of field exists on the Form only for presenting and gathering information. The data entered in Form fields will only be captured in a snapshot of the Form when the Form is Submitted, whereas data for other fields and properties will be captured and and stored in the database as normal..
    • Barcode/QR Scanner: Adds an icon to the Form, which allows users to scan barcodes/QR codes using the embedded scanning functionality (i.e. camera) on the resources mobile device. The results of the scan automatically populates the associated field. This option is available as part of the Input element. Before using this option, users must ensure that the Android and iOS app that is installed on their devices has access to the device’s camera. In the Core Application, the Barcode/QR scanner is displayed as a text box.
    • Date and Time: Adds a date, time, or date and time field to the Form. The date picker appears as an icon that the user can click on to select their preferred date/time.
    • Hidden value: Adds a field to: (1) Include calculated values, which are not required to be displayed when the Form is filled. (2) Include pre-populated values by open parameters. The values for these parameters are configured on the Form button. When the user opens the Form, these values are populated on the Form. (3) Use in other expressions, whose values will be included into the submitted Form data with the values of all other Form elements.
  4. In the Data binding section, bind the elements to appropriate entities and fields:
    • Click the pencil icon. The Bind visual element to data source screen appears.
    • Click the drop-down list and select the entity that defines the data source.
    • In the Data field list, select the specific field, which you want to associate with the selected element. If the Show only fields appropriate for element type check box is selected, only the fields that are appropriate for the selected entity and the element type are displayed. If the check box is not selected and you select a different type of field, the element type is changed accordingly. For example, if your element type is Date and Time and you select Activity ID [aid], then the element type is changed to Input field.
    • Click OK.
  5. In the Visibility section, configure the visibility settings. The visibility is Read-write (RW) by default.
    • To change the visibility, click Add new. In the Access mode section, select the required visibility.
    • If you want to add any conditions to make the element visible, click the plus icon.
    • Add the required condition and click Save.
  6. In the Translations sections, add the labels for the field in the required languages. The application adds a label by default and you can change it here. You can use this label in default expressions and in the visibility conditions of other Form items. Further, you can use this label to refer to the submitted values in APIs.

  1. Click Save on the Visual Form Editor screen. The Form is now ready to be added to a context layout through a User Type screen configuration.

Where Can Forms Be Used?

You can open Forms from the following screens:

  • Activity details and Inventory details: You can open Forms from the links in the action bar and buttons inside the content.
  • Activity list, Inventory list, Forms history, User options, Print route: You can call Forms from the links in the action bar.
  • Dispatch Console: You can open Forms from the links on the activity hint.
  • Screens containing the Resource Tree: You can call Forms from the links on the resource hint.
  • Time view, List view: You can add Forms to the action menu.

Forms relate to the entities from which they are opened and submitted. In other words, if a Form is submitted in the context of an activity, then it remains connected to the activity. Users can view Form submission results from this specific activity. The same idea applies to inventory and resources contexts.

Add the Form to a Screen

You add a Form to a context layout screen, so that field resources can open and fill it in.

  1. Click Configuration, User Types.
  2. Select the type of user for which you want to add the Form.
  3. Click Screen configuration.
  4. Find and click the screen to which you want to add the Form. The Visual Form Editor screen appears.
  5. Drag-and-drop the Button element to the section from where you want to invoke the Form.
  6. Click the button.
  7. In the Standard action screen field, click the pencil icon.
  8. Select Custom Forms.
  9. In the Screens list, select the name of the Form that you want to open and click OK. The label of the Form is displayed in the Custom Forms field. By default all Forms have a visibility of Read-only.

Visual Form Editor Showing Select Screen Dialog

  1. In the Visibility section, add the conditions based on which the Form is visible.
  2. In the Parameters section, add the values that you want the Form to be populated with:
    • Click Add new. The Add parameter screen appears.
    • Click Entity and select Form data. The Hidden value and Date and Time elements added to the Form appear in the Field name list.
    • Select an element in the Field name list.
    • In the Value field, add the value that you want to be populated for the element. For example, let’s say you have a field called ‘City’ and you want to populate it with a value of ‘New York’. Select ‘City’ from the File name list and enter ‘New York’ in the Value field. Whenever a field resource opens the Form, New York is populated for City.
    • Click Save.
  3. In the Translations section, add a name for the Form. This name is displayed on the screen from which the Form will be invoked.
  4. Click Save on the Visual Form Editor screen. The Form is added to the selected screen.

Call a Form from a Button or a Link

Apart from adding a link to a Form on a screen, you can add a link to open a Form from the activity hint. This serves as a shortcut to open the Form. Follow the procedure described in the ‘Add the Form to a Screen’ topic. You can configure the fields in the Form to populate values when Field Resources open the Form. You use the Parameters section of the Button configuration screen to pass the values that need to be populated. Further, using the Parameters section, you can also configure all the entities to populate values, although they are not present on the Form explicitly.

Example of a button configuration in Visual Form Editor:

Button Configuration

There are some screens that are configured using Context layout editor. Following is the button configuration example:

Button Configuration from Context Layout Editor

View Form Submission Results

The Forms history screen (Formerly 'Requests history') collects all the Form submission results. The Forms history screen for an activity gives all the Form submissions for the activity. Forms history screen for an inventory item provides all the Forms submitted for an inventory item. Similarly, Forms history available from the Activity list and User options provides a list of Form submission results for a specific resource.

  1. Click Forms history for an activity, an inventory, or a resource.
  2. Click any record. The specific form is displayed with the values that were entered at the time of submission. When a Form is submitted, the application stores a snapshot of the values that were entered. The snapshot data remains unchanged even if the corresponding entities and fields change later. In addition, except for the auto-calculated default values or values filled through predefined parameters, the remaining field values are erased. Further, every time a Form is submitted, a formSubmitted type of event is created. You can retrieve the details of individual submissions by subscribing to this event. See theREST API guide for more information.

Export and Import Forms

You export the contents of a Form, so that you can import it to create a similar Form.

  1. Click Configuration, Forms & Plugins.
  2. Find the Form that you want to export.
  3. Click the stack icon and then click Export.
  4. Click Save and save the file the required location.
  5. The Form is saved in .json format.
  6. To import a Form:
    1. Click Add Form and add the Form details.
    2. Click the stack icon and then click Import.
    3. On the Import form content dialog, click Browse and select a .json file. The file is validated and the contents of the Form are saved.

Tips And Considerations

SUPPORT FOR SERVICE REQUESTS

We will continue to support service requests as an entity for Forms. The way it works is: if any field or property that belongs to the service request entity is configured on the Form, a service request will be triggered in the application when the Form is submitted.

You can also send this service request through Outbound API using the notifications engine. You can use only the fields and properties that belong to service requests in message scenarios. The fields and properties can be used either as variables within messages or as blocking conditions.

Functionality of service requests for Legacy manage will work same as it used to be before upgrade.

IMPLEMENTATION ADVICE

To take advantage of Forms, customers are advised to use Core Application as well as iOS and Android apps. To simplify the configuration, we advise customers to create as many Forms as needed. Instead of configuring updates for existing screens, which might be complicated and risky, now customers have to just create a screen that represents a new Form and configure a link to the Form for the required user types. Having said that, we would also like to mention that as the data entered in Form fields cannot be changed or stored in the application, we advise customers to carefully consider when to use Form fields and when to use system fields and custom properties. With these new capabilities there is no longer a need to create a custom property for every data element in Oracle Field Service Cloud, instead Form fields can be used where appropriate for the integration.

Key Resources

Watch Support of Forms Readiness Training

Date Picker and Barcode Scanner

With 19A, the Forms functionality adds new data capture elements to Oracle Field Service Cloud.  Users of the Android and iOS Apps can use a barcode scanner to capture data in a form field or property. Users will also have access to capture date, time and/or date and time information using new visual components.

BARCODE ELEMENT 

NOTE: The Barcode scanner element and the Date and Time picker are not available on Screen Configuration - context layout screens.

To configure the barcode scanner for a Form:

  1. Click Configuration, Forms & Plugins.
  2. Click Add Form.
  3. Add the name of the form in English and other desired languages.
  4. In the Label field, add a label to the form.
  5. Click OK. The form is added to the Forms & Plugins screen.
  6. Click Modify content for the newly added form. The Visual Form Editor screen appears.
  7. Drag-and-drop the Input element.
  8. Click the Input element. The form element screen appears.
  9. Click the pencil icon at the Form field text box and then select the Barcode/QR scanner check box.

  1. Click Save. The barcode scanner element is added to the selected form.

NOTE: Before users can scan barcodes, users must ensure that the Android and iOS app installed on their devices has access to the device’s camera. When a users accesses the system using the Core Application via web browser (not via an installed app), the Barcode/QR scanner field will be displayed as a text input box with no ability to scan a code.

How to use:

There is the icon on the right of the element which indicates that a scanner can be initiated.

When the icon is clicked, the barcode/QR code scanning application will be invoked and automatically populate results of scanning into the field.  It is also possible to manually add data into the field and save it.

DATE/TIME PICKER ELEMENTS 

There is a specific 'Date and Time' element available in the Forms configuration. There are 3 options available:

  • Date picker
  • Time picker
  • Date and Time picker

To configure the date, time or date and time picker:

  1. Click Configuration, Forms & Plugins.
  2. Click Add Form.
  3. Add the name of the form in English and other desired languages.
  4. In the Label field, add a label to the form.
  5. Click OK. The form is added to the Forms & Plugins screen.
  6. Click Modify content for the newly added form. The Visual Form Editor screen appears.
  7. Search for the Date and Time element and add it to the form.
  8. Click the Type drop-down list and chose one of the three elements:
    • Date and Time picker: Populates both date and time
    • Date picker: Populates only date
    • Time picker: Populates only time

  1. In the Visibility section, add the visibility to the element.
  2. In the Translations section, add a label to the element.
  3. Click Save. The element is added to the form.

NOTE: The format of data in 'Date/Time' pickers is controlled by user settings. Specifically 'Time' (sudate_fid) and 'Date' (sudate_fid) user fields.

How to use:

Date -  'Date and Time' will be presented on Forms as a date picker visual component if corresponding type was selected for this element in configuration.There is the icon along the field that visually distinguish it from other fields. By clicking the icon a calendar with current date selected pops-up.

Users are able to select a specific date from the calendar and it will be populated into the field. By clicking 'Today' users will be navigated to a current date which will be automatically chosen. It's also possible to manually specify desired date into the field.

On the screen the date will be displayed in the format configured for a user.

Time - If corresponding type for 'Date and Time' is selected the element will be showed as a time picker widget marked by a special icon. By clicking the icon a time picker component pre-populated with current time on device pops-up.

Users are able to select a specific time from the calendar and it will be populated into the field. Another option is to manually type time into the field if needed.

On the screen selected time will be displayed in the user format.

Date and time - In accordance with configured type the 'Date and Time' element will be displayed as a DateTime visual component. This component is a combination of 'Date' and 'Time' pickers which lets users to populate both date and time into the one field.

All the rules defined for 'Date' and 'Time' widgets are applicable to this component.

Integration tips - Data captured from 'Date', 'Time', and 'DateTime' components is stored and exposed via 'formSubmitted' event of Events API in pre-defined format. There is:

  • yyyy-mm-dd for 'Date'
  • HH:mm for 'Time'
  • yyyy-mm-dd HH:mm for 'DateTime'

Integrators are advised to convert data in other formats if required.

Steps to Enable

The ability to add date and time elements and barcode scanner is are available by default. However, these elements must be added to the required context layout, before users can use them.

Tips And Considerations

Data captured from 'Date', 'Time', and 'DateTime' components is stored and exposed through the 'formSubmitted' event of the Events API in a predefined format. There is:

  • yyyy-mm-dd for 'Date'
  • HH:mm for 'Time'
  • yyyy-mm-dd HH:mm for 'DateTime'

Integrators are advised to convert the data in other formats, if required.

Key Resources

Landing Page: Improve Plug-Ins Presentation

Starting with 19A, new options are available in the Plug-in Framework to support tile presentation on the Landing Page.  

It is now possible to set an icon, additional text for the plug-in tile and highlight the tile. 

These additions could be used to:

  1. Call a users attention to an existing plug-in by presenting additional information on the Landing Page tile 
  2. Build an interactive dashboard through the development of new plug-ins. Here are some examples:
    • reminders about actions required from technician - vehicle maintenance
    • business KPIs - customer satisfaction
    • gamification elements - scoreboard position
    • warning messages - weather or area hazards

Plugin Tile Examples

A new parameter iconData is available for "close", "initEnd" and "sleep" Plug-in API messages. It is used to update the plug-in tile on the Landing Page:

  • status text - up to 3 alphanumeric characters are displayed
  • icon - image in svg or png format. Max 64 KB file size is allowed. Recommended icon size is 64 x 64 pixels.
  • color - 'default' or 'highlighted'

To use this functionality it is required that Landing Page is enabled (parameter 'Field Resource Landing Page' on Configuration >> Display >> Mobile settings is set to Dashboard).

CHANGES IN PLUG-IN API

The new parameter iconData is avalable for "close", "initEnd" and "sleep" messages, which can be used to update the data, that is shown on the plugin's tile on the Landing Page: status text, icon image and color.

The data can also be updated on "sleep" message, plugin is able to show the status of the synchronization, e.g. by showing the number of pending actions and by changing the icon when all the data is successfully sent to the server.

The data is applied in live mode, i.e. if the plugin's been woken up while the user is on Landing page, the icon is updated immediately after plugin's sent the iconData in a "sleep" message.

iconData format:

Field

Type

Limits

Description

color String

One of:

  • "default"
  • "highlight"
If value is set to "highlight", the Plugin's tile on the Landing page changes its color to get the user's attention
image Blob
  • Max size: 64 KiB
  • Allowed types:
    • image/svg+xml
    • image/png

Icon picture.

It's recommended to use a scalable monochrome white icon in SVG format.

In case of bitmap picture in PNG format it should be not smaller than 64x64 px.

text String Max length: 3 chars The short text that is shown as large title on the plugin's tile. May contain both letters and digits.

Example of sending of 'close' message

var

 

closeData = {

    

"apiVersion"

: 1,

    

"method"

"close"

,

    

"iconData"

: {

        

"color"

"highlight"

,

        

"text"

"117"

,

        

"image"

new

 

Blob([

            

'<?xml version="1.0"?>'

 

+

            

'<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" viewBox="0 0 64 64">'

 

+

                

'<rect x="16" y="16" width="32" height="32" fill="#fff" />'

 

+

            

'</svg>'

        

], { type: 

'image/svg+xml'

 

});

    

}

}

window.parent.postMessage(closeData, origin);

Steps to Enable

No steps are required to enable this feature.

Key Resources

Disable Coordinates Gathering for Personal Activities

Starting with 19A, a new privacy feature is available, where you can disable location tracking by activity type.

When a user has an activity in ‘Started’ status, the user’s location details are not gathered in the application. A message “Your location is not tracked for this activity” appears on the landing page.

The location tracking resumes only after the activity status changes and route is still activated.

This functionality is supported the browser and installed applications (Android and iOS) and requires Oracle Field Service Smart Location, Oracle Field Service Professional Cloud Service or Oracle Field Service Enterprise Cloud Service.

Disable Location Tracking Message

Steps to Enable

  1. Click Configuration, Activity Types.
  2. In the Activity Types screen, navigate to the activity type.
  3. Select the activity type and click Modify to open the Modify Activity Type dialog.
  4. Under Features, clear the Disable resource tracking for this activity type field and click Update.

Improved Calendars

With 19A, the following improvements have been made to calendars in the Core Application and Mobility:

  • Resource Landing Page: A date picker is added.
  • Resource info and Resource calendar screens: Additional information about working days and shifts are displayed.

The new calendar panel added to the Resource Dashboard appears after clicking the date field on top right corner (highlighted blue box in the screenshot below) of the screen. The Landing page reloads whenever the user switches a date on the Calendar.

Date Picker

The information related to On-call, Workload, and Non-working day will be available for the future dates on both Landing Page and Mobile applications.  

  1. On-call - icon is displayed if the resource has an On-call shift scheduled for that specific day.
  2. Workload - a dot is displayed if the resource has at least one activity schedule for specific date. Note that mass-repeating activities are not included in the workload unless a regular activity has been added to the route for that day in the future.
  3. Non-working day - day is shown as grey.

Information is updated no sooner than once every 10 minutes.

RESOURCE CALENDARS

Also, the Resource Calendar on Resource Info and Resource Calendars screens display additional information about working days and shifts.

  1. Working days are colored with blue
  2. Non-working days have white background
  3. Workload has a dot displayed for the date if there is any activity except mass-repeating for that day
  4. On-call icon is displayed if there is On-call shift for this day

This information is available for current and future days.

Resource Calendar

Resource Info

Steps to Enable

No steps are required to enable this feature.

Key Resources

Plugin Framework

Improved Navigation and Configuration for Plug-Ins

Earlier, when you had several plug-ins that used significantly different sets of data, you could not separate the data that had to be sent to each plug-in. As a result, all the plug-ins received all the data. With 19A, each plug-in can have its own configured fields, independent of other plug-ins in Oracle Field Service Cloud. You can also specify which plug-in must be opened after closing the current one, so that the navigation flow between plug-ins is set.

The Plug-in API section on the Screen configuration screen, where you configured the properties that were visible for plug-ins is available until you migrate all the plug-ins to the new Forms & Plugins screen. After that, the section will be removed. The Action Management screen, where you configured plug-ins is not available anymore. Instead, the new Forms and Plug-ins screen, that can be accessed from the Configuration screen provides the ability to configure all the details for plug-ins. Further, the new Add plugin screen does not include any tabs.

With the new Forms and Plug-ins screen, you can:

  • Configure the data required for each plug-in individually.
  • Configure the available properties for each plug-in.
  • Mark a plug-in as Hosted and upload the files with the plug-in.
  • Export and import individual plug-ins or all plug-ins.

CHANGES TO FORMS AND PLUGINS SCREEN

  • New section Available properties shows on Add/Modify plug-in screen.

Add Plug-Ins Screen with Available Properties Section

  • A message providing suggestions to switch to a new approach is displayed to those who have Plug-in API context configuration for at least one user type.

NOTE: The Plugin API section does not appear on the User Types screen if there are no Internal plug-ins or plug-ins that use Plug-in API before upgrade to 19A.

Steps to Enable

You can configure each plug-In separately; the plug-in will be independent of other plug-Ins available in the application. You can export or import settings for any particular plug-in.

CONFIGURE PROPERTIES FOR A PLUG-IN

NOTE: Newly created Plug-ins cannot use Plug-in API contexts.

  1. Click Configuration, Forms & Plugins.
  2. In the Forms & Plugins screen, click Add Plug-in. The Add Plug-in screen is displayed.
  3. Select the Use Plug-in API check box. The Add Plug-in screen displays the Available Properties section.
  4. In the Available Properties section, click the pencil icon. The Property selection dialog is displayed.
  5. In the Search box, type the name of a property to quickly find that property.

Property Selection Dialog

  1. Click the Show configured properties for this plug-in check box to filter properties that are already available to the plug-in.
  2. Select the check boxes corresponding to the properties to add and click OK. The Available Properties section shows the properties grouped by entities and sorted alphabetically.
  3. Click Save to save the configuration.

The following fields can be configured using the Add/Modify plug-in screen:

Activity Resource Inventory

acoord_status

acoord_x

acoord_y

activity_workskills

aid

appt_number

astatus

atime_of_assignment

atime_of_booking

atype

aworktype

c_zid

caddress

ccell

ccity

cemail

clanguage

cmessagetime

cname

cphone

cstate

customer_number

czip

delivery_window

end_time

ETA

length

position_in_route

service_window

sla_window_end

sla_window_start

time_slot

travel

email

external_id

pactive

pdate_fid

pid

planguage

pname

pphone

ptime_fid

ptype

time_zone

inv_aid

inv_change_invid

inv_pid

invid

invpool

invsn

invtype

quantity

START A NEW APPROACH FOR ALREADY CONFIGURED PLUG-INS

To switch to a new approach, you should copy the existing configuration into a plug-in. After moving all existing configuration from Plugin API contexts to the Modify plugin screen, you can use the Modify plugin screen to configure plug-in properties if needed.

To copy the existing configuration:

  1. Click Configuration, Forms & Plugins.
  2. In the Forms & Plugins screen, click the properties icon corresponding to a plug-in and select Modify. The Modify Plug-in screen is displayed.

Properties Menu Showing Modify Action

  1. In the Modify plugin screen, select the Use Plug-in API check box. The Add Plug-in screen displays the Available Properties section.
  2. In the Available Properties section, click the pencil icon. The Property selection dialog is displayed.
  3. In the Search box, type the name of a property to quickly find that property.
  4. Click the Show configured properties for this plug-in check box to filter properties that are already available to the plug-in.
  5. Select the check boxes corresponding to the properties to add and click OK. The Available Properties section shows the properties grouped by entities and sorted alphabetically.
  6. Select User type in the drop down list from which you want to copy configured properties ("Configure Properties" button will be available on the screen if at least one User type has configured property on the Plugin API contexts in previous versions)
  7. All previously configured properties will be copied from Plug-in API contexts without visibility rules and appear in the section Available Properties.
  8. Click Save to save your changes. 

NOTE: Your plugin will not use the Plugin API contexts; it will use the configuration from the new screen. Once saved, plug-ins cannot be switched back to using of context layouts.

EXPORT OR IMPORT PROPERTIES AND SECURE PARAMETERS

You can use Export ior Import functionality on the Forms & Plugins screen to download and upload the configuration of the plug-in. Secure parameter values cannot be exported, but they can be imported if needed.

To export the existing configuration:

  1. In the Forms & Plugins screen, click Export Plug-ins. The Save as dialog is displayed.
  2. The configuration of the selected plug-in is exported as an XML file. 
  3. The exported XML file will also contain configured Properties and Secure parameters.

Keys of configured secure parameters will be exported without value.

XML FILE EXAMPLE

Following is an example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<root>

<format version="1"/>

<product version="17.2.0"/>

<plugins>

<plugin label="An Addon" action_label="" type="addon">

<translations>

<translation lang="en" val="An Addon En"/>

</translations>

<fields>

<field label="customer_number" entity="appt"/>

<field label="inv_aid" entity="inventory"/>

<field label="customer_number" entity="provider"/>

</fields>

<secured_params>

<secured_param name="parameter1" value="val1"/>

<secured_param name="parameter2"/>

</secured_params>

<plugin_data>

<plugin_data_item path="https://google.com/" post_data="" width="" height="" options="32" user_agent_mask="" sort_order="0" native_app_label="" auth_type="basic" auth_login=""/>

</plugin_data>

</plugin>

</plugins>

</root>

To import a plug-in configuration:

  1. In the Forms & Plugins screen, click Import Plug-ins. The Import dialog is displayed.
  2. Browse and select the XML file you want to import.  
  3. A new row appears displaying the details of the imported configuration.

Key Resources

Watch Support of Forms Readiness Training

Mobility

Improve Routing on Mobility Design

With 19A, the look and feel of the Routing screen tabs have been improved to allow improve usability across all devices, especially when using smaller devices such as mobile phones and for all screen sizes.

You can create, modify, and start routing plans, set baselines, and review the routing results from any device supported by Oracle Field Service Cloud.

The Routing screens are now easy to use on all the devices supported by Oracle Field Service Cloud, compatible with different screen sizes including mobile phones.

The following sections discuss how the Routing screen tabs appear on devices with different display sizes.

DISPLAY ON WEB BROWSERS

The following images display the Routing Plan, Routing Execution, Savings, and Results tabs in a web browser:

Routing Plans Tab on the Routing Screen

Routing Execution Tab on the Routing Screen

Routing Savings Tab on the Routing Screen

Routing Results on the Routing Screen

DISPLAY ON DEVICES WITH MEDIUM SCREEN SIZE

The following images display the Routing Plan, Routing Execution, Savings and Results tabs in devices with medium screen size:

Routing Plans Tab on the Routing Screen

Routing Execution Tab on the Routing Screen

Savings Tab on the Routing Screen

Routing Results Tab on the Routing Screen

DISPLAY ON MOBILE DEVICES OR DEVICES WITH SMALL SCREEN SIZE

The following images display the Routing Plan, Routing Execution, Savings, and Results tabs in mobile devices:

Routing Plans Tab on the Routing Screen

Routing Execution Tab on the Routing Screen

Routing Savings Tab on the Routing Screen

Routing Results Tab on the Routing Screen

Steps to Enable

No steps are required to enable this feature.

Key Resources

Find Nearby Resources and Broadcast a Message

With 19A, resources (Technicians) can find and locate other resources (Technicians) who have a specific parts available in their truck and invoke broadcast request for sharing inventory.

It is important for Technicians to have availability of correct parts finish a specific job. In case of lack of correct parts, Technicians can find and share such parts from nearby Technicians in the same location. This helps in making use of available inventories and reduces the need for unnecessary ordering of parts. In addition, Technicians can complete their job as per schedule without rescheduling the task to another day and waiting for the inventory, thereby showing increased efficiency.

You can perform the following:

  • Configure the Part details dialog
  • Search inventory/parts from the Parts Catalog
  • Search the details about an inventory/part in the Parts Catalog

You must first add the 'Parts details' context layout in the Application screens page.

Steps to Enable

To display a link to the plug-in on the Parts Details screen, you must configure the context layout of the Parts details screen.

Prerequisite: The plug-in is added on the Forms & Plugins screen and configured.

To configure the Part details context layout:

  1. Click Configuration, User Types.
  2. In the User Types screen, select the Screen configuration tab.
  3. In the Application screens section, click Parts details. The Parts details context layout screen appears.
  4. Under Action, click Click to Add to open the Add action dialog.

Add Action Dialog

  1. To add the Find Nearby Inventory action item, select the Find Nearby Inventory check box and click OK.

  2. In the Part details dialog, select the Find Nearby Inventory action item. A set of options are displayed below the action item.

Part Details Context Layout Options

  1. To change the visibility, click Modify corresponding to the action.
  2. In the Add new visibility dialog, click the check box next to the visibility and click Save.
  3. Click Close.

To add a plug-in to the Parts details screen:

  1. Click Configuration, User Types.
  2. Go to the Screen Configuration tab and click Parts details.
  3. Select the Plug-ins option. The list of plug-ins that you have added on the Forms and Plug-ins screen appear in the Available section.
  4. Select the required plug-in and then click OK.
  5. On the Parts details context layout screen, select the newly added plug-in.
  6. Click Add new visibility. The [<plug-in name>] visibility screen appears, with the Read-only option selected.
  7. Click Save.
  8. Click Close.

To search inventory and broadcast a message to nearby Resources:

NOTE: The Find Nearby Inventory tab will be active only for those resources who are online and when the location attributes are available for that resource.

  1. Open the search box and type the name of the part to search. The Parts Catalog displays a list of inventories that match the searched keyword.

Parts Catalog Search

  1. Click the required inventory to search.

The Parts details screen appears.

Part Details Dialog

  1. Click the Find Nearby Inventory tab. The Find Nearby link will be active ONLY if the following conditions are true:
  • Company has Smart Collaboration and Smart Location
  • User type of corresponding user has Collaboration enabled.
  • User location is available
  • User is online
  1. After searching for the selected item, the application displays a list of Field Resources in the nearby locations with real time travel duration for those resources.

The Find Nearby Inventory tab shows the number of users who hold this inventory within 50 miles distance from the resource. The distance is based on the configuration of Distance provided in the Business Rules screen.

Find Nearby Inventory Dialog

The Find Nearby Inventory tab will display the travel duration only if the following conditions are true:

  • Customer has Field Service Enterprise SKU and Maps and Geocoding Provider
  • Customer has purchased Google Add-on.
  • Enable Real Time Traffic check box is enabled in the User Types page
  1. Select all the check boxes corresponding to those resources who have the required inventory.

  2. Click Start Chat to invoke a broadcast message.  The Broadcast chat window is displayed.

Broadcast Chat Window

  1. Type a broadcast message requesting to share the inventory and click the Play icon.

The message will be sent to all selected resources simultaneously.

Broadcast Message

  1. Resources who have enough inventory with them can collaborate and share the inventory to finish the job. 

Key Resources

Improvements of Search Functionality in Oracle Field Service Cloud

Starting 19A, the new search in Oracle Field Service Cloud allows users to perform the following tasks:

  • Search for an activity, an inventory or parts
  • Search in Offline Mode
  • Set search preferences
  • View the last five recent searches
  • Navigate the search

SEARCH FOR AN ACTIVITY / AN INVENTORY / PARTS

Users can search for an activity, an inventory, or parts using the new Search feature.

 

Search Box

The user needs to enter at least three characters of the word or numerical value in the Search box. These three characters will be matched with all the inventory pools associated with the resource and the relative search results are displayed:

  • Search by inventories will perform a search based on a technician's route.
  • A user who manages multiple users (Supervisor) cannot search inventories or parts from the Manage view (Supervisor view).
  • Search by Activities will perform a search for all activities to which the user has access.
  • Search by Parts will perform a search by all Parts catalog.

SEARCH IN OFFLINE MODE

The user can search for parts and inventory in offline mode. However, this feature cannot search for activities in offline mode.

Search in Offline Mode

SET SEARCH PREFERENCES

The user can set search preferences using the Search Preferences option present under the Search box.

Set Search Preferences

This option helps the user to perform the following activities:

  • select one or more preferences from the displayed list
  • change the priority of the preferences from the list using the drag and drop feature
  • select a particular date to view the search results of a related activity 

RECENT SEARCH

The user can view the last five recent searches in Search box.

Search Box Showing Recent Searches

NAVIGATE A SEARCH

When a user searches for an item from Activity, Inventory, or Parts Catalog, the relative results appear on the screen. If the user opens search from Landing page, searches for Activity details and clicks the Back button, the user is navigated back to the Landing page. Similarly, if the user opens search from Manage screen and searches for Activity details, Inventory details, etc. and clicks the Back button, the user is navigated back to the Manage screen.

COLLABORATION USER INTERFACE CHANGES

The user can search for a contact or a conversation from the Collaboration window. When the user searches for active conversations and conference chats, the Collaboration window appears as follows:

Collaboration Window

When the user searches for a one-one conversation from the Collaboration window, it appears as follows:

Collaboration Window Showing One-One Conversation

Similarly, the user can also search for the Conference, Helpdesk messages, Helpdesk conversation, and Contacts from the Collaboration window.

Steps to Enable

No steps are required to enable this feature.

Key Resources