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
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 |
|---|---|
| Miscellaneous | None |
| Parameter | EntireTable |
| Group | Found or FoundAndEmpty |
| Main | Found or FoundAndEmpty |
| Transaction | NotInTTS |
| WorksheetHeader / WorksheetLine | NotInTTS |
| TransactionHeader / TransactionLine | NotInTTS |
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.
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_fromwithout 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.