Adobe Captivate



Slide 3 - Oracle Field Service Cloud

[pic]

Slide notes

Hello, my name is Erik. Welcome to training for Oracle Field Service Cloud, Release 19A.

If you’re like most OFSC customers, there’s a good chance that you require your field resources to complete some types of forms during their workday. Work authorization forms, invoices, or inspection results are a few examples, and as you can imagine, some of can even become fairly complex.

In earlier versions of OFSC, screen configurations and service requests were used to accomplish many of those types of tasks. In this session, we’ll be talking about the new ‘Support of Forms’ feature, which takes this functionality to a whole new level by significantly simplifying the configuration process and providing increased flexibility to accommodate even more unique use cases.

Notes

| |

| |

| |

| |

| |

| |

Slide 4 - Agenda

[pic]

Slide notes

‘Support of Forms’ represents a pretty significant feature, and it includes a number of additional related enhancements – all part of our ongoing effort to improve the overall user experience and OFSC performance of the OFSC Core Application. Within this video, we’ll provide you with an overview of each enhancement, followed by additional details including how you can use them and the business value they offer. We’ll also provide you with demonstrations of some of the key components and explain important considerations in terms of how to configure and implement them.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 5 - Enhancements Overview

[pic]

Slide notes

As I mentioned, there are quite a few individual enhancements that either make up or are a result of the overall Support of Forms feature, starting with…

• The new “Forms & Plugins” configuration screen, which is where you can create and manage plugins and forms, including service requests.

• The Visual Form Editor has also been significantly improved overall to streamline the way you add fields, properties, and action buttons to screens.

• And finally, true to the name of the screen, the 19A release introduces the concept of Forms themselves, which are essentially the digital equivalents of paper forms that a field resource would use to record information. In addition to very customer-specific for requirements, these also represents how and where service requests are configured and managed. And you’ll also find that a few very helpful new elements are available to configure within forms.

Now let’s go through each of these in a bit more detail. You’ll see that these enhancements are not mutually exclusive – they kind of all tie together.

Notes

| |

| |

| |

| |

| |

| |

Slide 6 - Forms & Plugins Configuration Screen

[pic]

Slide notes

So first up, we have the new “Forms & Plugins” screen, which is accessible through the OFSC Configuration page, and it is here that all of the plugins and forms that have been configured for your environment will be displayed.

From this screen, you can create new forms and plugins and modify any existing ones – including service requests, which are supported as a type of form – all using the updated Visual Form Editor.

You can also import and export plugins and forms from this screen as needed.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 7 - Forms & Plugins Configuration Screen

[pic]

Slide notes

With this new configuration area in place, it serves as a central point in OFSC for easily and intuitively managing any plugins and forms that are part of your field service business. And, as I’ll explain shortly, because of improvements to the way actions are now managed within forms and screen contexts, the Action Management configuration screen has been removed.

 

So just think of this screen like the gateway to creating and managing your plugins and forms, including any service request-related ones.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 8 - Visual Form Editor Improvements

[pic]

Slide notes

As part of the ‘Support of Forms’ feature, there have been several enhancements to the Visual Form Editor that make it even easier to configure screen contexts. Some of the changes affect any screen contexts that use the VFE for configuration, and some are just for use within the new Forms feature.

In general though, this new version of the Visual Form Editor streamlines the configuration process by listing a concise menu of configuration elements that you can just click and drag to where it needs to be within your context layout. Then, for any sort of input or other data element, you can identify the data source the element should be bound to. That could be as simple as selecting a system field or custom property, or maybe even, if you’re configuring a Form, a form field.

 

The enhanced VFE lists elements intuitively based on their functionality. Sections and Tabs help you set up the layout structure of a form or context, as will Text if there’s something you want to draw attention to. Input elements equate to String properties, which can consist of some alphanumeric value like a free text entry, or a URL, phone number or email. Geolocation elements get their own entry on the element list. An Integer property would fall under a Checkbox element or an Input element depending on the format. Enumeration properties – comboboxes, dropdown menus, or radio groups, are considered to be List elements. And for File properties you would choose based on the appropriate component type – so an Image, Signature or File element. The Hidden Value Element is new and can hold a value or expression. It can be used for calculating a value which doesn’t need to be displayed and can also be pre-populated by set parameters. And the Date and Time element will use the “Date Picker” functionality to allow for easy selection of a Date, Time, or both.

 

So if you have a form context where the corresponding entity has potentially a lot of associated attributes, the new-look VFE will provide a much leaner and cleaner UI for configuring the contexts the way you need them, and it’ll also support some of the new elements found exclusively in Forms.

 

