Ask AI
Skip to main content

Data formats

Dataformats are where you define the contract for the data you want to use within NoCode-X. This is mostly but not limited to use within actions & the built-in database.

If you want to be able to reason with data for example use a certain property of a data in a function within one of your actions you are best of with creating a data-format & mark that data as being of that type.

If you want to store data in the built-in database, you will have to create a data-format. The data you store will have to be created & valid according to the rules within that data-format.

Information​

  • Name: The name of this data-format for recognizability within the NoCode-X platform

  • Description: The description of this data-format for recognizability within the NoCode-X platform

  • Tags: You can create & link tags to ****this data-format for recognizability within the NoCode-X platform

  • Icon: You can choose an icon for this data-format for recognizability within the NoCode-X platform.

Properties​

Define a list of properties each with its own type & with its own specifications.

Action triggers​

  • After creation of data: Executes actions when a piece of data of this data-format is created in the built-in database.

  • After update of data: Executes actions when a piece of data of this data-format is updated in the built-in database.

  • After removal of data: Executes actions when a piece of data of this data-format is removed in the built-in database.

Reserved words: properties, items, noCodeXType​

The keys properties, items, and noCodeXType are reserved by NoCode‑X for data-schema processing. Do not use these exact names as field keys in your schemas or data objects — doing so can cause schema parsing errors and break runtime behavior. If you see unexpected schema errors, first check whether any of these reserved words are used as field names.

Why this matters​

  • These words are interpreted by the platform as schema keywords/metadata. Using them as regular field names collides with the parser and leads to invalid schemas or runtime failures.
  • properties and items are common JSON Schema keywords; likewise noCodeXType is used internally by NoCode‑X. They must be avoided in user-defined field names.
  • Rename fields to unambiguous names, for example:
    • properties → props, metadataProperties, attributes
    • items → elements, listItems, entries
    • noCodeXType → ncxType, platformType, typeHint
  • If you must keep a human-facing label “properties” in UI, store it under a safe key (e.g., display_properties) and map it to the UI label at runtime (do not store raw key properties).

How to find & fix usages​

  • Search your schema files and data for those keys.
  • Rename the key to a safe alternative.
  • Update any consumers/mappers that read/write that key.

Additional information​