Zoomed Image
USA
800 691 9120
UK
01225 704844

Layers and Overrides

xAssets Configuration Guide
Integration and Data Operations with Transformations

Layers and Overrides

xAssets uses a layering system to protect built-in transformations from accidental modification while still allowing full customisation. This page explains how the layering model works, when to create an override, and the consequences of deleting one.

Prerequisites

How Layers Work

Every transformation exists in one of two layers:

Layer Description Editable?
SYSTEM Built-in transformations supplied by xAssets. These implement standard integrations, imports, and internal operations. No -- read-only
CUSTOMER Transformations created at your site. These include any customisations, bespoke integrations, or overrides of system transformations. Yes

Your site always runs in the CUSTOMER layer. When you open a SYSTEM-layer transformation for editing, you see a lock message indicating that it cannot be modified directly:

Screenshot

This protection ensures that product upgrades can safely update system transformations without overwriting your customisations, and that accidental changes to critical integrations are prevented.

Override Transformations

To customise the behaviour of a system transformation, create an override. An override is a CUSTOMER-layer transformation that runs in place of the original whenever the original would normally execute -- regardless of how it was invoked (menu item, schedule, API call, or another transformation).

The key benefits of overrides are:

  1. The original is preserved. The system transformation remains intact and untouched.
  2. Reversibility. If you delete the override, the system automatically reverts to running the original.
  3. Upgrade safety. Product upgrades update the system layer without affecting your override. If the upgrade changes the original's behaviour, your override continues to run as-is.

Warning: Because the override completely replaces the original, any improvements made to the system transformation in a product upgrade will not take effect until you either update your override or delete it to revert to the new system version.

Creating an Override

There are two ways to create an override:

  1. From within the locked transformation -- open the system transformation and click the Create New Override button
button. This creates a CUSTOMER-layer clone of the original, pre-configured to override it. You can then modify the clone as needed.
  1. As a new transformation -- create a transformation normally (see Creating a Transformation) and set it to override the target system transformation using the override field in the transformation header.

In both cases, the override transformation is linked to the original by name, so the system knows to execute the override whenever the original is called.

Deleting an Override

When you delete an override transformation, the system automatically reverts to running the original SYSTEM-layer transformation. No further action is needed. This makes it safe to experiment with overrides -- you can always get back to the standard behaviour.

When to Use Overrides vs. New Transformations

Scenario Approach
You want to modify how a built-in integration works (e.g., change field mapping on the Active Directory import) Create an override of the system transformation
You want to add a completely new integration or custom process Create a new CUSTOMER-layer transformation
You want to add pre-processing or post-processing around a system transformation Create a new transformation that calls the system transformation using RunTransform in an AMSX script

Tip: Before overriding a system transformation, consider whether your change could be achieved through data mapping rules alone. Mapping changes are simpler to maintain and less likely to conflict with future upgrades.