Configure `config.json` for DMO-to-DMO Transforms

For data model object (DMO)-to-DMO transforms (transforms that read from and write to DMOs), don’t use the sf data-code-extension script scan command because you must pass the DMO schema. Instead, follow the schema standards to configure the config.json file manually.

This schema example demonstrates the structure of a config.json file for DMO-to-DMO transforms:

Your config.json file must include these root-level properties.

Property	Required	Description
`entryPoint`	Yes	The main script file that is executed when your code extension runs.
`dataspace`	Yes	The data space that contains the DMOs to read from and write to (typically “default”).
`permissions`	Yes	Read and write permissions for data objects.
`dataObjects`	Yes	Schema definitions for each DMO your script writes to.

The permissions object defines which DMOs your script reads from and writes to. It must follow this schema structure.

Schema Requirements:

Include both read and write permissions.
Use dmo for DMOs.
Use different object names for read and write operations.
Every DMO in the write list must have a corresponding schema definition in dataObjects. You don’t have to define schemas for DMOs in the read list.

The dataObjects array contains schema definitions for each output DMO that your script writes to. Each object in the array defines the complete structure of a DMO, including its fields, data types, and primary keys.

Each object in the dataObjects array represents one DMO and must include these properties.

Property	Required	Type	Description
`name`	Yes	String	DMO name. Must match a name in `permissions.write.dmo`.
`category`	Yes	String	Set to “profile”, “engagement”, or “other” (case-insensitive).
`fields`	Yes	Array	Array of field definitions. Include at least one field.
`timeEventField`	Conditional	String	Required when `category` is “engagement”. Name of a `dateTime` field defined in `fields` that holds the event time.
`label`	No	String	Human-readable label.
`type`	No	String	The object type for the schema entry. Set to “dataModelObject” for DMOs.
`description`	No	String	Description of the DMO.

Supported DMO Categories

You can write to DMOs in any of these categories.

profile - Profile data, such as accounts or contacts.
engagement - Time-series engagement data, such as events or interactions. An engagement DMO must include a timeEventField at the object level that names a dateTime field in fields.
other - Data that doesn’t fit the profile or engagement categories.

For an engagement DMO, supply the timeEventField property at the object level and define the referenced field as a dateTime field in the fields array.

Each field in the fields array defines a property of the DMO. Each field must include these properties.

Property	Required	Type	Description
`name`	Yes	String	Field name. Can’t be blank.
`dataType`	Yes	String	Data type. Can’t be blank.
`isPrimaryKey`	Yes	Boolean	Whether this field is a primary key
`label`	No	String	Human-readable label
`keyQualifierFieldName`	No	String	Name of the key qualifier field

Use these data type values in the dataType property for your DMO fields.

text - Text or string values
email - Email addresses
dateTime - Date and time values
number - Numeric values
boolean - True or false values

When defining primary keys for your DMO, use keyQualifierFieldName to reference another field that provides more context for the primary key.

If your script writes to multiple DMOs, define a schema for each one in the dataObjects array. Each DMO must have its own object definition with a complete field schema.

This example shows a complete config.json file that follows all the required schema standards for a DMO-to-DMO transform.

Your config.json file must meet these validation requirements.

Read and write permissions must not be empty.
Dataspace must not be blank.
Don’t read and write the same object.

dataObjects must be present and not empty.
Every DMO in permissions.write.dmo must have a matching schema in dataObjects.
Each object’s name must not be blank.
Each object’s category must be “profile”, “engagement”, or “other”.
Each object with the “engagement” category must include a timeEventField that names a dateTime field defined in fields.
Each object must have at least one field.

Each field’s name must not be blank.
Each field’s dataType must not be blank.
isPrimaryKey must be specified for each field.

These errors occur during package validation when your config.json doesn’t follow the required schema standards.

Error Message	Solution
No DMO schema found	Add `dataObjects` array with schemas for all write DMOs
Some DMO write targets do not have a schema	Ensure all DMO names in `write.dmo` have matching entries in `dataObjects`
Invalid DMO Schema: name missing	Add `name` property to data object
Invalid DMO Schema: invalid object category	Set `category` to “profile”, “engagement”, or “other”
Invalid DMO fields schema	Ensure all fields have `name` and `dataType`
Can’t read and write from/to the same entity	Use different DMO names for read vs write

Currently, all these validation errors surface to the Connect API as error code 2999 (“Unknown error occurred”). The preceding error messages are available in the logs for debugging.

Start with write targets: List all DMOs you write to in permissions.write.dmo.
Create matching schemas: Make sure that each DMO has a corresponding entry in dataObjects with the same name.
Define all output fields: Include all fields that your script writes.
Set primary keys correctly: Identify primary keys and mark them with isPrimaryKey: true.
Match your script output: Ensure field names match what your Python script produces.
Use descriptive labels: While optional, labels improve readability and debugging.

Configure config.json for DMO-to-DMO Transforms

Supported DMO Categories

Configure `config.json` for DMO-to-DMO Transforms