Form Control provides a “No Code/Low Code” Customization tool for Microsoft Dynamics GP that can revolutionize how users, consultants and developers can make changes to how GP windows work. It was added as a new module to GP Power Tools with the release of Build 31.

This is the first article in a series of four articles. The series provides an introduction to Form Control, why it was created, how it works and what it is capable of doing. I will describe how the initial example of making Maintenance windows Read Only was configured. Then I will provide details of some extensions that can be added. The final article has downloadable sample projects for both Customer and Vendor Maintenance.

To explain why Form Control is needed, you need to understand an example of the type of requirements it was created to solve.

The Auditor’s Requirement

We were recently approached with a requirement from a customer’s Auditors to provide absolute “Separation of Duties” for adding or updating Vendor details using the Vendor Maintenance window and the Vendor Workflow process.

The customer needed the Accounts Payable team to be able to enter or edit the Vendor details and send the changes for approval. The approver should be able to see the data on the Maintenance window and approve the workflow, but not be able to make any edits on the window. The customer needed to make the Maintenance window and child windows Read Only for specific user and company combinations.

This separation of duties is vital to ensure that bad actors cannot work alone to make changes and approve them and needed to be demonstrated as a requirement from the company’s Auditors.

What is Form Control?

GP Power Tools – Form Control Introduction (direct link)

The idea behind Form Control was to use resource filters and rules to create customizations without needing any coding or only needing a small amount of code. Making a Maintenance window Read Only was the initial test case used during development.

Using a single “Lock Field” rule with resource filters that include all fields, but exclude the fields used for navigation (browse buttons, primary lookup, key field, etc.), and making it work for alternate and modified windows would solve the requirement with a simple “no code” solution.

Also, having the standard GP Power Tools user settings window at either the Form Control ID or Rule level would provide easy assigning of the customization to the current user and company using Users and/or Companies, User Classes, Security Tasks, Security Roles or the Security ModAlt IDs.

While Form Control can easily solve the Auditor’s requirements above, this sort of functionality has been requested for many years.

Example Read Only Customer Maintenance window

Quick Definitions

In Dexterity (the language Dynamics GP is developed with), a Form is a container that can include one or more Windows. Each Window can have fields added to it. Form Control can apply filters and rules at the Form, Window and Field levels.

Note: This definition of a “Form” is different to how other languages might use the term.

Why was Form Control needed?

In Microsoft Dynamics GP almost all windows that use a Customer ID, Vendor ID or even an Item ID have a “Zoom” drill down back to the Customer Maintenance, Vendor Maintenance or Item Maintenance windows (respectively). If a user should not have the ability to make changes on these Maintenance windows, the usual practice would be to not grant them access using the standard GP Security Tasks and Roles (which might require duplication of Tasks and Roles), or if you already have GP Power Tools, you could just deny access using Deny Based Security from the Enhanced Security window.

If security access to the window was not granted (or denied), clicking on the drill down would fail and the user would be unable to easily view the data on the Maintenance window. It would be possible with a few extra manual steps to open an inquiry window to see similar data, but this is inconvenient and usually does not show all the same data.

A better solution was needed.

Can I use Field Level Security?

One option would be to use Field Level Security. You could grant access to the Maintenance windows and then create a Field Security ID for every field on the window (except the fields used for navigation) to lock them up.

This sounds great in theory but is a nightmare in practice. Let’s look at the Customer Maintenance window; there are over 500 fields on the RM_Customer_Maintenance form across 8 windows. You would need 500 Field Security IDs created. You would then need to assign those Field Security IDs on a per user and company basis where they were needed.  Let’s say 2 users in 5 companies and we now have 5,000 checkboxes selected. Now let’s add the Address Maintenance form into the equation and the situation just gets worse.

Finally, due to how Field Level Security was written (I know, as I was the original creator), there are situations where locking/disabling a field would fail and the field would become unlocked/enabled again when existing code on the window ran after Field Level Security had locked/disabled the field.