I also need to point out that actions have also been simplified by providing the ability to configure them within a single screen. Now any form, service request or plugin that is created, can be linked to through a button element directly within a given context. Configuring and managing separate actions for each plugin is no longer necessary, so between that and the advent of the new Forms and Plugins screen, you’ll find that the Action Management screen has been removed from OFSC.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 9 - Visual Form Editor Improvements

[pic]

Slide notes

So what business value do the Visual Form Editor enhancements provide?

Faster, more intuitive screen configurations due to the new Visual Form Editor structure is one.

Simpler management of how actions are configured within contexts is another. This too will make context and form configurations much more efficient, requiring less navigation between different screens.

And finally, the Visual Form Editor enhancements support a few new elements that are for use exclusively within forms. These new elements will be described in detail in the next section of this video.

Ok, now for the main event in this TOI video…

Notes

| |

| |

| |

| |

| |

| |

Slide 10 - Forms

[pic]

Slide notes

Now we’re onto Forms themselves… In practice, a ‘Form’ is like the digital equivalent of a paper form a field resource would use to record information. Typically, they are simple screens designed to capture and submit data, although they can be as complex as dictated by your business needs.

In OFSC, the ability to effectively create a form of sorts by configuring a particular screen context with the necessary system fields and custom properties to capture the required data is not new, and you may find that that meets some of your needs just fine. With the new forms feature though, there are some very distinct differences that might make more sense for you.

The first difference you’ll find with forms is that they are independent of user types. Once a form is configured and an action that calls it is added to a screen context, the form will appear as configured to all users, capturing the same data. Kind of like how standard paper forms work – very consistent. They are easy to configure, while still being extremely flexible. And equally important - when changes to them are necessary, you don’t have to remember to make the same screen changes correctly for each user type. So the ease of form maintenance is a major advantage of this feature. And the more complex a form might be, the more important that point becomes.

Another differentiator for forms is that it supports a new concept we refer to as ‘form field’, something I alluded to earlier in this video. Prior to forms, any field that appeared on a given screen had to be either a system field or a custom property, so if there wasn’t already an appropriate system field or custom property in place for some given data, then one would have to be created. Essentially this binds a visual element – the field where users would enter information – with a data source. Form fields are different than any other type of field that you’re used to in that any data that is entered in a form field is not linked or “bound” to an existing system field or custom property. As a result, OFSC doesn’t record form field data the same way it records values that are entered into a system field or property.

 

Now let me explain how that works in the context of a form: Let’s say we have a form that has just two fields – a ‘work_order_type’ property and a form field to record the mileage on our truck when we arrive at the activity location. When I open the form, if a form element is bound to a system field or property, it displays its value – assuming there is one. For example, if the value for the work_order_type has already been set, then that field displays the value. The form field will be blank though, since there’s no data source that’s bound to from which it can display a value. There may be exceptions where a form field is pre-defined or auto-calculated, but the point is there’s no associated database record where an existing value can be obtained from. Now assuming I have read-write visibility for both fields, when I hit submit, the following will happen relative to the form and the fields:

First, OFSC captures all of the form’s data values in a snapshot. It then saves the snapshot, which can be accessed on the Forms History screen. The captured values are also accessible within a new ‘formSubmitted’ event via the Core API.

Second, the value I entered in the work_order_type field will be recorded, replacing any previous value for the appropriate data record. The value I entered for the Mileage field does not get recorded anywhere else, because that field is a form field. So it’s only available in the form snapshot, and only accessible in the Forms History screen in the UI, as an event via the Events API, or as a service request if the conditions match.

If I were to subsequently re-open the form, the work_order_type field would display the value that I previously entered – not because I previously entered it on this form, but because that was the most recent update to the its value. And the form field would once again be blank.

 

So form fields is a new data binding capability accessible within forms via the Visual Form Editor. Another one is a barcode scanner indicator. When this parameter is selected for a dragged-and-dropped input element, it works a little differently, depending on how the user is accessing OFSC. If using the installed iOS or Android app, and access to the device’s camera has been allowed, then the user can click the icon on the form and it will automatically invoke the barcode/QR scanner app on the device and populate the results of the scan into the field. It’s also possible to manually fill in data in the field and save it. If using the OFSC Core Application via a web browser – so not one of the installed apps - the barcode scanner field will display as a regular text input where the applicable code can be entered manually.

 

One more new addition to the Visual Form Editor that’s currently only available for forms is a new element called ‘Date and Time’. When this is added to a form, it provides a visual component that makes it easier for users to select the date and time on their devices. As it’s being configured, you can choose whether it should display a date picker, time picker or a date AND time picker. In any case, an icon will appear to the right of a corresponding ‘select date’, ‘select time’ or ‘select date and time’ parameter on the form, and when the user clicks it, they’ll be prompted to enter the value of their choice. This functionality is available within forms accessed via the Core Application as well as the installed iOS and Android apps, and the data captured is available from a ‘formSubmitted’ event via the Core API.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 11 - Forms

