View Categories

Object and Attribute Management

Overview #

The Object Manager and Attribute Manager in DnXT Administrator provide powerful extensibility tools for customizing the DnXT data model to match your organization’s specific requirements. The Object Manager lets you define custom object types with their own schemas, fields, and relationships, while the Attribute Manager controls the planning and eCTD attributes used throughout submission workflows.

Together, these tools allow administrators to extend DnXT beyond its built-in entity types (companies, products, submissions) to capture any additional structured data your regulatory processes require.

Key Concept: Object Manager defines what types of data objects exist in the system and their schemas (fields and data types). Attribute Manager defines which attributes are available for submission planning and eCTD metadata across workflows.

Object Manager #

Accessing Object Manager #

  1. Log in to DnXT Administrator.
  2. Click Object Manager in the left sidebar.
  3. The Object Manager view opens with two tabs: Object Types and Database Tables (Database Tables is visible to Tenant Admin users).

Object Types Tab #

The Object Types tab uses a master-detail layout with an object type list on the left and a schema editor on the right.

Object Type List (Left Sidebar) #

The left panel displays all defined object types. You can filter the list by:

  • Application — Filter to show object types for a specific DnXT application (Publisher, Reviewer, Admin)
  • Search — Type to search object types by name

Click an object type to load its schema in the right panel.

Schema Editor (Right Panel) #

The schema editor displays the fields that make up the selected object type. Each field represents a data column for that object type. The schema editor shows a table of fields with the following columns:

Column Description
Field Name The internal name of the field (used in code and APIs)
Type The data type of the field
Title The display label shown in the UI
Required Whether the field is mandatory when creating/editing records
System Whether the field is a system-defined field (cannot be deleted)

Field Types #

DnXT supports the following field data types:

Type Description Example Use
STRING Short text value Name, code, identifier
NUMBER Numeric value (integer or decimal) Quantity, version number, priority
BOOLEAN True/false value Is active, is required, is approved
DATE Date only (no time component) Approval date, expiry date
DATETIME Date and time combined Submission timestamp, last modified
TEXT Long text / multi-line text Description, notes, comments
SELECT Dropdown selection from predefined options Status, category, priority level
LOOKUP Reference to a record in another object type Company reference, product reference
OBJECT_REF Reference to a specific object by ID Parent record, linked entity
ARRAY A list of values Tags, multiple selections, list of codes

Creating a New Object Type #

  1. Click the Add button (or +) above the object type list.
  2. Enter the Object Type Name (e.g., “Regulatory Contact”, “Meeting Record”).
  3. Select the Application this object type belongs to.
  4. Click Save. The new object type appears in the list.

Adding Fields to an Object Type #

  1. Select the object type from the list.
  2. In the schema editor, click Add Field.
  3. Enter the field details:
    • Field Name — The internal identifier (use camelCase, e.g., meetingDate)
    • Type — Select from the available field types
    • Title — The display label (e.g., “Meeting Date”)
    • Required — Check if the field is mandatory
  4. For SELECT fields, define the list of available options.
  5. For LOOKUP fields, specify the target object type to reference.
  6. Click Save.
Warning: Deleting a field from an object type schema will permanently remove that field’s data from all existing records of that type. Always verify that a field is no longer needed and consider exporting the data first before removing a field.

Sub-Sections of the Object Type Detail #

Below the schema editor, each object type has additional configuration sections:

List Columns Config #

Define which fields appear as columns when this object type’s records are displayed in a table view. You can reorder columns, hide fields from the list view, and set default sort order.

UI Locations #

Configure where in the DnXT interface this object type’s records can be viewed and edited. Options include adding the object type as a tab in the Metadata Manager, as a panel in specific views, or as a standalone module.

Relationships #

Define relationships between this object type and other object types. Relationships can be:

  • One-to-Many — One record of this type relates to many records of another type
  • Many-to-Many — Records of both types can be associated with multiple records of each other

Workflows #

Associate a workflow (from the Workflow Manager) with this object type. When a workflow is associated, records of this type will follow the defined workflow states and transitions.

Managing Records #

Once an object type has been defined with its schema, you can create and manage records of that type. The records management section provides:

  • Column Chooser — Select which columns to display in the data table
  • Data Table — View all records of this object type with sorting, filtering, and pagination
  • Add/Edit/Delete — Create new records, edit existing records, or delete selected records

Database Tables Tab #

The Database Tables tab (available to Tenant Admin users) provides a low-level view of the database tables that store object type data. For each table, you can see:

  • Table Name — The database table name
  • Record Count — The number of records in the table
  • Field Info — Column definitions and data types
Tip: The Database Tables tab is primarily for troubleshooting and advanced administration. For normal operations, use the Object Types tab to manage schemas and records.

Attribute Manager #

Accessing Attribute Manager #

  1. Log in to DnXT Administrator.
  2. Click Attribute Manager in the left sidebar.
  3. The Attribute Manager view opens with two tabs: Planning Attributes and ECTD Attributes.

Planning Attributes Tab #

Planning Attributes are custom fields used in the submission planning process. They allow you to capture additional metadata about dossiers and submissions that is specific to your organization’s planning workflow.

