DIE Applications

Application Schemas

Whenever you select an application, DIE will automatically check the integrity of the application's schema for any errors or potential issues. If any errors and/or potential issues are found, a modal containing this information will be displayed. If any errors are found they must be fixed in Quick Base before you can use this application within DIE. If any potential issues are found, it is suggested to fix these in Quick Base, however you will still be able to use the application within DIE.

Automations

Automations allow you to configure automatic DIE imports. When a file (data feed item) gets added to Box.com, DIE will compare automations to see if the data feed item matches any automation file values. If a data feed item matches multiple automation file values, only the first automation file value that matches is used and only one import is performed. The order in which the data feed item is compated to automation file values is as follows:

1. Exact file match (Data Feed.json)
2. Partial file match (Data *.json)
3. File extension match (*.json)
4. Any file (*)

To manage application specific automations, click on the  Automations button for an application. On this screen you will be able to view existing automations as well as add, edit and delete automations. An automation consists of two parts, the DIE configuration to use as well as the file. Some examples file values are: "Example Data Feed.xlsx", "Example*.xlsx", "*.xlsx" and "*".

Configurations

You can view information about DIE configurations by clicking on the  Configurations button for a specific application. You can also delete configurations, however for a configuration to be successfully deleted it must not exist in Quick Base.

You can also clone configurations from another application by clicking on the  Clone Configurations button. Then simply select the application you which to clone configurations from. Configurations with the same name will not be overwritten in the current application.

Linked Records

You can view how DIE will attempt to link records, as well as the fields it looks for in each table by clicking on the  Linked Records button for a specific application. You can also view any broken or missing linked records.

Broken Linked Records

Broken linked records are records that contain a reference to another record which does not exist. Broken linked records are seperated by table and broken references are highlighted in red. You can fix broken records by clicking on the  Fix Linked Records button, this will delete all broken records in the selected table if the table is an in between table (Linked Shots and Product Data, Linked Samples and Shots, etc.). If the selected table is not an in between table (Samples, Shots, etc.), all broken records will be updated, resetting the broken references.

Missing Linked Records

Missing linked records are records which should contain a reference to another record but do not. Missing linked records are seperated by table and missing reference fields are highlighted with a red background. You can download a CSV of all missing linked records for every table by clicking on the  Download as CSV button.

Purge

You can easily purge an application by clicking the  Purge button for a specific application. You will then be prompted with a modal which will allow you to select which tables to purge.

Field Mappings

Field mapping relationships are organized by the remote table they belong to. Every mapping relationship includes two components: local field and remote field. The local field is constructed using any combination of data feed items, formulas and/or text. Any data feed items in the local field must be wrapped in square brackets. Any formulas in the local field must be wrapped in curly brackets. Some examples of a local field are: "[category]-[sku]", "0[sku]", "shot pending", "[model_name]_season_[Season]", "season_{date(Y-m-d)}" and "{lowercase([season])} season". The remote field consists of one or more application table fields. While one local field can be mapped to multiple remote fields, each remote field can only have one local field associated to it.

You can omit empty local fields by toggling the "Omit Empty" option, if the local field value is empty then the remote field will not be changed if the "Omit Empty" options is set to "Yes".

For every remote application table there are currently four actions you can perform. These actions are only applied against the field mappings contained within the selected table.

On top of the actions which can be performed, there are also currently two filters which allow you to show only field mapping relationships which match the filter's criteria.

Field Types

All local fields which are contained in one or more field mapping relationships are available to configure in the fields tab (any local fields that do not exist in any field mapping relationships will be omitted). Any local fields which are mapped but are not in the data feed (for example when loading an existing mapping configuration) will show up at the top of the list with a red exclamation mark. You can mark a local field as required by toggling the required switch. As well as making a field required, you can also set the field type and format.

* A list is considered a single data feed item value which is actually multiple values which are delimited.

Formulas

Date Formats

All date formats are case sensitive.

Logic Configuration

The logic configuration is comprised of two different type of tasks: "Default" and "Conditional". Default tasks contain only actions which will always be performed on every data feed item on import. Conditional tasks contain local and remote conditions on top of actions. These actions are only performed on the data feed item if both the local and remote conditions are met.

Task Actions

Task actions are comprised of two parts: the operation and the remote application table to apply the operation to. For default tasks, the only operation available is insert.

Task Conditional Behaviors

Both local and remote conditions have a behavior, there are currently two types of behaviors:

Local Conditions

Local conditions are made up of three parts: local field, operator and values. The local field is compared against the values specified, which are comma separated, using the defined operator.

Remote Conditions

Remote conditions consist of four components: remote application table, remote field, operator and local field. The local field is constructed using any combination of data feed items and/or text (same as the local field in the field mapping relationship).

* Negative operator.

Remote conditions are grouped together by the remote application table. If the remote condition behavior is "All" the conditions are joined together using "and". If the remote condition behavior is "Any" then the conditions are joined together using "or".

For a remote condition to be considered as met, records must be returned from the remote application table which the remote conditions were applied against. There are two exceptions to this rule:

1. If the task action is an "Insert or Update" and no records are returned, then that remote condition will be considered met.
2. If a remote condition contains a negative operator ("Is Not", "Is Not Blank" and "Does Not Contain"), then the condition will only be considered met if no records in the remote application table match the condition. For example, "color is not black", will be converted to "color is black" and if no records are returned, then the condition is considered met.

Loading/Saving Configurations

Mapping and logic configurations are loaded and saved independent of each other. Meaning you can use the same mapping configuration across multiple logic configurations and vice versa. When saving either the mapping or logic configuration, the configuration name is compared against existing configurations, if a match is found, then the configuration is updated, otherwise a new configuration is created.

Configuration

You must set the configuration which will dictate the field mappings and logic to use for the import (if you attempt to use a configuration that is pre version 1.5 you will be prompted to update the configuration before the import can be run). You can view a summary of the selected configuration by clicking on the  Configuration Summary button. You can change the default options by clicking on the Advanced Options button. Once you are ready to proceed, click on the  Create Import button to trigger the preparation of the import.

Prepare Import

The import preparation will determine what records will be inserted or updated in the remote application. Once complete, a list of every record that will be either inserted or updated will be shown, along with any new field choices that will be created (if applicable). On top of this, a quick reference summary of details is displayed along with information pertaining to the import (in the panel heading). Once satisfied with the import preparations, click on  Begin Import to trigger the actual import itself.

Run Import

The import will process packet items concurrently. Once a packet has been processed, linked records for every packet item will be generated and compared against current linked records to prevent both duplicate linked records and overriding existing link references.

* Requires more than one record.