Field Level Security also does not understand Modified windows and is unable to control Modifier Added Fields.

Can I use a Customization instead?

Yes. It would be possible to write a customization to achieve similar functionality to Field Level Security. You could write the code using Visual Basic for Applications (VBA), but this tool has reached “End of Life” and does not work on modern Windows Server platforms. You could write the code in Dexterity, but Dexterity cannot see Modifier Added Fields. You could write this code with Visual Studio Tools but need to run the DAG (Dictionary Assembly Generator) tool to access Modified Windows.

However, all of these tools require specialist development skills and would need to be programmed with the specific list of fields to lock. Dexterity and Visual Studio Tools also require separate development environments and would need files deployed to every workstation and GP restarted each time to test. If an alternate or modified window added fields, those fields would not be handled without changing the code.

Finally, additional handling would be needed to ensure the fields don’t become unlocked/enabled again when existing code runs, and the code would also need some method to know whether it should be applied or not for specific users and companies.

Can I use GP Power Tools Developer Tools?

Yes, you can but you would need some Dexterity skills. You would be able to either list the fields or even use code to get the list of fields from the dictionary files but would still need to know which fields to lock and which to leave. GP Power Tools can work with Modified windows, and so could lock Modifier Added Fields. You would still need additional handling for when existing code runs.

GP Power Tools works inside GP and does not have a separate development environment. It does not need files deployed or GP restarted. GP Power Tools also can have the project assigned using Users and/or Companies, User Classes, Security Tasks, Security Roles or the Security ModAlt IDs.

While GP Power Tools Developer Tools module is the best customization tool for the job, there still must be a better solution.

How Form Control works

When a Form is opened in GP, Form Control checks if there are any Form Control IDs where the base settings resource filter includes that form. The resource filters for the base settings can only include form filters (no window or field settings).

If there are any Form Control IDs valid for the form that is opening, Form Control will read the dictionary resources for the Form with its windows and fields and cache them for the current user and company. The cache is only updated if this is the first time the form has been opened or if the dictionary version information has changed. The cache for Modified windows is updated once per session as Modified windows can be changed at any time and don’t have separate version information.

After the resources are cached, each Form Control ID that meets the base setting resource filter on the form is processed. Each Rule in the Form Control ID is checked to see if any resources in the cache for that form meet the filters for that rule. If so, the rule is applied to all resources that meet the filters. After the rule is processed, the next rule in the sequence will be processed (unless the rule settings to jump to another rule or stop processing are used). After the Form Control ID has finished processing, the next Form Control ID is processed until all Form Control IDs that meet the base settings resource for the form are processed.

There are over 60 rules available which can be divided into 3 classes:

• Field Level Security rules which can be used to replace Field Level Security with a more powerful and easier to maintain system.
• Form Control rules which can be used to apply new functionality such as stripping unwanted characters, formatting fields, validating field values, masking fields, setting default values for fields and much more.
• Developer Tools rules which can be used with the Developer Tools module to apply customizations across multiple forms, windows and fields without needing to create individual triggers for each resource.

More Information

Here are the articles in this series, they will be available after the publishing date:

• 13-Sep-2024: #GPPT Form Control Introduction – Making Maintenance windows Read Only – Part 1
• 16-Sep-2024: #GPPT Form Control Introduction – Making Maintenance windows Read Only – Part 2
• 17-Sep-2024: #GPPT Form Control Introduction – Making Maintenance windows Read Only – Part 3
• 18-Sep-2024: #GPPT Form Control Introduction – Making Maintenance windows Read Only – Part 4

For more information see:

• GP Power Tools Portal: https://winthropdc.com/GPPT
• GP Power Tools Samples: https://winthropdc.com/GPPT/Samples
• GP Power Tools Videos: https://winthropdc.com/GPPT/Videos

Hope you find this information useful.

David

26-Sep-2024: Added GP Power Tools – Form Control Introduction video.

This article was originally posted on https://www.winthropdc.com/blog.