Summary

Within the Administration > System Settings component exists a number of advanced system configurations that are used by features across the application. These configuration settings are implemented by the Foundry Health engineering team and were originally designed to be added by IQVIA engineering support teams and further managed by superadmin users.

Also in this This area of ClinSpark is also has a synchronization feature built as a way to ensure certain configurations are properly managed over time. By design, this feature set is not visible to or accessible by customers as it is intended for use by Foundry Health engineering and support team members as a support toolfunction.

...

As certain customer environments receive configuration changes or new builds of ClinSpark over time, previously saved system settings are carefully reviewed and updated.

Configurations managed in project source

An incredibly A powerful aspect of ClinSpark is the ability to customize reports and dashboard components in both a modular and controlled way. Customers can even request that Foundry Health develop new or ‘custom’ reports. More details about that process are outlined in this help article.

System configurations also receive regular updates over time as enhancements are routinely made, sometimes necessary with new features that are developed. For example, when improved password reset features were implemented, a new set of configurations were added that allows for the customization of alert messages that are emailed to users. Details about that are here: https://foundryhealth.atlassian.All of these net/wiki/spaces/DOCS/pages/3708617070/Self-service+Password+Reset#Modifying-the-email-template

System configurations are maintained as part of the project source control as developers track updates to them over time. Changes make their way into updated builds of ClinSpark, which are deployed into new or existing environments.

Foundry Health IQVIA maintains ‘least common denominator’ settings that are automatically pushed added to environments upon initial deployment. During customer onboarding these are commonly referred as ‘bootstrapped’ configurations which are provided to all customers by default. In the example of password reset, this would include the default email template used when sending password reset emails, when customers accept that build into an environment.

Synchronization States

The A synchronization feature is available to superadmin users through a set of visual cues and descriptors that reflect the known state of a given configuration. These are important to understand as they serve a different purpose and meaning depending on the state of the environment, and , what actions can be taken against the configuration.

...

Date & Time Last Updated

Each configuration will show a date and time value that’s associated with certain “last updated” context. These date and time values help users know the current state of the configuration, and, if action is necessary to update further.

Database Last Update

This represents the datetime that the setting which is currently saved and active in the system was last updated. If there have not been any manual updates made to this setting, this datetime most likely matches the datetime when the latest build was deployed to that environment.

...

However, if a superadmin user made an update to a configuration (possibly requested in a recent service desk ticket), this datetime would then correspond with the most recent save done against the configuration (same datetime as the ‘save’ audit record).

Configuration Last Update

This represents the datetime when the setting was last updated as it is currently present in the deployed WAR file.

...

Often this datetime corresponds with when the configuration was last changed and updated as part of the project source code. Global configurations that are updated from project source eventually make their way into WAR files that are deployed to environments and made available to customers.

Status messages

Each configuration will display to users a status message indicating if action is required. Within customer environments, each Each configuration should be looked at carefully with each status message to determine what the appropriate action is. If there is ever a question on whether or not a configuration should be modified, seek the assistance of engineering to confirm what exists in the deployed environment and what is in the project source.

Configuration Synchronized

...

This status message indicates that no action is required. It confirms that the currently saved and active configuration within the database matches that of the configuration within the deployed WAR file.

The last update datetimes do not need to match or be in ‘sequential’ order for a config to be properly synchronized. What already exists in the database may not be newer than what is currently available in the deployed WAR.

Update Required

...

This status message indicates that there is possible action needed. The currently active configuration setting in the database may need to be updated with a more recent one found in the deployed WAR.

...

The Import action takes the View(GSP) and Data(Groovy) script values from the configuration present in the deployed WAR file, override the previously supplied values, and offer user a chance to save the changes with an audit reason.

...

Once this action has been completed successfully, users can see now that the setting is synchronized. Old and new script values are maintained in the audit trail, so previous values can be restored if needed.

Component/Setting Not Mapped

...

This status message informs users that a configuration exists in the database, but it’s not mapped to any known configuration within the deployed WAR file. While there may not be any action to be taken for this, the presence of unknown configurations could be addressed with engineering help to determine if any action is required.

...

There may also be customer specific or “one off” requests for things like Dashboard components or Reports that get added to specific environments but not elsewhere. Since these exist as a unique configuration, they may not be mapped to the global configurations maintained within project source.

Save Required

...

This status message alerts Foundry Health users superamins to the fact that a configuration setting exists in the deployed WAR, but it’s not yet saved to the database, and therefore is not visible or accessible to customers.

This is often the result of newly developed global configurations such as reports, dashboard components, or volunteer search functions that become present in newer deployments of ClinSpark, but have not yet enabled for use.

When a configuration requires prompts for save, it should be considered if the customer needs the configuration. Some customers may not need those items as it would not be applicable to their current use of the system, or, they have not yet had the chance to review the specifications of the configuration change before accepting it into their environment.