The Elements Reporting Database provides an institution with direct access to the data managed by Elements. It represents the primary data source used by stock and custom reports and dashboards throughout Elements. As you gain experience authoring your own reports and dashboards against the Reporting Database, or to support other reporting use cases, there can arise a desire to customise the Reporting Database to enable it to better serve your particular needs.

Examples might include the need to improve the performance of the rendering of a custom report or dashboard by adding suitable custom indexes to the database, the desire to include additional non-Elements sourced data, or a wish to configure and consume SQL Server Change Tracking functionality in your Reporting Database.

For these reasons, Symplectic has designed the Reporting Database to support certain types of customisation.

This document outlines the types of customisation and the methods of maintaining them that are supported by Symplectic, as well as defining the responsibilities involved in managing your customisations.

In order to maintain the ability of Elements to automatically synchronise data to the Reporting Database, the following types of customisation are not supported by Symplectic and would be in breach of the terms of your licence for use of Elements.

• You must not alter any of the Symplectic-authored code in the Reporting Database, including its stored procedure definitions.

• You must not alter the structure of any of the stock tables (tables created by Elements) in the database, including adding, removing or altering primary keys, columns or constraints, or altering or removing triggers.

• You must not alter any of the data placed in the database by Elements.

• You must not add any new tables, views or other database objects to the "dbo", "meta" or "analytics" schemas unless explicitly supported below.

• You must not create any foreign keys that reference stock tables

Symplectic will be unable to provide support for the continued use of such an altered Reporting Database until the problematic customisations are removed.

Symplectic does not currently support the following features of SQL Server for use by clients:

• SQL Server Replication

Subject to the restrictions above, the following types of customisation are anticipated to be consistent with the ongoing ability of Elements to synchronise data to the stock tables of the Reporting Database:

• New custom views (in a schema other than "dbo", "meta" or "analytics")

• New custom tables (in a schema other than "dbo", "meta" or "analytics")

• New stored procedures (in a schema other than "dbo", "meta" or "analytics") that do not modify data in stock tables

• New (non-unique) indexes on existing stock tables

• New triggers (on new custom tables or existing stock tables) that do not modify data in stock tables

• For Hosted Clients, from Elements v7.1 onwards: Enabling SQL Server Change Tracking on a selection of existing or custom tables.

Customisations can be implemented by developing and executing your own custom T-SQL scripts against the Reporting Database. For Symplectic-hosted versions of Elements, any such scripts must be compatible with all versions of SQL Server supported by the product. See Symplectic Elements End of Support Announcements for SQL Server version support information.

Irrespective of who authors and/or runs your customisation scripts, they are owned by you. It is your responsibility to develop, test, and maintain them, and store master copies of them for backup purposes. In practice, you may commission a third party (even Symplectic) to develop, test and perhaps even host and run your customisation scripts for you, but at all times the ultimate responsibility for management of the scripts remains with you.

Please see the following article for more information:

• Ongoing maintenance of customisations and custom integrations

You will typically wish to apply your scripts to the Reporting Database (or ask Symplectic for support in doing so) whenever you choose to rebuild the tables in the database. You will typically choose to rebuild the Reporting Database after the following events:

• After installing a fresh instance of Elements

• After applying a version upgrade to Elements

• After modifying the data types or fields in Elements

Exactly when you must reapply your scripts depends on what your script actually does. Please consider the following situations:

Some Elements upgrades require the entire Reporting Database to be dropped and then recreated using the Reporting.Setup utility. Obviously, no customisation to the Reporting Database can survive this procedure. You must reapply your customisations after this operation.

The "big red button" on the Reporting Synchronisation management page drops all stock tables in the Reporting Database, recreates them, and refills them with data. This is typically done by your institution whenever you wish to update the reporting table structure (e.g. columns) to reflect custom field alterations you have made in Elements.

Any customisation you have applied to a stock table in the Reporting Database will obviously be lost when pressing this button. This includes any indexes you have added to stock Elements reporting tables, and any opt-in to SQL Server Change Tracking on stock tables.

The Reporting Synchronisation management page allows you to configure an automated schedule for a "full synchronisation" (reloading all data from scratch). This process leaves the structure of all existing tables alone. It merely truncates all data from all stock tables and refills them with fresh data. As such, it will also leave your customisations alone. You do not need to reapply your customisations after this process.

It is your responsibility to make any alterations to your customisation scripts that may become necessary as a result of changes in Elements itself, whether associated with version upgrades or alterations to system configuration that you make. You should ensure that testing the ongoing viability of your customisations is a standard part of your acceptance testing processes ahead of upgrading a production instance of Elements to a newer version.

Customisations that you make to the Reporting Database are not considered to be a part of Elements. Your database customisations will not be preserved during upgrades or installations, or related operations such as system disaster recoveries (for Symplectic-hosted instances of Elements). It is your responsibility to ensure the correct reapplication of your customisations after any such events.

One way to automatically mitigate against the lack of preservation of customisations during upgrade or disaster recovery is to ensure your customisation scripts are run to a regular schedule, such that they automatically reapply your customisations if they are found not to be present.

Please see the following article for more information:

• Ongoing maintenance of customisations and custom integrations

Your customisations might conceivably interfere with the ability of Elements to synchronise data to the Reporting Database successfully, or degrade performance in data transfer either into or out of the database to an unacceptable level.

If either of these situations occurs, the only supported solution is for you to remove or re-engineer your customisations. All Symplectic support required to diagnose interference in the proper functioning of the Reporting Database is chargeable at the standard support rate.

Symplectic does not offer custom database hosting services. You can consider adding new tables to the existing Reporting Database, or hosting your own database on-site or with a Cloud database provider.

Yes. Symplectic will happily consider quoting for services to develop and test your customisation scripts. Alternatively, you can engage a third party, or develop and test your scripts yourselves.

Yes. Symplectic will happily consider quoting for services to host and run your scripts either as a one-off execution or to a regular schedule. Alternatively, you can engage a third party, or host and run your scripts yourselves.

As would be the case if you hosted and ran your scripts yourself, the hosting and running of your custom scripts by Symplectic is performed entirely separately to the hosting and running of instances of Elements. Because of this, it is currently not possible to arrange for the running of your customisation scripts by Symplectic as a part of the process of installing or upgrading of Elements, though you can ask Symplectic to schedule the regular running of your scripts against a nominated instance of Elements. Similarly, if you ask Symplectic to perform alterations to the hosting of Elements (e.g. by commissioning an additional test instance of Elements), you should consider whether corresponding changes to the running of your hosted scripts should also be requested (e.g. by hosting and running copies of your customisation scripts against the new test instance of Elements).

Scripts intended to be run regularly should be developed in such a way that repeated running of the scripts does not cause errors. For example, if your customisation adds new tables to the database and fills them with data, your scripts implementing these customisations should test for the existence of the tables and not attempt to create them again if they already exist.