GT eForms 3.50.00 Release Notes

GT eForms 3.50.00 provides a significant performance improvement to eForms. We built a smarter eForms engine that only does what needs to be done when a user fills out an eForm. In addition to better performance, this redesign also makes the Framework more reliable and easier to enhance.

New eForms Engine (3.50 Helium)

Performance Metrics

We no longer enforce spin-watching as a hobby for GT eForm users. We built a new forms engine we call 3.50 Helium. We’ve installed and refactored forms at a few clients to use 3.50 Helium and the results are impressive. We measure performance improvement by the time we save end-users from spin-watching when filling out a form. Measurements are provided as a reference and your solution will vary based on the size and complexity of your eForm.

Form Size	3.30.xx (seconds)	3.50 Helium (seconds)	% Wait Time Saved (Spin-Watching)
Small (1-99 fields)	11	7	34%
Medium (100 – 199 fields)	151	44	71%
Large (200 – 499 fields)	121	32	74%

Dependency Network

The 3.50 Helium Framework maps out the dependencies between all the elements in your eForm and stores them in what we call a Dependency Network. As eForms users interact with your form, the Framework refers to this network and only fires what needs to fire. It minimizes the processing, database calls, and memory your eForm requires. This translates to less spin-watching for users of your eForm, especially on form fields that have no logic tied to it. This new dependency-managed approach requires changes to the process of building eForm solutions. (See Building 3.50 Helium eForms)

Prior eForms Engine (3.50 Standard)

To facilitate the transition of existing forms to 3.50 Helium as part of an upgrade, we include the prior form engine so forms can work as before. We refer to the prior form engine as 3.50 Standard. As you are ready to evaluate, test, and if needed, refactor a form to work in 3.50 Helium, you can toggle a checkbox on the Form Type Setup to have the eForm use the 3.50 Helium form engine.

Please note:

3.50 Helium is not compatible with classic forms. If your form has the Form Style of “Classic,” even though you can check “Use Helium Performance”, it is not supported. Your form will still behave like a 3.50 Standard form, and you will still have spin-watching after exiting each field.

For forms that will use 3.50 Standard, we were surprised during the beta implementations to find the 3.50 upgrade also improved performance for form types using the 3.50 Standard form engine though not as dramatically as the 3.50 Helium form engine. Your results may vary from these averages.

Size of Form	3.30.xx (seconds)	3.50 Standard (seconds)	% Wait Time Saved (Spin-Watching)
Small (1-99 fields)	15	13	14%
Medium (100 – 199 fields)	469	410	13%
Large (200 – 499 fields)	No Large Forms Tested	No Large Forms Tested	No Large Forms Tested

As you can see, the 3.50 Standard version can still provide great value. Yet, our goal for you is that you experience the full benefits of the 3.50 Helium on all your forms. We recommend that you begin to make plans for how and when you will refactor all your forms to use 3.50 Helium. We will continue to support clients with forms using 3.50 Standard through the next feature release. However, 3.50 Standard will not be supported beyond the next feature release from GT.

3.50 Upgrade Scope

eForm Upgrade Testing Expectation

All eForms will need to be fully tested after the 3.50 upgrade regardless of whether they will use the 3.50 Standard form engine or the new 3.50 Helium form engine.

Performance Change Expectations

Area	Description	3.50 Standard	3.50 Helium
Navigation	To get to an eForm	No Performance Change	No Performance Change
Search	eForm Search Page	No Performance Change	No Performance Change
Form	GT eForm pages, segments, and fields a user sees, handles the data and processing of all user interactions on the pages	Minor Performance Improvement	Significant Performance Improvement
Workflow	Routing to Approvers	No Performance Change	No Performance Change
Integration (Component Interfaces)	Integrations over Component Interfaces or Web Services	No Performance Change	No Performance Change

3.50 Helium Features

Performance

Detailed 3.50 Helium Metrics

Client 1

End-User Action	3.30.xx (seconds)	3.50 Helium (seconds)	% Wait Time Saved (Spin-Watching)
Form Page Load	12	2	82%
Field Change – No Dependents (Deferred)	38	0	100%
Field Change – Dependents (Not Deferred)	44	2	96%
Navigating Between Pages	6	1	91%
Form Submission	12	8	35%

Client 2

