Maintenance of customisations and custom integrations

This article provides advice on how your institution can maintain its Elements customisations. For example, to ensure they continue to function properly after Elements version upgrades. Common customisations include:

• Custom dashboards (either in the old Manage Dashboards part the system, or in the new post-v6.1 Reporting Hub)

• Custom SSRS reports (either in the old Registered Reports part the system, or in the new post-v6.1 Reporting Hub, or both)

• Customisations to the Reporting Database, such as custom indexes, tables and views, and configuration of SQL Server Change Tracking functionality

• Custom API integrations

• Custom Reporting Database integrations

• Custom data feeds implemented via file drop to Symplectic's shared secure FTP server

• Custom scripts implemented using the "Custom script" or "Google analytics" administrator web pages

Your institution might have developed customisations itself, or commissioned Symplectic or a third party to develop them for you, or perhaps otherwise have obtained copies of useful customisations such as dashboard or report definitions from the Elements community. These are all encouraged, and are all great ways to make best use of your Elements system.

Regardless of the origin of a customisation (even if it was obtained by cloning a stock dashboard or report from a current or older version of Elements) no customisation forms a part of the Elements product. They are always owned and maintained by your institution.

The following responsibilities remain with your institution:

• Initial implementation. You are responsible for ensuring the customisation is not used in a production environment until you are satisfied that it performs adequately, processes data securely and does not compromise or degrade stock functionality in Elements.

• Maintenance and testing. You are responsible for testing your customisations and maintaining them in working order as you make changes to Elements itself, including through Elements version upgrades.

• Fixing issues. You are responsible for fixing any issues caused by your customisations. On request, Symplectic may be able to provide support under the chargeable "Client Customisation & Environment Support" area of the Service Level Agreement.

On occasion, a newer version of Elements may make a breaking change to something upon which your customisation depends. Examples include:

• For custom dashboards, SSRS reports and Reporting Database integrations and customisations, the structure of the Elements Reporting Database (or Elements Analytics Database) may occasionally feature a breaking change. Such changes are announced in Elements release notes at the time of release, along with step-by-step technical advice on how to alter custom SQL queries to work against the newer version of the Reporting Database.

• For custom API integrations, a long-obsolete backwards-compatible endpoint against which you developed your integration may have been retired. Retirement of obsolete API endpoints does not occur for at least two years after their obsolescence, which provides your institution with plenty of time to plan a migration to the latest endpoint. Please see the End of Support Announcements page for more information. Removal of legacy API endpoints is also announced in Elements release notes at the time of release, and step-by-step technical advice on how to alter older API integrations to work against later API compatibility endpoint versions is released with the API documentation for each new endpoint version.

• For custom scripts, the structure of the Elements user interface may change between versions of Elements. Without proper maintenance, your scripts may no longer function as desired.

In addition, any changes your institution makes to the set of custom data fields configured in your Elements instance may result in structural changes to the Elements Reporting Database and/or data changes in API responses/requests, since the columns and tables in the Reporting Database, and the data exchanged using the API are named after such fields. This may affect data feeds and other customisations that use the modified data fields.

It is your institution's responsibility to determine the need for, and then make, any alterations to its customisations that may become necessary as a result of changes in Elements itself, whether associated with version upgrades or alterations to system configuration, and whether your customisation was authored directly by your institution, authored by Symplectic, or authored by a third party, on your behalf.

You should ensure that testing the ongoing viability of your customisations, and making any necessary alterations, is a standard part of your project planning when upgrading a production instance of Elements to a newer version.

An important part of reviewing your customisations is ensuring your approach to sharing data is still secure given any new data privacy features or behaviours introduced in newer versions of Elements. Please see, for example, the following articles for more information:

• Dashboard security and data protection

• Cookie consent management