The recommended way to test Flex configuration changes is for the main Flex configuration to be stored in a source code control repository, such as SVN or GIT, and then for that repository to be checked out by each user on the server to a folder at the same level as the Flex configuration:

The contents of each folder must match the expected Flex configuration structure

This allows each user to work independently on their own configuration without conflicting with other users working on the same files, and for their changes to be merged with others using standard source code control mechanisms for conflict resolution, and for the merged changes to be updated out to other users and the main config folder, using standard change control mechanisms.

For each user to use their configuration they must add a config URL parameter to Flex, for example:

When Flex is opened with this parameter included you will see an additional Reload tool configuration from server button on the title bar of tools which allows configuration changes to be tested without reloading the whole Flex UI. This will close and reopen the tool with the latest changes saved to the server.

It is recommended to use a combination of WinSCP and VSCode for editing files. You can configure WinSCP to use VSCode as its external editor, allowing you to double-click a file in WinSCP to open it in VSCode. After making your changes, just save the file in VSCode, and it will be automatically written back to the server.

VSCode is a feature‑rich editor that provides automatic validation of JSONC files. It displays any errors in the Problems tab, which you should keep open while editing. This allows you to quickly identify and fix syntax errors before saving the file and reloading it in Flex.