✏️ Explanatory Question

What are the key table and field property best practices when creating a new table in Dynamics 365 Finance & Operations? Explain TableGroup, title fields, important field properties (AllowEdit, AllowEditOnCreate, Mandatory, Visible), and index best practices.

👁 10 Views
📘 Detailed Answer
🟢 Easy
💡

Answer with Explanation

D365 F&O • X++ INTERVIEW

Table & Field Property Best Practices in Dynamics 365 Finance & Operations

Question 28 — TableGroup, title fields, field properties, indexes and system fields done right.

Interview Question

What are the key table and field property best practices when creating a new table in Dynamics 365 Finance & Operations? Explain TableGroup, title fields, important field properties (AllowEdit, AllowEditOnCreate, Mandatory, Visible), and index best practices.

Model Answer (Short)

A well-designed table sets its Label, its TitleField1 / TitleField2, and its TableGroup (which drives caching and classification). Every field should use an EDT or base enum, belong to at least one field group, and have correctly configured AllowEdit, AllowEditOnCreate, Mandatory and Visible properties. System fields such as CreatedBy/CreatedDateTime and ModifiedBy/ModifiedDateTime should generally be enabled. A proper primary index (allow duplicates = No) is set on every table, and where / order-by fields — especially for bulk update_recordset / delete_from — must be indexed to avoid table scans and deadlocks.

Table Property Best Practices

Key table properties

  • The Label property must be set.
  • TitleField1 and TitleField2 should be configured (shown in lookups/headers).
  • TableGroup is required — it classifies the table and drives the recommended CacheLookup.
  • CreatedBy/CreatedDateTime and ModifiedBy/ModifiedDateTime should generally be set to Yes.
  • Use setTmp() to make a table temporary rather than duplicating it (keeps versions in sync).

TableGroup & Recommended CacheLookup

Table group Recommended CacheLookup
MiscellaneousNone
ParameterEntireTable
GroupFound or FoundAndEmpty
MainFound or FoundAndEmpty
TransactionNotInTTS
WorksheetHeader / WorksheetLineNotInTTS
TransactionHeader / TransactionLineNotInTTS

Field property best practices

  • Always base a field on an EDT or base enum — never a raw primitive.
  • Fields holding the same information must share the same EDT.
  • Every field must belong to at least one field group.
  • AllowEditOnCreate — makes a field editable before the record is saved.
  • AllowEdit — makes an existing record editable (usually Yes; set No for system-set fields).
  • Set a field's Label ID when it differs from the EDT label — no free text allowed.
EDIT BEHAVIOUR
AllowEdit = No + AllowEditOnCreate = Yes = editable only on new records

Index best practices

  • Set a primary index (allow duplicates = No) on every table.
  • All where and order-by fields in queries/views should have a supporting index.
  • Bulk update_recordset / delete_from without an index on the where fields causes table scans and can trigger deadlocks.
  • Maintain and source-control indexes in the development environment.

Prerequisites (Rule 5)

  • Visual Studio with the Dynamics 365 developer tools.
  • A custom model / package for your objects.
  • EDTs / base enums created for the fields.
  • A clear understanding of the table's role (parameter, main, transaction, etc.).

Code Example — A cache-friendly find on the primary key

public static AbcSetupTable find(AbcSetupId _setupId,
                                 boolean     _forUpdate = false)
{
    AbcSetupTable setupTable;

    setupTable.selectForUpdate(_forUpdate);

    // Full primary-key equality read (works with Found / FoundAndEmpty cache)
    select firstonly setupTable
        where setupTable.SetupId == _setupId;

    return setupTable;
}

Setting an add-on field only on new records

public void initValue()
{
    super();

    // Field with AllowEdit=No, AllowEditOnCreate=Yes: safe to default here
    this.Status = AbcStatus::New;
}

Indexed bulk update (avoids table scan)

AbcStagingTable staging;

// 'Processed' is indexed, so this set-based update is efficient
ttsbegin;
update_recordset staging
    setting Processed = NoYes::Yes
    where staging.Processed == NoYes::No;   // indexed where field
ttscommit;

Points the interviewer wants to hear

  • Set Label, TitleField1/2 and TableGroup on every table.
  • TableGroup drives the recommended CacheLookup.
  • Every field uses an EDT/enum and belongs to a field group.
  • AllowEdit / AllowEditOnCreate control editability precisely.
  • Index where / order-by fields to avoid scans and deadlocks.

Likely Follow-up Questions

  • How does TableGroup influence caching?
  • What is the effect of AllowEdit=No with AllowEditOnCreate=Yes?
  • Why must where-clause fields in a bulk update be indexed?
  • When should CreatedBy / ModifiedBy be enabled?

Key Takeaway

Solid table design starts with the right properties: set Label, title fields and TableGroup, base every field on an EDT/enum inside a field group, configure edit/visibility flags deliberately, and index all where/order-by fields to keep queries fast and deadlock-free.