Summary
The following Smart Forms have been migrated by Axsy from V1 to V2 format and are available in the FFABIT org as draft format Forms and the FFATEST org as version format Forms.
Table 1 - Smart Form Handover Delivery Schedule
All changes to the Smart Forms above are described in further detail in an update to the Design Documentation available at the following link: https://docs.google.com/spreadsheets/d/1UT0VD2k_pt-xn3sk0mLA3VXC3UL6z55_Ng0jUZEHuE8/edit#gid=1662691566
The above Smart Forms may be executed in an identical fashion to the V1 Smart Forms by association to a Work Order.
Test reports are available for each of the Smart Forms in the following web link:
https://drive.google.com/drive/folders/1-3l_Dt6dEtXt-dVCmhMbDeNVuRwo21-d?usp=sharing
Smart Forms Managed Packages
V1.43
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t1U000007cOTm
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t1U000007cOTm
Release notes are available for this managed package and preceding managed packages from the following link: https://ng.support.axsy.com/support/solutions/folders/76000008516
Known Issues
Designer preview may show an erroneous error message for pick list strings – fixed in v1.44 of Axsy Smart Forms.
Axsy Smart Forms v1.43 has been installed by Axsy in the FFABIT and FFATEST orgs.
Field Service (FS) Mobile Apps
The following Axsy FS mobile apps are available:
Android:
https://install.appcenter.ms/users/js-axsy.com/apps/axsy-field-service-1/distribution_groups/public%20access
Windows: App link will be provided later.
Axsy FS iOS and Android Apps v 5.6
Usage
The Axsy iOS and Android FS apps are beta apps made available to NG for testing purposes ahead of their intended App Store distribution planned for 29th October 2021.
The iOS and Android FS apps must not be used for production purposes or distributed outside of NG test teams
Axsy FS Windows App v5.6
An issue has been identified in the FS Windows app relating to image capture which must be resolved before release for beta testing.
ADDENDUM: Draft Import Considerations
- When importing draft Smart Forms into an org that has previously had a V1 Form of the same name in the org may result in Form Mappings used in V1 that are not required for the newly imported V2 Form.
Check the Related tab for the relevant Smart Form and if there are any Form Mappings then these must be manually deleted
.
Addendum Figure 1 – Removing V1 Form Mappings Manually
Migration Implementation
Meter Barcode Capabilities
Based on the details provided to Axsy in the Excel spreadsheet “DOM 01-June-2021.xls” Axsy has implemented derivation of meter fields based on the meter serial number.
Axsy applied the following changes to the DOM Smart Forms to allow for derivation of meter fields from the serial number.
Table 2 – Meter Barcode Capabilities
Except for the invisible Element “Is the Serial Number Valid” all of the above Elements may be manually entered. Valid scanned (via the mobile device camera) or manually entered meter serial numbers will populate the remaining meter fields.
The meter mechanism picklist used in the DOM Smart Forms varies depending on whether the meter is an existing or a new meter. The availability of picklist values is shown in Table 3 below. For new meters all non ‘CR’ meter mechanisms will resolve as ‘PP’.
Table 3 – Availability of Picklist Values for Existing and New Meters
Compatibility of Smart Form Elements to Salesforce Data Types
Axsy Smart Forms V2 requires Smart Form Elements types (text, numeric etc) to be compatible with the corresponding Salesforce field types they are mapped to. It was noted that certain Elements were not compatible with their mapped Salesforce fields. Axsy made no changes to the Salesforce data model but did change some Element types so alignment was achieved, this is summarised in Table 4, below.
Table 4 – Modification of Element Types for Salesforce Field Compatibility
Dates
Date Elements in Smart Forms V2 differ in their presentation from V1 dates, these are summarised in Table 5 below.
Table 5 – Date Format Content
Any post form response processes that expect dates to be in the V1 format may need to be updated.
Jump To’s
Jump To’s in Smart Forms V2 should be contained within loops or their own subsection, Axsy has implemented this approach throughout the Smart Forms. This will result in a page break in the mobile app when the subsection is entered. See our article:
https://smartformssupport.axsy.com/support/solutions/articles/76000013601-form-layout-page-breaks
In the following Smart Forms / Sections: DOM_IPRMFC /DOM - IPRM Rectification Action and the DOM_MPRMFC / DOM - Rectification Action Jump To Elements are present in the V1 Smart Forms that are not allowed in V2 Smart Forms, see article below.
Axsy has removed these Jumps and from inspection the required business logic is retained via the use of visibility formulas.
The removed Jump To’s are noted in the updated Design Documentation:
Use of Non-Unique Salesforce ID’s
Axsy observed that non-unique Salesforce ID’s were used for Elements throughout the DOM Smart Forms. The resolution of all of the non-unique Salesforce ID’s is beyond the scope of this handover and is expected to be performed by NG at a later stage. To assist in the detection and resolution of non-unique Salesforce ID’s further details are provided in Appendix 1 and Appendix 2.
Axsy introduced unique Salesforce ID’s for all Elements used in meter barcode scanning to enable the barcode scanning formulas to function correctly. Axsy also corrected references to any dependent Elements the barcode scanning Elements referred to and where necessary introduced additional Elements with unique Salesforce ID’s in the dependent Elements. The manner in which unique Salesforce ID’s were introduced is described in Appendix 2. Details of the Elements introduced by Axsy and any Element Name changes are listed in the updated Design Documentation:
Validation Checking Configuration
Axsy V2 Smart Forms has validation checking features (not present in V1 Smart Forms) to aid Smart Form Designers during the creation of their Smart Forms. During the course of the migration project validation errors were detected by the V2 Smart Forms validation checker, which resulted (due to the way detected errors are handled) in the migrated Smart Forms being executed in a dissimilar manner to their V1 equivalents. To ensure continuity of the migrated Smart Forms, Axsy introduced two validation checking configurations:
Lenient mode – which is compatible with V1 Smart Forms validation handling
Strict mode – the default V2 Smart Forms mode.
Refer to Table 1 which lists the Forms that have Lenient or Strict mode applied. The introduction of Lenient mode enabled the migrated V2 Smart Forms to be executed in the same manner as their V1 equivalents.
Details are provided below on how to change the validation configuration.
Changing the Validation Configuration
The validation configuration for lenient mode is shown in the highlighted text, in Figure 1 below.
Figure 1 - Validation Checking in Lenient Mode
The absence of a validation configuration enables strict mode as shown below in Figure 2.
Figure 2 – Validation Checking in Strict Mode
Notes
The Config field may need to be added to your Salesforce page layout
Changes to the configuration can be made to Smart Forms in Draft format in Designer
To change the configuration edit the Config line as shown in Figures 1 and 2 above and save the change
A further dummy change must now be made in the main body of the Designer, pick any Element, Save it (without making any changes)
Save the Form
Publish the Form – this applies the changed configuration
When a JSON export is performed of the Smart Form the configuration is captured in the JSON file, when this JSON is imported into another org the configuration is applied. An alternative method to change the configuration is to manually inspect and edit the JSON file prior to the import of the JSON file into another Salesforce org.
Minor Differences Between Source FFADSEAR1 ORG and FFABIT ORG
Minor differences were observed in the FFABIT org relative to the reference FFADSEAR1 org, in all cases the content of the FFABIT org was retained and any changes (e.g., new Elements) are captured in the Design Documentation:
Mapping Changes
All migrated Smart Forms have had their mapping syntax modified to the V2 format.
Mapping Discrepancies
Form: DOM_MPRMFC
Section: DOM Termination FC
Element: DOMMPRMFCFORMRESPONSESTATUS
was noted to be mapped to FFA_Form_Response_Status__c this field does not exist in the Work Order object and thus the Mapping was removedForm: DOM_IPRMFC
Section: DOM - IPRM Termination FC
Element: DOMFRStatus
was noted to be mapped to FFA_Form_Response_Status__c this field does not exist in the Work Order object and thus the Mapping was removedThe regulator Element Name: DOMNewRegulatorModelFrancelNI used in some Forms (e.g, DOM TSEHire) does not have a mapping to Salesforce, whereas adjacent regulator Elements do have this mapping.
Necessary Mapped Field Permission Change
The field FFA_Appliance_3_unsatisfactory_comment__c in the Job_Information__c object had a ‘Hidden’ permission, Axsy changed this permission to ‘Editable’ in both the FFABIT and FFATEST orgs as an essential change to enable any Forms with Safety Checks to work normally.
ISBLANK Correction
Smart Forms V1 uses an incorrect application of the ISBLANK expression, this has been corrected in the migrated V2 Smart Forms. Close inspection of the formulas previously using ISBLANK may be required to detect these changes.
Appendix 1 – Validation Errors
Please refer to our knowledge base articles for mobile app error reporting and designer error reporting:
Mobile App: https://smartformssupport.axsy.com/support/solutions/articles/76000034235-in-app-error-alerts
Designer: https://smartformssupport.axsy.com/support/solutions/articles/76000034753-smart-form-preview
If errors are present in a Smart Form, tapping on the red exclamation mark in the mobile app will reveal an error message screen. Similarly running the Smart Form Designer will also show the same error message summary. Note it may be necessary to navigate through a Smart Form to expose all the errors. Except for validation errors that may be attributable to the use of duplicate Salesforce ID’s for Elements, the resolution of in-app reported errors is outside the scope of these Release Notes.
Validation Errors Due to Non-Unique Salesforce Element ID’s
All Elements in an Axsy Smart Form have an underlying Salesforce ID. This can be revealed by downloading the JSON for a Smart form. An example is shown in Figure 3 below.
Figure 3 – Smart Form Element with Salesforce ID Visible via Smart Form JSON
Elements often have formulas associated with them, in the example in Figure 3 a validation Formula is used, other formulas include: validation, visibility and default values.
If an Element has a formula associated with it, the Salesforce ID for that Element must be unique to the Smart Form that the Element is within unless the Section that the Element is contained within is in a Shared Section. See Axsy’s knowledge article here for more information about Shared Sections:
Many of the DOM Smart Forms have Elements with Salesforce ID’s that are not unique to a single Smart Form and the Section they are within is not a Shared Section. Where these Elements have associated formulas the consequence of this is that only the Elements in one Smart Form might potentially be correctly evaluated, but the formulas for the corresponding Elements in the other Smart Forms will not be correctly evaluated.
If Strict mode is enabled these errors will be reported as validation errors in the Mobile App and Designer, furthermore the expected functionality when comparing V1 and equivalent V2 Forms may also change, in some cases Strict mode may make a Smart Form unusable.
Axsy has provided separately to these Release Notes Excel data that will assist in the resolution of validation formula evaluation for the DOM Smart Forms. General guidance is also provided below on how to detect and resolve these errors.
Enable Strict mode
Either via the Designer preview or via a mobile app, run the Smart Form to expose the errors
If the reported Element references a Salesforce ID that is reused in other Smart Forms (check the Excel data sheet) then the source of the error is likely to be due to Salesforce ID reuse, you may further verify this by downloading the JSON for the respective Smart Forms and searching for the same Salesforce ID in the separate JSON files.
As an example, inspecting the Element DOMAsbestosPhotoNGMSC in DOM_TSEHire (in the DOM - Safety Checks (TSE Hire) Section), the visibility formula is in an error state as shown below in Figure 4.
Figure 4 – Example Visibility Formula in Error State
The Element DOMAsbestosPhotoNGMSC has a Salesforce ID used in three Smart Forms:
DOM_NewInstall
DOM_Remove
DOM_TSEHire
As the Salesforce ID is not unique for the Element under consideration the visibility formula in Figure 4 cannot be supported – the presence of a Salesforce ID @a0t7a000003qMSpAAM indicates an erroneous formula.
The correct visibility formula cannot be applied until each of the Elements in the three Smart Forms have a unique Salesforce ID.
Appendix 2 – Applying Unique Salesforce ID’s to Elements
The procedure used by Axsy to create Elements with their own unique Salesforce ID’s is described below:
Identify an Element that needs to have a unique Salesforce ID
Download the JSON for the Smart Form and find the Element in the JSON – typically by searching on its label – see Figure 3
Find the corresponding Salesforce ID for the Element – again refer to Figure 3
Using the search feature in your JSON browser search for all occurrences of the Salesforce ID determined in step 3 above making a list of any dependent Element references that use this ID – this may be within the same Element (a validation formula) or other Elements or both
Case 1 - The Element has no Dependent References
In the Smart Form Designer, Clone the Element using the Clone feature, using Clone causes the newly cloned Element to have a unique Salesforce ID.
Figure 5 – Use of The Clone Tool
This will result in an identical looking Element directly below the original Element
Figure 6 – Cloned Element Below Original Element
Double click on the cloned Element and as best practice give the Element a unique Name as shown in Figure 7, below.
Figure 7 – Making the Element Name Unique (Good Practice)
Then make any changes to the relevant formula, in Figure 8 below, the correct formula has been determined by inspecting nearby Elements, but in many cases more complex assessments must be performed.
Figure 8 – Correcting the Visibility Formula
Save the Element and the correction should now be applied
Delete the source Element and save your Smart Form.
Case 2 – The Element has Dependent References
If the Element that you have cloned is referenced in dependent Element formulas you must now go into each of these Elements and make changes to relevant formulas so that the Element Name (see Figure 7) is used in these formulas.