End-User Action	3.30.xx (seconds)	3.50 Helium (seconds)	% Wait Time Saved (Spin-Watching)
Form Page Load	5	1	79%
Field Change – No Dependents (Deferred)	49	0	100%
Field Change – Dependents (Not Deferred)	59	17	72%
Navigating Between Pages	17	8	55%
Form Submission	5	10	-120%

Client 3

End-User Action	3.30.xx (seconds)	3.50 Helium (seconds)	% Wait Time Saved (Spin-Watching)
Form Page Load	12	2	82%
Field Change – No Dependents (Deferred)	38	0	100%
Field Change – Dependents (Not Deferred)	44	2	96%
Navigating Between Pages	6	1	91%
Form Submission	12	8	35%

Client 4

End-User Action	3.30.xx (seconds)	3.50 Helium (seconds)	% Wait Time Saved (Spin-Watching)
Form Page Load	11	5	50%
Field Change – No Dependents (Deferred)	2	0	100%
Field Change – Dependents (Not Deferred)	26	11	59%
Navigating Between Pages	6	5	19%
Form Submission	12	11	9%

Client 5

End-User Action	3.30.xx (seconds)	3.50 Helium (seconds)	% Wait Time Saved (Spin-Watching)
Form Page Load	4	3	11%
Field Change – No Dependents (Deferred)	5	0	100%
Field Change – Dependents (Not Deferred)	8	8	0%
Navigating Between Pages	6	7	-16%
Form Submission	4	3	12%

Deferred Fields

Deferred Mode

You may be wondering why we differentiate between fields that have logic and fields that do not and how that affects the 3.50 Helium engine. We differentiate because we have incorporated PeopleSoft’s Deferred Processing Mode into GT eForms. You can read more about Deferred Processing Mode in PeopleSoft’s documentation here.

GT Deferred Mode

The 3.50 Helium engine checks whether anything in the form is dependent on a field and if there is, that field will have the deferred mode turned off. As a user leaves the field after entering a value, the engine will trigger a trip to the server to fire the dependent logic changes. The indicator a trip is happening is the spinner that pops up on the page. If there is nothing dependent on that field, the field will have deferred mode turned on. As a user leaves the field after entering a value, there will be no trip or spinner. This drastically improves usability and rapid data entry in an eForm.

GT Deferred Mode Override

We also give a functional form builder the power to override the deferred behavior for a field using a new “Deferred” option on the Field Details page (see image below). All fields have Deferred mode set to “Calculated” initially, meaning the framework will determine if the field has dependencies to determine if deferred mode should be on or off. However, a form builder can choose to override the calculated deferred behavior by setting Deferred to “On” or “Off” manually.

For example, let’s say your form has a date field, nothing is dependent on it, and you want it to always reformat to “04/01/2022” after a user enters “4/1/22” and leaves the field. A form builder would set Deferred to “Off” on that field so end-users benefit from seeing the formatting change happen right after leaving the field instead of putting it off until another action triggers a trip. This matches the behavior of a deferred date field on a standard PeopleSoft page.

On a standard PeopleSoft page, a developer would have to use App Designer to mark a field as deferred or not deferred. GT eForms calculates whether the field should be deferred and allows form builders to override the calculated behavior using configuration instead of App Designer.

GT Deferred Mode Override Page

Navigation: Manage GT eForms 3.x > GT Functional Setup > eForm Parts Gallery > Deferred Mode

We envision Deferred Mode to be a powerful feature that a form builder can use to meticulously craft the end-user flow of filling out an eForm. We knew it would be tedious to drill into Field Details for each field, so we created a new setup table that lists all the fields on a form and allows you to quickly make changes to each field’s Deferred Mode. This table updates Field Details on the Form Setup but is a more SEEFul way to see and update all the fields at once.

Visibility

Dependency Network Visualizer

Navigation: Manage GT eForms 3.x > GT Utilities > Network Visualizer

The 3.50 Helium form engine includes a Dependency Network Visualizer. This Visualizer provides visibility into the elements that make up an eForm and the relationships between those elements. While this tool does provide the ability to see everything happening in a form type, the network is technical in nature and a full understanding will require training. Additional documentation and simplification of the tool may be released in the future.

Example 1: How many column segment fields there are in a form type

Example 2: What prepopulates POSITION_NBR and what happens when POSITION_NBR changes

In this example, the visualizer shows that the POSITION_NBR field is prepopulated from the SATPOSTAG data pool record and when POSITION_NBR changes on the form it updates the value of POSITION_NBR2.

There are various types of analysis this tool can support. Additional examples include:

