---
title: "Managing configuration resources and data"
slug: "managing-configuration-resources-and-data"
updated: 2026-06-05T09:40:49Z
published: 2026-06-05T09:40:53Z
canonical: "support.lusid.com/managing-configuration-resources-and-data"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing configuration resources and data

You can use the **Data Management** dashboard in the [Admin Portal](/v1/docs/admin-portal) to:

- Deploy *configuration resources* to domains (see below).
- Replicate domains (coming soon).

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/image-GPZMEVH8.png)

## Understanding LUSID configuration resources

Configuration resources are the transaction types, property types, data types and so on that drive the FINBOURNE platform. [See a full list of resources](/v1/docs/understanding-lusid-configuration-resources).

You can bundle configuration resources into one or more *packages* for deployment to target domains. For example, you might [use the Admin Portal to create](/v1/docs/configuration-import):

- A `core_ibor` package containing transaction types and sides to generate holdings with a particular economic impact.
- A `quote_outliers` package containing task definitions, workers and workflows to automate a data quality check.
- A `broker_feed` package containing schedules, jobs, Drive files and entitlement policies to automate a transaction data load.

Each package is a JSON file that describes a *desired state*. When you [use the Admin Portal to deploy](/v1/docs/configuration-export) a package to a target domain, LUSID infers how to create, update and delete resources in that domain to match the state. Deploying the same package to multiple domains guarantees a consistent result. Note the Admin Portal integrates source control applications (Gitlab and Github) for package files to facilitate change management and recovery.

Resources successfully deployed by the Admin Portal become *managed resources* in the target domain. Note not all resources in a domain need be managed:

- If a resource (for example, a transaction type) is deployed and does not exist in a target domain then it is created as a managed resource.
- If on a subsequent deployment of the same package the same managed resource is found to differ then the target domain is updated to match the desired state.
- If a managed resource is omitted from a subsequent deployment of the same package then it is deleted from the target domain.
- If a resource is found to already exist (unmanaged) in the target domain then the deployment fails with an error.

Note the Admin Portal flags some resources (for example, transaction types and property types) as having *dependencies* (sides and data types respectively). You must include dependencies in a package but [in most cases](/v1/docs/data-management#best-practice-recommendations) you can choose whether they are deployed as managed resources or as *references*. LUSID checks whether references exist in the target domain but does not update or manage them (if they do not exist, the deployment fails with an error).

## Example: Deploying transaction types and sides

Consider the following example, of a target domain with an existing set of unmanaged transaction types and sides, perhaps built-in to LUSID or created by users:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/targetdomain.png)

We want to deploy and subsequently manage two additional transaction types, which between them have dependencies on three sides:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/resourceset (1).png)

We can [create a package](/v1/docs/configuration-import) in the Admin Portal with a deployment ID of `core_ibor` containing:

- `BuyBond` and `SellBond` transaction types and a `CarryAccrual` side as managed resources (in blue above).
- `Side1` and `Side2` as references, since they already exist in the target domain and we do not want to manage them (in red).

When we [deploy](/v1/docs/configuration-export) the `core_ibor` package from the Admin Portal:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/deployment.png)

- `BuyBond`, `SellBond` and `CarryAccrual` are created in the target domain, since they do not already exist, and are labelled as managed resources (in blue).
- LUSID checks that `Side1` and `Side2` exist but does not label them as managed (in black).
- The existing `Buy` and `Sell` transaction types are untouched.

If we subsequently edit `core_ibor` to remove the `SellBond` transaction type:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/resourceset-deleted.png)

The next time we deploy, `SellBond` is removed from the target domain:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/deployment-deleted.png)

## Best practice recommendations

Note the following:

- The Admin Portal does not track resources between packages. The recommended approach is to only ever include a managed resource in a single package. The same resource can be included in other packages as references if needed.
- Do not attempt to deploy *system* resources such as property types in the protected `system`, `internal` and `default` scopes (for example, `Transaction/default/GrossConsideration`). This causes the deployment to fail with an error.
- Where the Admin Portal flags system resources as dependencies (for example, the `system/string` data type for a custom property), they must be included in packages as references. If included as resources, the deployment fails with an error.