[pic]

Slide notes

This feature provides the ability to have forms configured for capturing data consistently, simplifying maintenance and minimizing the risk of errors within screen configurations. The same form can be shared across different user types, even if the screens they’re being accessing from are configured differently.

Form fields can make configuring forms more efficient and faster overall, reducing the need to create custom properties for every data element that’s to be displayed or captured.

A new event - ‘formSubmitted’ – can be added to subscriptions, allowing for the periodic retrieval of form data via an API call.

Barcode scanning capability is supported by designated elements within forms, allowing for users of the installed iOS and Android OFSC apps to automatically invoke their scanning applications at the touch of an icon. For Core Application users, it provides a text box where codes can be entered.

The Date and Time element makes it easier for users to select either the appropriate date, time or date AND time simply by clicking on icons within a form on their device.

Notes

| |

| |

| |

| |

| |

Slide 216 - Additional Information

[pic]

Slide notes

There are a few additional important details to be aware of:

All functionality described in this TOI video are applicable to the OFSC Core Application only. They are not available in Legacy Manage.

A form field only exists on the form to which it’s been added. This means that while multiple forms can each have a data field labeled “form_element#1”, those fields do not interact with each other, nor does any values entered in those fields impact fields on other forms.

All of the settings for an element on User Type configuration screens, such as visibility, default values, and validation rules, also apply to form fields. But it’s important to understand that they apply only for that form and only prior to submission. That means the values entered in a form field can be used to calculate default values, set visibility, or provide validation for other fields on that form. But, once the form is submitted, the data in those form fields effectively “resets”.

Default value and validation rules are not supported by the new Date Picker and Barcode Scanner elements, nor can they be “bound” to system fields or properties. They can be used to calculate default value on other elements configured on the form.

Existing Service Requests will be automatically migrated to Forms as part of the upgrade. Existing Plugins will also be automatically migrated to the Forms & Plugins screen as well.

The ‘Identify service request by’ identifier on the Screen Configuration tab doesn’t apply to service requests in Core Application since the structure of identifiers for Forms is persistent and cannot be configured.

And finally, when you create a message scenario that’s triggered by a service request, you’ll be able to use only those system fields and properties that belong to the Service Request entity. In other words, you can’t use the new Form Field elements as variables in the message or as blocking conditions.

Notes

Slide 217 - Summary of Enhancement Capabilities

[pic]

Slide notes

Here is the summary of the features I’ve talked about today:

First, the new Forms & Plugins configuration screen provides a single location for creating and managing plugins and custom Forms, which include Service Requests. 

Next, the improvements to the Visual Form Editor have resulted in a more intuitive and streamlined approach to both screen configuration and action management.  Requiring fewer steps not only makes for greater efficiency, but also reduces the opportunities for mistakes to be made. As such, the Action Management screen has been removed.

And finally, the expansion of the Forms functionality provides much greater flexibility in how customers can structure workflows and capture data.  The introduction of the form field element provides opportunities to quickly create new forms without having to create corresponding custom properties for each field.  And being able to share those forms across multiple user types without having to modify separate screen contexts simplifies the ongoing administration of workflows and helps eliminate redundant configuration.

Notes

| |

| |

| |

| |

| |

| |

Slide 218 - Implementation Advice

[pic]

Slide notes

In this implementation advice section we will go through what you need to consider before enabling these features in your business, and what you need to know to set them up.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 219 - Feature Impact Guidelines

[pic]

Slide notes

This table depicts key update information for the features covered in this training. All of the enhancements included in the Support of Forms feature are delivered ready to use – no additional configuration is required to enable the features. All features can be accessed through the default user type. These features are for use by administrators so have no impact on the existing business operations.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

Slide 220 - User Types

[pic]

Slide notes

The single user type that every instance of Oracle Field Service Cloud has is the Privileged Administrator user type, which can access every new feature covered in this training. Access to the Forms & Plugins Configuration screen is set by user type in the Main Menu/Configuration context. All user types that previously had access to the Action Management screen and plugin configuration will automatically have access to the Forms & Plugins screen after upgrade. You can create additional user types that can have access to the Support of Forms-related enhancements as well.  

This concludes this presentation. Thank you for listening. You can easily pause and rewind any of these slides if you require additional time to take in the detail.

Notes

| |

| |

| |

| |

| |

| |

| |

| |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download