• Whether an element (field, data pool record, search field) in a form type can be deleted without breaking anything on the form
• What happens in a form when a field is changed
• What a Data Pool Record is used for
• Where a PeopleCode or Configured VisualIf is used

Annotations

Navigation: Manage GT eForms 3.x > GT Functional Setup > eForm Parts Gallery > Annotations

This page shows all the PeopleCode parts and events in a Form Type and whether those parts/events have been annotated. Annotations are a new 3.50 Helium code pattern that tells the form engine what a custom PeopleCode part or event is dependent on in the form so the engine can fire the part/event when it needs to. These code patterns are covered in a separate document under the Tips N Tricks folder of the GT Customer Self Service documentation site.

Example 1: When the GSTOTAL_AMOUNT field changes, a custom page paint hook will be triggered.

Process Improvement

Form Build Process

To create the Dependency Network described above, a form builder needs to run the Form Build Process whenever changes are made to the Form Type Setup or code. A form builder can choose how and when this Form Build Process is run via the General tab of Form Setup.

Build Immediately on Save

The default for new forms will be “Build Immediately on Save.” This option means that every time the Form Type Setup is saved, a Form Build will start and finish before indicating the Form Setup has been saved. The status of the Form Build will appear in a message box after it is completed, indicating if the build was successful, was successful but has warnings that should be reviewed, or failed due to errors. If the build was successful, no further action is needed, and you can test your form and see your new form behavior. If your build had warnings or failed, you can click a link on the General tab to open the Form Type Build page in a new tab to review the messages.

Save Without Building

If you do not want to wait for your form to finishing building in your user session but still would like the Form Build Process to run each time you save, you can change the Form Build Option to “Schedule Build on Save.” When this option is selected, saving Form Setup will kick off the build via the Process Scheduler. A “Build Details” link will appear above the save button for a form builder to view the status of the build in the process monitor. Again, the process monitor will either show successful, successful with warning, or error and the same process mentioned previously to review warnings and errors can be followed.

Schedule Build on Save

If you are in the initial stages of configuring your form and do not wish to kick off the form build each time you save, you can change the Form Build Option to “Save Without Building”. As it sounds, this means the build process will never automatically kick off. When this option is selected, a “Run Form Build” link will appear above the Save button on Form Setup to remind you to kick off the build when you are ready. Clicking that link will open the Form Type Build setup page in a modal window where you can choose to run the form build process in your user session or via the Process Scheduler. Again, the same messages and process to review warnings and errors apply. If you forget to run the Form Build and go to test your form, you may encounter errors when opening or the form may not behave as expected. Therefore, it is best to only choose this option when you run into issues with the form build kicking off too frequently or taking up time when rapidly developing.

Form Build Work

The Form Build does the following:

1. Processes all the custom code for a Form Type

   NOTE

   This replaces the Load Custom Parts process. That process is deprecated and not used for 3.50 Helium.

2. Builds the Form Type Dependency Network using the code and configuration for a Form Type

3. Calculates and stores what needs to happen for every user interaction on a form

New Code Patterns

3.50 Helium includes new code patterns that need to be followed to allow custom parts and events to be dependency managed. These code patterns will be outlined shortly in a separate document under the Tips N Tricks folder of the GT Customer Self Service documentation site.

Form Data Format

Turning on Helium Performance changes a form’s data format. 3.50 Helium uses JSON while 3.50 Standard continues to use XML as the earlier 3.30.x versions have. The JSON format is simpler to read and update. In addition to changing the data storage format, we also changed the structure of the data to be based off record and rowset tags instead of segments. This means a field that is in multiple segments will show up once in the JSON instead of being replicated for each segment.

You are still able to view and update the form data JSON just like you did with XML via the Form Data tab of the Form Admin Tool.

XML Form Data	JSON Form Data

Implications for Pre-Upgrade eForms Transactions

eForms that were submitted prior to turning on Helium Performance for the form type can still be acted upon and viewed after turning on Helium Performance. The eForm data is converted from the XML format to the new JSON format when the eForm is opened. When action is then taken on the eForm (resubmitted, approved, etc.) the JSON form data is saved.

3.50 Helium/Standard Fixes

We’ve been working on Helium for over a year and are so excited to finally release it. With that said, we haven’t forgotten about our standard 3.50 fixes and we’re sharing them with you here. These fixes are included in both the 3.50 Standard and Helium form engines. Thank you all for your suggestions and input! We always welcome feedback in hopes of better meeting your needs.

