Object Settings

When creating an Object, you'll configure various settings that control its behavior, organization, and data management. This guide explains each setting in detail.

Required Settings

Object Name

The unique identifier for your Object. This name is used throughout the system to reference the object.

Requirements:

• Must be unique across all Objects
• Cannot be changed after creation
• Use descriptive, PascalCase names (e.g., "Customer", "Order", "Product")

Best Practices:

• Use singular nouns (Customer, not Customers)
• Be specific and clear (CustomerAccount, not Account)
• Avoid special characters and spaces
• Keep names concise but descriptive

Example: Customer, Order, Product, Invoice

Description

A human-readable description that explains what the Object represents and its purpose in your system.

Requirements:

• Required field
• Can be updated after creation
• Should clearly explain the object's purpose

Best Practices:

• Write clear, concise descriptions
• Explain the business purpose, not just technical details
• Include examples of what data will be stored
• Keep it to 1-2 sentences when possible

Example: "Customer information and contact details for managing customer relationships and transactions"

Optional Settings

Business Key

A field name that serves as a unique identifier for display purposes. The business key field is used when displaying records in lookups, dropdowns, and related record views.

How It Works:

• References a field name in your schema (e.g., "email", "name", "code")
• Must be a field that exists in your Object schema
• Used for user-friendly record identification
• Helps users identify records without seeing UUIDs

When to Use:

• When you have a natural unique identifier (email, product code, SKU)
• For better UX in lookup fields and related record displays
• When records need human-readable identifiers

Example:

• For Customer Object: email or customerNumber
• For Product Object: sku or productCode
• For Order Object: orderNumber

Note: The business key field should ideally be unique or have a unique constraint in your schema.

Object Type

Defines the category and behavior of the Object. Each type has different characteristics and use cases.

Default: PERSISTENT

Best Practices:

• Use PERSISTENT for most business data
• Use TRANSIENT for temporary or workflow-specific data
• SYSTEM objects are managed by the platform
• EXTERNAL objects are synced from external connections

Tags

Labels for organizing and categorizing Objects. Tags help you filter, search, and group related objects.

How It Works:

• Multiple tags can be assigned to an Object
• Tags are case-sensitive
• Use tags to group related objects
• Filter Objects by tags in the UI

Best Practices:

• Use consistent naming conventions (lowercase, kebab-case, or camelCase)
• Create meaningful categories (e.g., "customer", "sales", "inventory", "finance")
• Use tags for cross-cutting concerns (e.g., "core", "integration", "reporting")
• Keep tag names short and descriptive

Example Tags:

• customer, sales, core
• inventory, warehouse, logistics
• finance, billing, payment
• integration, external-api, sync

Use Cases:

• Grouping related Objects for easier navigation
• Filtering objects in lists and reports
• Organizing objects by business domain
• Identifying objects for specific integrations

Enable Audit

Enables audit trail tracking for all changes made to MData records in this Object.

How It Works:

• When enabled, all create, update, and delete operations are logged
• Audit logs capture who made the change, when, and what changed
• Audit history is stored separately and can be queried
• Useful for compliance, debugging, and change tracking

When to Enable:

• For important business data (customers, orders, financial records)
• When compliance or audit requirements exist
• For data that requires change tracking
• When debugging data issues is important

When to Disable:

• For temporary or transient data
• For high-volume, low-value data
• When storage optimization is critical
• For system-generated data

Note: Audit trails consume additional storage. Enable only for objects where change tracking is necessary.

Org Enabled

Controls whether MData records are scoped to the organization (multi-tenant isolation).

How It Works:

• When enabled (default): Records are filtered by organization ID
  • Each organization only sees its own data
  • Queries automatically filter by organization
  • Supports multi-tenant data isolation
• When disabled: Records are shared across organizations
  • All organizations can access the same data
  • No automatic organization filtering
  • Useful for shared reference data

Default: true (enabled)

When to Enable (Default):

• Customer-specific data (customers, orders, invoices)
• Organization-specific configurations
• User data and preferences
• Most business data

When to Disable:

• Shared reference data (countries, currencies, product catalogs)
• System-wide configurations
• Global lookup tables
• Data that should be accessible to all organizations

Example Use Cases:

• Enabled: Customer records, orders, invoices (each org has its own)
• Disabled: Country list, currency codes, product categories (shared across all orgs)

Important: Changing this setting after creation may affect data access. Plan your multi-tenant strategy before creating Objects.

Import Schema

Import field definitions from an Excel (.xlsx, .xls) or CSV file instead of manually adding fields.

Supported File Formats

• Excel: .xlsx, .xls
• CSV: .csv

File Format

The import file should contain columns:

• Name: Field name (required)
• Title: Display name for the field
• Description: Field description
• Type: Field type (string, number, date, etc.)
• Enum: Enum values (for picklist fields, comma-separated)

Import Process

1. Click "Select File to Import Schema"
2. Choose an Excel or CSV file
3. Review the imported fields
4. Click "Import Schema" to apply

Use Cases

• Migrating schemas from other systems
• Bulk field creation
• Standardizing field definitions across Objects
• Importing predefined field templates

Download Template

Use the download icon to get a template file with the correct format for importing.

Settings Summary

Best Practices

1. Naming: Use clear, descriptive names following naming conventions
2. Descriptions: Always provide meaningful descriptions for maintainability
3. Business Keys: Set business keys for better UX in lookups and displays
4. Tags: Use consistent tagging strategy for organization
5. Audit: Enable audit for important business data only
6. Org Enabled: Plan multi-tenant strategy before creation
7. Object Types: Choose the right type based on data lifecycle
8. Import Schema: Use import for bulk field creation or migrations

Related Introduction

• Field Types - Complete reference for all field types
• Object Relationships - Creating relationships between Objects