✏️ Explanatory Question

What are the key naming conventions in Dynamics 365 Finance & Operations? Explain the customization prefix, the project-per-function rule, how new objects and their child components are named, the extension naming pattern, and the temporary table suffix.

👁 2 Views
📘 Detailed Answer
🟢 Easy
← Previous What are the best practices for sorting result sets in X++? When should you sort, why is order by preferred over index / index hint, and what field types should you avoid sorting on?
💡

Answer with Explanation

D365 F&O • X++ INTERVIEW

Naming Conventions in Dynamics 365 Finance & Operations

Question 33 — Prefixes, project-per-function, new objects, extensions and the Tmp suffix.

Interview Question

What are the key naming conventions in Dynamics 365 Finance & Operations? Explain the customization prefix, the project-per-function rule, how new objects and their child components are named, the extension naming pattern, and the temporary table suffix.

Model Answer (Short)

Every customization object carries a prefix that distinguishes it from standard and third-party objects. Names are always English, descriptive, spelled correctly and used consistently — they must not start with AAA, copyOf, or DEL_ (except for upgrade objects). Internal variables use camelCase. Each function gets its own project named like __. A new object gets the prefix, but its child components (methods, fields) do not. Child components added to standard objects take the prefix; table/object extensions use the . dot notation and end with _Extension. Temporary tables end with the Tmp suffix.

Generic naming rules

  • All names are written in English using logical/descriptive words.
  • Names must be spelled correctly and used consistently.
  • A name must not begin with AAA or copyOf (e.g. no CopyOfStoreReplenishmentParameters).
  • Do not start a name with DEL_ unless it's a table/EDT/enum needed for data upgrade.
  • Internal variables use camelCase (e.g. camelCase).

Project per function

  • Create a Finance & Operations project for each function.
  • Include all objects customized by that function in the project under source control.
  • Name pattern: _ + FDS ID + Function — e.g. XYZ_CM900_CustomFunction.

New objects & child components

  • A new object gets the customization prefix.
  • Its child components (methods, fields) do not get a prefix.
  • New child components on standard/third-party objects take the prefix (e.g. AbcSellableDays).
  • Metadata extension objects (tables, queries, views, EDT, base enum) must carry the prefix per the naming guide.
EXTENSION NAMING
Standard table extension = CustTable.  •  Class = Prefix + Name + _Extension

Temporary table suffix

  • Temporary table names must end with the Tmp suffix.
  • Example: XyzCustVendTransTmp.

Naming Pattern Reference

Item Rule Example
Project (per function) Prefix_ + FDS ID + Function XYZ_CM900_CustomFunction
New object Prefix + descriptive name AbcSellableDays
Child component (new object) No prefix calcTotal()
Table extension TableName. CustTable.AbcExtension
Class extension (CoC) Prefix + Name + _Extension AbcSalesTableType_Extension
Temporary table Name + Tmp XyzCustVendTransTmp

Prerequisites (Rule 5)

  • Visual Studio with the Dynamics 365 developer tools.
  • A custom model / package with a defined prefix.
  • The project's naming conventions agreed before development starts.

Code Example — New object with prefix, unprefixed children

// New class carries the prefix; its methods/fields do NOT
class AbcSellableDaysCalculator
{
    int totalDays;   // child component: no prefix

    public int calcTotal(TransDate _from, TransDate _to)   // no prefix
    {
        totalDays = _to - _from;
        return totalDays;
    }
}

Temporary table with Tmp suffix

// Table buffer for a temporary table named XyzCustVendTransTmp
XyzCustVendTransTmp custVendTransTmp;

custVendTransTmp.AccountNum = 'C0001';
custVendTransTmp.Amount     = 1000;
custVendTransTmp.insert();

Class extension with _Extension suffix

[ExtensionOf(classStr(SalesLineType))]
final class AbcSalesLineType_Extension   // Prefix + Name + _Extension
{
    public static boolean abcIsHighValue(SalesLineType _type, Amount _threshold)
    {
        return _type.salesLine().LineAmount >= _threshold;
    }
}

Points the interviewer wants to hear

  • Every customization object carries a prefix; names are English & descriptive.
  • No names starting with AAA, copyOf or DEL_ (except upgrade objects).
  • One project per function: Prefix_FDSID_Function.
  • New objects get the prefix; their child components do not.
  • Extensions use .ModelName / _Extension; temp tables end with Tmp.

Likely Follow-up Questions

  • Why must customization objects carry a prefix?
  • When is a DEL_ prefix actually allowed?
  • Do methods on a new custom class need a prefix? Why or why not?
  • How do you name a standard table extension versus a class extension?

Key Takeaway

Consistent naming makes customizations easy to identify and maintain: apply the prefix to new and extended objects (not their child components), use one project per function, follow the _Extension / dot-notation extension patterns, and end temporary tables with Tmp.

D365 F&O Interview Series — Question 33 of many
← Previous What are the best practices for sorting result sets in X++? When should you sort, why is order by preferred over index / index hint, and what field types should you avoid sorting on?