New Attachment Message

A new version of the error message appears for required attachments. Trying to submit a form without uploading a required attachment no longer indicates that the user needs to upload or delete the row. The message now advises the user, “An attachment with the description [attachment description name] is required for this form.”

New Manage Custom Parts Page

Have you ever wished you could remove the space between “U R L” in our delivered Smart Sources or other custom Smart Sources created? Well now you can, and more! We have created a new page, Manage Custom Parts, which allows you to view and edit certain elements of Smart Sources, Visual If Parts, Rosters, Data Pool Custom Load Parts, and Custom Segment Drivers. Here is an example of how the description of the delivered “True” Visual If is updated to display “Always True”.

Below is a list of the elements within the Manage Custom Parts page that you can adjust in addition to seeing all the parts within the framework.

Smart Sources

• PeopleCode Smart Sources
  • Description is editable
  • Package (custom packages only)
  • Path (custom packages only)
  • Class ID (custom packages only)
  • Method (custom packages only)
• SQL Smart Sources
  • Description
  • SQL Object ID
• Query Smart Sources
  • Smart Source Description
  • Query Name

Visual Ifs

• PeopleCode Visual If Parts
  • Part Name
  • Package Name (custom packages only)
  • Path (custom packages only)
  • Class ID (custom packages only)
  • Method (custom packages only)
• SQL Visual Ifs
  • Part Name
  • SQL Object ID
• Query Visual Ifs
  • Part Name
  • Query Name

Custom Part Filtering by Application Package

Speaking of custom parts, with 3.50 comes a change where the framework will now filter custom parts. These custom parts are Smart Sources, Visual If Parts, Custom Segment Drivers, Data Pool Custom Loads Parts, and Defined Rosters. When you look for one of those custom parts, the only parts visible in the search will be those included in one of the following application packages:

• Form Type application package
• Form Type’s Form Family application package
• Form Type’s Search Set application package
• System application package

You can view which application package is associated with each category here: Manage GT eForms > GT Technical Setup > Custom Application Packages, as shown below. If you were sharing a part that belonged to an application package not associated with your Form Type, Family, or Search Set, you would need to add it to one of your application packages.

New Smart Source

A new Smart Source, Comment History HTML, was created to be used when comment history carriage returns are being ignored in emails. This Smart Source renders the comment history for use in emails and webpages.

New “Show” Option in Search Configuration

The “Use” checkbox in Search Configuration has been changed to “Show.” This change now means the Show column controls whether a field added to the Search Configuration is visible to the end-user on the Search page, while keeping that field as a search key.

Rich Text

GT eForms 3.50 includes a Rich Text security patch and fixes for issues PeopleTools 8.59 introduced. Oracle released a Fluid Rich Text editor in PeopleTools 8.59. GT eForms released a Fluid Rich Text editor three years ago using Quill (quilljs.com). We will continue to use the Quill Rich Text Editor going forward to provide a consistent experience for our clients regardless of their PeopleTools version.

Smart Source Form Descr Deprecated

You may have noticed we had Smart Sources for Form Descr and Form Type Descr that both appeared in searches. To fix the duplication, the Form Descr Smart Source has been deprecated.

In 3.50.00, if you are using the Form Descr Smart Source in your solution (most likely in your email templates), you will get this error:

To address this issue, you can do one of the following:

1. Update any Smart Sources referencing Form Descr to useForm Type Descr instead
2. Allow Form Descr to still be used at the solution level by putting the following code in a LogicParts class in your system application package (GT Technical Setup>Custom Application Packages)

method SMARTSRC_FormDescr();

method SMARTSRC_FormDescr
   /+ Returns String +/
   Return &G3FRM.FORMREC.DESCR.Value;
end-method;

3. Allow Form Descr to still be used as a framework customization by uncommenting the Form Descr SmartSource in the G3LOGIC_DELIVERED:SmartSource class
   1. Option 2 is recommended over this to prevent you from having to maintain it as a framework customization

method SMARTSRC_FormDescr();

/*||| 5/3/2022 GTC-2830  START |||*/
<*method SMARTSRC_FormDescr
   /+ Returns String +/
   Return &G3FRM.FORMREC.DESCR.Value;
end-method;*>
/*||| 5/3/2022 GTC-2830 END |||*/

Forms Engine

Prompts

