Data Flexibility

Learn how to expand and customize your configure8 instance data models

configure8 Data Flexibility allows you to extend the system's current data model schemas and create new ones.

If you want to extend your default configure8 data, there are two options:

1. Extend the system with already existing data types

If you want to add one of the following entities to another entity:

  • Application

  • Environment

  • Library

  • Manifest

  • Person

  • Repository

  • Resource

  • Service

  • Team

You can easily extend that data by following these steps:

  1. Go to Add Settings -> Schemas -> Add Schemas.

  2. Select the Type of entity you want to extend from the list above.

  3. Provide a name, for instance if you want to extend Services: "ExtendedServices". You can use the same name as Identifier.

  4. Don't add anything to the Data Model section.

  5. Add a Relation to the entity you want to add to this.

    1. Select Type, for instance, "Person".

    2. Add a name, for instance "BusinessOwner".

    3. Add a display name, for instance "Business Owner".

    4. Select the display Settings for the Service side:

      1. Toggle the first option to show the BusinessOwner field on the Services table.

      2. Toggle the second option to show the BusinessOwner field on the Service page.

    5. Add the Foreigner Name field, for instance "BusinessOwner".

    6. Add the Foreigner Display Name, for instance, "Business Owner".

    7. Select the display Settings for the Business Owner side:

      1. Toggle the first option if you want to show the Services field on the BusinessOwner tables (Only available for One to Many or Many to Many relationships).

      2. Toggle the second option if you want to show the Services field on the people page.

    8. Select the relation type. In this case, Many to One, as many services can have one but only one BusinessOwner.

You can only extend a system schema once, so any other change or relation you want to add should be made in the same extended schema.

2. Create new data types and relate them with current system entities

You can also create new base schemas to model your specific data types and create multiple relations from this to all other catalog entities.

Check the full docs below on adding new schemas or look at our samples here.

Adding a Schema

To add a new schema to your organization, go to Settings -> Schemas -> Add Schema:

Schemas can only be added and edited by Administrators

1. Details


Defines the general type of entities that can be created or extended in our system.

  • Application

  • Base

  • Environment

  • Library

  • Manifest

  • Person

  • Repository

  • Resource

  • Service

  • Team

You can only extend the currently existing system schema for the application, environment, service, library, manifest, person, repository, resources, service, and team.

You can only add a new schema for those types once; to add any other attribute or relation, you just need to edit the existing one.


Defines the specific domain of the entity that you are creating. Sub-types only exist for:

  • Base

  • Resource

You can have multiple schemas with different sub-types for Base and Resources types.

You can then extend that schema by using the same subtype in a new one. This will import all data fields from the original base schema.


Name that the user will see in the User Interface.

The name can be up to 150 characters.


An identifier is a unique identifier or your schema, so you won’t be able to use it twice. This is used in your schema URL, for instance "domains" would be acessible in

Identifier is auto-generated based on the Name, but you can change it if needed clicking on the lock icon.

Identifier can be "A-Z" , "_","-" and "0-9".

You can select a logo for your schema. This logo will be displayed in the Schemas table.


Add a description to explain for other Admins what is this schema about.

2. Data model

Form JSON Schema

This field is not required, but it´s used to add more data fields and data field validations to the schema. It can be used to validate inputs that are pushed via the public API or directly in the UI for the new fields.

It is not required as we already have some default fields for each new schema, which you can check in the System Inherited Data Model field below. If you want to add more fields, then you should add it here.

  "$id": "",
  "title": "Snyk Issue",
  "description": "Snyk Issue",
  "type": "object",
  "required": [
  "properties": {
    "severity": {
      "description": "",
      "type": "string"

You can check the full supported syntax here.

Data Model JSON

This field is not required and it's used to add columns to the schema entity tables. By default no field will be displayed in the columns, not even the default ones from System Inherit Data Model. If you want to add new fields than you should add those properties here. For instance:

    "columnName": "Severity",
    "name": "severity",
    "calc": "details.severity",
    "hidden": false
  • columnName: The name that will be displayed on the table.

  • name: Property name in the entity JSON.

  • hidden: if you want hide this field in the tables. For instance if you just want to use it on the calculations but not show in the table.

  • calc: from where you want to take the value. Complex operations can be performed here.

Check the full calculated properties docs and samples here.

System Inherited Data Model

View-only system schema for the selected "Type" that is inherited by default from configure8.

The additional Data Model JSON fields will be merged with this at the end of the process. But we will always show here the system original one.

3. Relations

Here we can adding relations from multiple data types and fields into this schema.

  • Application

  • Environment

  • Library

  • Manifest

  • Person

  • Repository

  • Resource

  • Service

  • Team

  • Custom Schemas

Target schema we want to make a relation to this schema.


The property name of this entity is in the scope of this schema.

This property will need to pass when pushing data via the API.

This is also the identifier for the relation when doing Custom Calculated Properties or Custom Data Scorecard Check. Note that the relationship has two sides, so you need to know from where you start the relationship "navigation". Scorecards will always be from the service side. Calculated properties will be from the schema you add to the new column.

Display Name

The UI name of this entity is in the scope of this schema.

Display settings

Toggle - Show this relation in the entity table columns. For instance:

Toggle - Show this relation on the entity detail page. For instance:

Foreigner Name

The property name of this entity is in the scope of the other entity to which it's related.

Foreigner Display name

The UI name of this entity in the scope of the other entity it's related.

Foreigner Display settings

Toggle - Show this relation in the foreigner entity table columns.

Toggle - Show this relation in the foreigner entity detail page. For instance:

Relation Type*

Relation Type will define how these two entities relate to each other. These are the available options:

  • One to One: Every entity has one foreign entity and vice versa.

  • One to Many: One entity can have many foreign entities.

  • Many to One: Many entities can have just one foreign entity.

  • Many to Many: Many entities can be related to many foreign entities.

4. Tabs


After saving your schema, you are able to add and configure tabs that show up on an entity's detail page at the top of the page:

Currently the "Overview" tab will still show up for service entities and still allows configuration of plugins as it has been before

Creating/Configuring A Tab

Adding a tab will allow you to configure a tab's name & description:

Adding/Configuring Widgets

And then you can click "Add Widget" and select a widget. This list includes all of our preconfigured schema widgets, as well as any schema widgets you may have added and a "Custom Widget" option for ultimate flexibility.

After selecting a widget, you can configure the widget.

This is an example of adding a schema widget:

And an example of configuring your own custom widget:

5. Custom Widgets

This section allows you to associate custom widgets with a particular schema. These widgets can be defined in one place (inside the schema) and used across different services.

Configuring custom schema widgets

To create a new custom schema widget, click Add Widget under the "Custom Widgets" heading:

This will open an empty dialog with the custom widget editor:

Define your custom widget (see the documentation on creating a custom widget), and you'll be able to use it when you go to add a widget to the service:

Overriding widgets

When you edit a custom schema widget on the services page, you will be presented with an empty code editor. You can override any properties of the original schema widget, but they will only be overridden for that instance of the widget. This allows some customization per service without having to copy/paste configurations between services.

We suggest that you use this feature minimally since it can be prone to breaking when editing the schema widget in the future.

Last updated

Copyright © 2023 configure8, Inc. All rights reserved.