Planning Attributes Table #

The table lists all defined planning attributes with toolbar actions:

  • Add — Create a new planning attribute
  • Delete — Remove selected attribute(s)
  • Refresh — Reload the table
  • Export — Download attributes as CSV

A Scope Filter above the table lets you filter attributes by their scope (where they apply in the system).

Planning Attribute Detail Panel #

Click an attribute to open its detail panel with the following fields:

Field Description
Name The internal attribute name
Label The display label shown in the UI
Value Default value for the attribute
Description A description of the attribute’s purpose
Type Data type: Select, String, Date, Boolean, Number, UserList, List
Scope Where the attribute applies (Dossier, Submission, Document, etc.)
Enable Toggle to enable or disable the attribute
Automate Toggle to allow automatic population of the attribute value

Creating a Planning Attribute #

  1. Click the Add button.
  2. Enter the Name (internal identifier, use camelCase).
  3. Enter the Label (display name, e.g., “Target Filing Date”).
  4. Select the Type (e.g., Date for a target date, Select for a dropdown).
  5. For Select or List types, define the available options.
  6. For UserList type, the attribute will present a dropdown of system users.
  7. Set the Scope to determine where the attribute appears.
  8. Toggle Enable to make the attribute active.
  9. Toggle Automate if the attribute should be auto-populated by system rules.
  10. Click Save.
Tip: Planning attributes with the UserList type are ideal for assigning responsibility — for example, a “Responsible Specialist” attribute that lets users select from the user directory, or a “Reviewer” attribute for assigning review tasks.

ECTD Attributes Tab #

ECTD Attributes are the standard metadata fields defined by the eCTD specification. Unlike planning attributes, which are fully customizable, ECTD attributes are predefined by the eCTD standard and cannot be added or removed. However, administrators can control:

  • Enable/Disable — Toggle whether each attribute is active in the system
  • Default Value — Set a default value that is pre-populated when creating new submissions

ECTD Attributes Table #

The table is read-only in terms of adding or deleting attributes. Toolbar actions include:

  • Refresh — Reload the table
  • Export — Download the attribute list as CSV

Editing ECTD Attributes #

  1. Click an attribute in the table to select it.
  2. Toggle the Enable/Disable switch to control whether the attribute is active.
  3. Set or modify the Default Value that is pre-populated for new submissions.
  4. Click Save.
Important: Disabling an eCTD attribute does not remove it from existing submissions — it only hides it from new submission forms. Be cautious about disabling attributes that may be required by your target regulatory authority.

How Object Types and Attributes Work Together #

Object types (from Object Manager) and attributes (from Attribute Manager) serve complementary purposes:

Feature Object Manager Attribute Manager
Purpose Define entirely new entity types with custom schemas Add custom fields to existing submission entities
Scope Creates standalone objects with their own tables and views Adds fields to existing dossier/submission/document records
Use Case Custom entity types (meetings, training records, etc.) Custom metadata on submissions (target date, responsible person)
Flexibility Full schema definition, relationships, workflows, UI locations Simple field-level customization with enable/automate toggles

Best Practices #

Plan Before Building #

Before creating custom object types, document the data model you need. Define the fields, relationships, and where the data should appear in the UI. This prevents schema changes later, which can be disruptive.

Use Meaningful Names #

Field names (the internal identifiers) should be descriptive and follow a consistent naming convention (camelCase is standard). Field titles (the display labels) should be clear and user-friendly.

Start with Planning Attributes #

If you only need to add a few extra fields to dossiers or submissions, Planning Attributes are simpler and faster to set up than full custom object types. Reserve Object Manager for genuinely new entity types.

Test in a Non-Production Tenant #

If available, test custom object types and attributes in a non-production tenant before deploying them to your production environment. This helps catch schema issues early.

FAQ #

Can I change a field’s type after creation? #

Changing a field’s data type after records have been created is not recommended, as it may cause data loss or conversion errors. If you need to change a field type, create a new field with the correct type, migrate the data, and then remove the old field.

Do custom object types appear in the Metadata Manager? #

Yes, if you configure the UI Locations setting to include the Metadata Manager. Custom object types can appear as dynamic tabs alongside the built-in entity tabs.

Can I export and import object type definitions? #

Object type schemas can be viewed and documented through the UI, but there is no built-in export/import for schema definitions. Use the Export function on records (not the schema itself) to back up data.

What is the difference between LOOKUP and OBJECT_REF field types? #

LOOKUP creates a user-friendly reference with a dropdown picker that shows records from the target object type. OBJECT_REF stores a direct reference by ID, which is more lightweight but less user-friendly. Use LOOKUP when users need to select references through the UI; use OBJECT_REF for system-managed references.

Can I use Planning Attributes in workflows? #

Yes. Planning attributes can be referenced in workflow rules and triggers. For example, you could create a rule that only allows a transition when a “Target Filing Date” attribute has been set, or trigger an email when an attribute value changes.

Related Articles #

Powered by BetterDocs

Leave a Reply

Your email address will not be published. Required fields are marked *