In Dynamics 365 Finance & Operations, TableGroup is a design-time classification on a table (and views can also be assigned to a table group). Microsoft describes it as a way to categorize tables according to the type of data they contain, and notes three practical uses. First, it can help define whether the system should prompt users when they update/delete data on pages that use the table as a data source. Second, it can be used to filter records during data export. And lastly, it is a general categorization mechanism for tables/views. More detail are available at https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev….

Separately, TableGroup is also used by Microsoft best-practice rules (CAR/BP checks) as a signal for “this table should probably have a compatible caching strategy,” which is why you see validations like “Main + NotInTTS is invalid.”. You can find out more about the CAR at https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev….

The TableGroup Values

Microsoft documents the current enum values for Finance & Operations in the .NET/X++ API reference for Microsoft.Dynamics.Ax.Xpp.TableGroup. Detail rea available at https://learn.microsoft.com/en-us/dotnet/api/microsoft.dynamics.ax.xpp.t….

Here’s what each value generally means in practice.

Miscellaneous

Use for “Doesn’t fit cleanly anywhere else.” This is typically ad hoc support tables, helper tables, or niche domain tables – anything that doesn’t have a clear place somewhere else. Use caution though as overuse of Miscellaneous is common. If it’s really master/setup/transactional, picking a more specific group makes downstream behaviors and best-practice checks clearer (especially around caching expectations).

Parameter

Use for setup/parameter tables that define how a module behaves. This is typically for Parameter forms, feature switches, module configuration – items like that. This is important because parameter tables are usually read constantly and change rarely which often aligns with “prompt on update/delete” expectations and with cache strategy validations.

Group

Use for grouping/master categories that other records point to. Typically this is stuff like Item group, Customer group, Posting profile group-style concepts.

Main

Use for primary master data (“main entities”). This means stuff like customers, vendors, items, fixed assets – tables that represent “the thing” in the business domain. This is important because Main tables have distinct best-practice expectations (including cache lookup expectations).

Reference

Use for reference/lookup data that is reused broadly. This is typically various codes, types, and lists that many tables reference. 

Transaction

Use for high-volume operational transactions. Typically this is for posted or postable transactions, journals, movements, detail records. This is important because Transaction tables are commonly high-churn and are the classic place where “wrong caching + wrong grouping” becomes a performance and correctness problem—hence the CAR rule checking the TableGroup/CacheLookup combo.

TransactionHeader / TransactionLine

Use for transactional document patterns split into header/lines. Typically this means Sales order header vs sales order lines, etc. (conceptually) but we’ll but them in similar groups with a group for the header or lines. These exist to let tooling and conventions distinguish “document header” vs “detail line” within the broader transactional category.

WorksheetHeader / WorksheetLine

Use for work-in-progress / unposted working documents (often staged before posting). Typically this is worksheets where users edit, recalc, validate, then post/transfer. Good examples are SalesTable and SalesLine. This matters because Microsoft explicitly calls out WorksheetHeader/WorksheetLine in the cache mismatch rule. they’re treated similarly to Transaction for validation purposes.

Worksheet

Use for worksheet-style tables that aren’t explicitly split into header/line or where a single-table worksheet pattern is used. 

Framework

Use for system/framework-supporting tables which you can think of like plumbing data rather than business data. Typically for stuff like framework metadata, runtime support, infrastructure-ish tables.

Staging

Use for staging/import/export style tables especially data management / integration flows. As the name implies, this is for staging of and processing of data, especially in the context of a DMF or integration workload.

How To Choose

Use this mental model:

Does it configure behavior? Parameter

Is it a category/bucket other records point to? Group

Is it a first-class business entity? Main

Is it “code table / lookup data”? Reference

Is it operational volume data? Transaction

Is it editable “pre-posting” work? Worksheet (or WorksheetHeader/Line if it’s a document pattern)

Is it raw import/export landing data? Staging

Is it platform plumbing? Framework

If no fit then Miscellaneous

And then sanity-check it against Microsoft’s best practice rule logic by running the CAR report (https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev…).

Why You Should Care

Microsoft explicitly ties table groups to whether the system can prompt users on update/delete operations from forms as well as the platform uses TableGroup to validate other design choices (notably cache lookup).