• Provided a fix for a bug that was causing multifield prompts to not rebuild.
• Provided a fix for PeopleSoft’s auto complete (aka type ahead) to work if the first field in a grid is a lookup.
• Provided a fix that allows prompt fields to be added in columns 11-18 in a grid.

Attachments Segment

• Fixed a bug where non-default conditions could have their attachment setup wiped out or replaced by the default condition’s setup. Now, when a user has multiple conditions on a form, the user can make changes to the attachment instructions in the default condition without worrying about other conditions being changed or wiped out by that change.
• The Add button in the Attachments segment is now disabled in the View task.
• A fix was provided for an issue where disabled attachments could be seen in certain scenarios.
• An enhancement was provided to better handle virus related attachment upload errors (if attachment virus scanning is enabled and implemented in the environment).

Comments Segment

• A fix was made for a bug causing multiple duplicate comments to show when one comment was entered in the Comments segment.

Related Displays

• There was a fix to remove extra spacing within a segment row after adding any related displays to the elements of the row.
• A fix was made to correct related displays that were wrapping incorrectly.
• A fix was made so that Related Descriptions appear as soon as a user selects a value from the prompt of the field associated with the Related Description, as opposed to having to refresh the page.

Logic

• A fix was made for a bug where the Signature/Action Logs header would show on the Delivered History Page when the Visual If was false for the Signature/Action Logs segment. Now, if the form log segment is set to hide, it will now correctly hide the segment and segment header for both Delivered History Page and Delivered Results Page.
• A new view G3RECDEFN_VW was created and applied to the G3DATA_POOL_REC table, which will be used on recname for the prompt table in the Data Pool.

Query Records

• A fix was made to correct an issue where the “Use Process Scheduler” link was disappearing after dropping data in structure in the Form Setup Query Records tab.
• A fix was made to prevent an error using the Build button on Form Setup Query Records tab if CLOB field is on multiple record tags.
• A fix was provided to accommodate the DATE field while building query records. Report Setup
• An upper-case G3XML_ID field was causing an error in Reports Setup in Form Setup. It was changed to mixed case to resolve the error.
• A fix was provided for an error that was triggering when trying to set up a custom XML report.  

Other

• A validation was added limit Form Family and Form Type names to only allow alphanumeric and underscore characters. Not allowing dashes in the name prevents future errors with content references.
• Oracle fixed an issue that we previously had a work-around for where checkboxes weren’t registering values behind the scenes. This is no longer an issue, so we removed the work-around.
• A fix was provided for an issue where a search with Form ID as URL parameter was not joining G3FORM_ID to a search record.
• A fix was made to get the landing page HTML to show on search set landing pages.
• Validation fires to enforce that record tags are unique across segments and data pool.
• A fix was provided for an issue where Screen Reader Mode was causing fluid checkboxes to not show the Yes/No indicator on the toggle control.

Workflow and Notification Engine

Workflow Engine

• A fix was made to the GT Auto-Approval code to solve a bug that was causing a “.Null” error and preventing the GT Auto-Approval process from completing in 3.30.03 and 3.30.04.
• An enhancement was provided to allow for context aware Step Visual-ifs and Criteria Shim code, so step-based people code visual-ifs can access the step context (stage/path/step) where they are being run.
• An enhancement allows programmatically set whether AdHoc is enabled/disabled.
• An enhancement to show more intuitive workflow step titles.
• The Use Step Roster checkbox has been made available for the “Routed” Notification Event and the following Advanced Notification Events: _OnStepReassign, _OnStepReactivate, _OnStepComplete, and _OnStepPushBack

Notification Engine

• An enhancement was made to allow Attachments on Email Notifications using the “Send emails through Integration Broker (SMTP Guarantee)” field in the Form Installation Table.
• A fix was made for a bug with Worklist Item form links not taking users to the form.
• A fix was provided for an issue where notifications were not sending to an approver in ad hoc paths.
• A fix was made to resolve an issue where copying and pasting Notifications wasn't filtering Notification event fields correctly.

Other

• A fix was made to correctly display bind numbers on SQL Object Defined Rosters.
• Support added to allow AWE's Pushback functionality to be added programmatically to an eForm.
• A fix was provided for an issue where SMTP guarantee emails were not using all email template setup.

Search and WorkCenter

Search

• Fix was made if an error appeared on the ADD search from a debug message.
• A fix was made to prevent the Search Configuration page from crashing when Form Field labels were longer than 250 characters.
• A fix was provided so that a search only runs for Form Type if Form Type is the search field that is populated in a search configuration page.
• A fix was provided for an issue where a search with Form ID as URL parameter was not joining G3FORM_ID to a search record.
• A fix was made so that skipping search doesn’t hide search fields upon return to search.
• A fix was provided for form checkboxes rendering as dropdowns in the search fields.
• A fix was provided so that Return to Search loads the correct form if a user initially searched for a different, specific form ID.
• A fix was provided to address an issue where Search Page with a blank 1st search field didn't work when search results in 1 row.

GT Utilities

GT Admin Tool

• Fix made for a bug that was preventing On Hold forms from being opened via the Admin Tool. A fix was made to fix the resubmit functionality in the Form Admin Tool. There was a problem where the XML for a form's G3FORMLIST data was not syncing when a form is resubmitted through the admin tool. G3FORMLIST is syncing the last oprid and date/time while the XML isn't. The fix that was applied was to mimic the process used by the form, as that uses different code than the Admin Tool for accomplishing the resubmit.
• A fix was provided for an issue where opening a form in the Form Admin Tool was taking a long time because the form was being instantiating three times.
• A new button/link "Authorize without IB" was provided to the Form Admin Tool.
• A fix was provided so that Admin Tool Approvals indicate who the Admin user was that added the workflow approval.

Multi-Language

• A fix was made to prevent errors using Multi Language in forms with a data pool containing a CLOB.

Attachment Population Utility

• Improvement to the tool to look directly at the form XML instead of standing up form objects for grabbing the query data, which increases performance.
• Fixed an issue with the utility creating duplicates attachment entries.
• Updated missing descriptions both for previously blank nodes and for new, added two missing XML nodes to the form XML due to attachment XML version differences.
• Additional updates made to pre-3.30.x attachments through the attachment population utility.

GT Modal Popup Utility

• A fix was provided to be able to retrieve a heap value after closing the popup.

Form Transporter

• A fix was made to resolve a Form Transporter export issue, making it possible to correctly export duplicate segments on the same Task Step but different Task Sub Step.

GT Bolt-Ons

Batch Tool

• Install now includes G3LOADCUSTOM application package, which includes a class: G3LOADCUSTOM:CustomEvents:BatchEvents.
• A fix was made for loading the data pool in the G3FORM:Actions class.
• A fix was provided so that G3LOADCUSTOM:CustomEvents:BatchEvent class gets included in framework.
• G3BATCH:BatchMethods class (only included in the Bolt-On code, not the eForms framework) contains various fixes to the batch tool.

Developer Tools, Hooks, and Methods

Methods

• SetIfDifferentAndNotEmpty method has been added to G3CI:CIParent.

Hooks

• A fix was made to not use the IB to send emails when the form is in error since because IB OnError emails do not work with SMTP guarantee on, as IB messages don’t get published in an OnError context.
• A fix was made to allow URLs on the form to execute.
• The SortDropDown hook was implemented for grid dropdowns.
• ApprovalRosterResolve Event hook was added to the framework.

DMS Scripts

• A DMS Script fix was made to update the form status table with new translate values.

Other

• A fix was made so that using GetUserOption doesn’t hang IB in 8.59.
• A fix was made so that a SQL Visual If doesn’t always return False. Now, if you add a SQL Visual If on a vis if, if the SQL returns a value, then it returns true. If no value is returned, then it returns false.
• Updates were made to SQL for MS SQL Server Compatibility modifications made in SP4.
• A fix was made to replace with %CurrentDateIn, which resolves correctly despite the platform to fix a SQL issue in SQL Server/DB2 environments with delivered G3 SQL Smart Source. Previously, the framework crawled G3_SMARTSRC SQL objects and builds Smart - Sources from them and was trying to build a Smart Source SQL in SQL Server/DB2 environments, breaking on SYSDATE syntax.
• A fix was made so that Load Custom Parts process doesn’t silently fail due to Rollbacks.
• A fix was provided for Framework compile errors.
• Added versions of the G3CI:CIParent SaveCI and UpdateSaveCI methods that return a boolean instead of throwing an exception
• A fix was provided for an issue where Custom Segment Form Type Setup was not saving.

GT eForms 3.50 Documentation

Changes to feature documents are coming soon to reflect the new pages and changes to pages in GT eForms 3.50. As documents are updated they will be posted on the Documentation channel of GT Customer Self Service unless otherwise noted.