🔤 Naming Conventions

📖 Introductie

Deze pagina beschrijft de standaard naamgevingsconventies binnen het Dataverse / Dynamics 365 platform. Naming conventions zijn geen cosmetisch detail, maar een essentieel onderdeel van volwassen solution design, beheerbaarheid en Application Lifecycle Management.

In een professionele Power Platform of Dynamics 365 implementatie worden oplossingen over langere tijd uitgebreid, beheerd en door meerdere consultants of ontwikkelaars aangepast. Zonder duidelijke naamgeving ontstaan snel ambiguïteit, fouten in scripts en integraties, onduidelijke componentrelaties en extra onderhoudslast.

Deze richtlijnen gelden voor alle ontwikkeling binnen het Dataverse / Dynamics 365 platform en moeten consistent worden toegepast binnen solutions, entiteiten, velden, webresources, integraties en overige componenten.

---

📋 Algemene richtlijnen

De onderstaande uitgangspunten gelden voor de volledige oplossing. Ze zorgen ervoor dat naamgeving niet afhankelijk wordt van persoonlijke voorkeur, maar onderdeel wordt van een gedeelde technische standaard.

• Gebruik consistente naamgeving binnen het gehele platform
• Gebruik beschrijvende namen en vermijd onduidelijke afkortingen
• Gebruik geen environment namen zoals DEV / TST / ACC / PRD in componentnamen
• Scheid functionele en technische naamgeving waar nodig
• Gebruik lowercase voor technische namen
• Gebruik een duidelijke en herhaalbare structuur en opbouw

---

📦 1. Solutions

De naam van een solution moet direct duidelijk maken wat de functionele scope is en hoe deze solution zich verhoudt tot andere onderdelen binnen de totale oplossing. Een goede naam ondersteunt zowel beheer als deploymentvolgorde.

Display name

<customer> | <scope>

Richtlijnen

• Begin altijd met de klantnaam gevolgd door een scheidingsteken ( |)
• Gebruik een nummer voor de technische volgorde van componentgerichte solutions ( 01 t/m 05)
• Gebruik een duidelijke scope zoals Configuration, Programming UI, Core, Programming Logic of Automation
• Gebruik voor functionele of integratiegerichte solutions een herkenbare focusnaam

Voorbeelden – componenttype

• BRENKE | 01 Configuration
• BRENKE | 02 Programming UI
• BRENKE | 03 Core
• BRENKE | 04 Programming Logic
• BRENKE | 05 Automation

Voorbeelden – focusgebied

• BRENKE | Marketing
• BRENKE | Salesbuildr Integration

Technical name

<publisher>_<scope>

Richtlijnen

• Publisher prefix is verplicht
• Gebruik lowercase
• Gebruik underscore als scheiding
• Gebruik geen spaties

Voorbeelden

• brenke_configuration
• brenke_programming_ui
• brenke_core
• brenke_programming_logic
• brenke_automation
• brenke_marketing
• brenke_salesbuildr_integration

---

🧱 2. Entiteiten (Tables)

De naamgeving van entiteiten moet zowel functioneel logisch als technisch voorspelbaar zijn. Tabellen vormen een kernonderdeel van het datamodel en worden gebruikt in formulieren, views, flows, plugins, scripts en integraties.

Display name

<name>

Richtlijnen

• Gebruik enkelvoud
• Gebruik begrijpelijke namen voor eindgebruikers
• Laat de functionele betekenis centraal staan

Voorbeelden

• Account
• Order
• Subscription

Technical name

<publisher>_<name>

Richtlijnen

• Publisher prefix is verplicht
• Gebruik technisch compacte maar duidelijke namen
• Gebruik geen generieke of tijdelijke benamingen

Voorbeelden

• brenke_productionline
• brenke_registration
• brenke_subscription

---

🔗 3. Relaties (Relationships)

Relaties maken onderdeel uit van het datamodel en bepalen hoe entiteiten met elkaar verbonden zijn. Duidelijke naamgeving helpt bij analyse, configuratie, scripting en integraties.

3.1 Algemene structuur

<publisher>_<bronEntiteit>_<doelEntiteit>

Voorbeelden

• brenke_account_contact
• brenke_contact_account

3.2 Typen relaties

• 1:N (One-to-Many)
• N:1 (Many-to-One / lookup)
• N:N (Many-to-Many / intersect)

3.3 1:N relaties

<publisher>_<hoofdEntiteit>_<gerelateerdeEntiteit>

Voorbeelden

• brenke_account_contact
• brenke_account_opportunity

3.4 N:1 relaties

<publisher>_<childEntiteit>_<parentEntiteit>

Voorbeelden

• brenke_contact_account
• brenke_opportunity_account

Bijbehorende lookup velden

• brenke_accountId
• brenke_primaryContactId

3.5 Lookup veld vs relatie

3.6 N:N relaties

<publisher>_<entiteit1>_<entiteit2>

Voorbeelden

• brenke_account_competency
• brenke_contact_interest
• brenke_user_role

3.7 Intersect entiteit

<publisher>_<entiteit1>_<entiteit2>_link

Voorbeeld

• brenke_account_contact_link

3.8 Richtlijnen

• Gebruik altijd de publisher prefix
• Gebruik lowercase en underscore
• Gebruik duidelijke en consequente namen
• Wees consistent in richting en volgorde van naamgeving

3.9 Veelgemaakte fouten

• ✘ brenke_relation1
• ✘ brenke_lookup_account
• ✘ brenke_contact1_account2
• ✘ brenke_acc_cont

---

🔤 4. Velden (Columns)

Deze sectie beschrijft de naamgeving van velden (columns) binnen Dataverse. Goede veldnaamgeving is essentieel voor leesbaarheid in formulieren, begrijpelijkheid in configuratie, consistent gebruik in code en voorspelbaarheid in integraties.

Display name

De display name is bedoeld voor functionele gebruikers en moet direct begrijpelijk zijn.

Richtlijnen

• Gebruik duidelijke en beschrijvende namen
• Vermijd afkortingen
• Gebruik spaties voor leesbaarheid
• Schrijf in titelvorm

Voorbeelden

• Email address
• Phone number
• Order date
• Primary contact

Schema name

De schema name (logical name) wordt gebruikt in code, API’s en configuratie.

<publisher>_<functioneleNaam><suffix>

Richtlijnen

• Publisher prefix is verplicht
• Gebruik lowerCamelCase na de underscore
• Gebruik geen spaties
• Gebruik duidelijke Engelse termen
• Vermijd onduidelijke afkortingen

Naming per type veld

Tekst (Single line / Multiline)

Gebruik een beschrijvende naam zonder extra suffix.

• brenke_name
• brenke_solutionName
• brenke_description

Boolean (Yes/No)

Gebruik bij voorkeur een logische prefix zoals is of has.

• brenke_isActive
• brenke_isCustomer
• brenke_hasContract

Keuzeveld (Choice / OptionSet)

Gebruik een zelfstandig naamwoord; een extra suffix is meestal niet nodig.

• brenke_status
• brenke_type
• brenke_category

Numeriek (Whole / Decimal / Money)

Gebruik een duidelijke beschrijving van wat het getal representeert.

• brenke_quantity
• brenke_amount
• brenke_creditLimit

Datum / tijd

Gebruik indien relevant suffixen zoals Date of DateTime.

• brenke_startDateTime
• brenke_birthDate
• brenke_createdOn

Lookup velden

Gebruik altijd suffix Id en zorg dat de naam de betekenis van de relatie beschrijft.

• brenke_primaryContactId
• brenke_parentAccountId
• brenke_customerId

Goed

• ✔ brenke_accountManagerId
• ✔ brenke_primaryContactId

Fout

• ✘ brenke_contactId (te generiek)

Percentage / rates

Gebruik indien relevant een suffix zoals Percentage of Rate.

• brenke_discountPercentage
• brenke_interestRate

Technische / integratie velden

Gebruik duidelijke suffixen die het technische doel ondersteunen.

• brenke_externalId
• brenke_integrationKey
• brenke_erpReference

Consistentieregels

• Gebruik dezelfde structuur binnen alle entiteiten
• Gebruik vaste suffixen per datatype
• Wijzig namen niet per environment
• Volg naming conventions in alle solutions

Samenvatting per type

---

🗂️ 5. Webresources

Webresources moeten logisch georganiseerd zijn zodat scripts en assets voorspelbaar terug te vinden zijn. Een duidelijke folderstructuur ondersteunt onderhoud en hergebruik.

JavaScript

Gebruik één van de volgende structuren:

• <publisher>_scripts/<entity>.js
• <publisher>_scripts/<entity>/<entity>.js (bij meerdere scripts per entiteit)

Voorbeelden

• brenke_scripts/account.js
• brenke_scripts/contact.js
• brenke_scripts/account/account.js

Richtlijnen

• Gebruik één script per entiteit als standaard
• Gebruik de entitynaam als bestandsnaam
• Gebruik folders als meerdere scripts nodig zijn
• Gebruik lowercase

Afbeeldingen

Gebruik één van de volgende structuren:

• <publisher>_images/<entity>/<imagename>
• <publisher>_images/<imagename>

Voorbeelden

• brenke_images/account/chamberofcommerce.png
• brenke_images/icons/sync.svg

Richtlijnen

• Gebruik entity-gebaseerde structuur voor specifieke afbeeldingen
• Gebruik platte structuur voor algemene afbeeldingen

---

🔄 6. Cloud flows

Cloud Flows moeten zo benoemd worden dat scope, trigger en doel direct herkenbaar zijn. Dit helpt bij beheer, analyse, troubleshooting en overdracht.

Naamgevingsopbouw

• Applicatie (optioneel)
• Primaire entiteit
• Trigger
• Actiebeschrijving

Richtlijnen

• Gebruik duidelijke beschrijvende namen
• Gebruik een werkwoord in de actieomschrijving
• Houd de naam compact maar betekenisvol

Voorbeelden

• Sales - Opportunity - Cud - Create notification
• Service - Case - cUd (statecode) - Send email with status update
• Sales - Pricelist - S W(Sat) - Import new pricelist from SharePoint
• Account - CUd (iban) - Validate the IBAN

---

🔌 7. Connection references

Connection references moeten zowel functioneel leesbaar als technisch beheersbaar zijn. Duidelijke naamgeving voorkomt onnodige verwarring tussen accounts, service principals en verschillende koppelingen.

Display name

<connector> - <context> - <type>

Richtlijnen

• Gebruik beschrijvende en functionele benamingen
• Gebruik consistente terminologie per connector
• Maak duidelijk of het om bijvoorbeeld een Service Principal of Service Account gaat

Voorbeelden

• Dataverse - BRENKE - Service Principal
• SharePoint - BRENKE - Service Account

Technical name

<publisher>_<connector>_<type>

Richtlijnen

• Publisher prefix is verplicht
• Gebruik lowercase
• Gebruik underscore als scheiding
• Gebruik korte maar herkenbare termen

Voorbeelden

• brenke_dataverse_sp
• brenke_sharepoint_sa

---

⚙️ 8. Environment variables

Environment variables worden gebruikt om configuratie los te koppelen van deployment. Naamgeving moet daarom stabiel, begrijpelijk en environment-onafhankelijk zijn.

Display name

<name>

Richtlijnen

• Beschrijvend
• Functioneel en direct begrijpelijk

Voorbeelden

• SharePoint Site URL
• API Endpoint

Technical name

<publisher>_<name>_<type>

Richtlijnen

• Gebruik lowercase
• Gebruik underscore voor scheiding
• Gebruik een herkenbare technische naam die niet per environment verandert

Voorbeelden

• brenke_sharepoint_url
• brenke_api_endpoint

---

🔢 9. Choices

Choices moeten herkenbaar zijn voor functionele gebruikers en voorspelbaar voor technische implementatie. Consistentie tussen display name en technical name voorkomt onduidelijkheid in formulieren, rapportages en logica.

Display name

<name>

Richtlijnen

• Gebruik beschrijvende en begrijpelijke namen
• Gebruik enkelvoud
• Gebruik een functionele naam

Voorbeelden

• Status
• Type
• Category

Technical name

<publisher>_<name>

Richtlijnen

• Publisher prefix is verplicht
• Gebruik lowercase en underscore
• Gebruik geen spaties

Voorbeelden

• brenke_status
• brenke_category
• brenke_type

---

🧩 10. Custom API

Deze sectie is gereserveerd voor naamgevingsconventies rondom Custom API’s. Het onderwerp hoort inhoudelijk thuis binnen deze standaard, omdat Custom API’s een volwaardig technisch artefact vormen binnen solution design en integraties.

Placeholder op basis van de bron-MD: Request / Response volgt later.

---

🧾 11. Formulieren, tabbladen en secties

Deze sectie beschrijft de naamgevingsconventies voor formulieren (forms), tabbladen (tabs) en secties (sections) binnen model-driven apps. Deze naamgeving is belangrijk voor beheer, scripting, troubleshooting en overdraagbaarheid.

11.1 Formulieren (Forms)

Formuliernamen moeten duidelijk maken wanneer een formulier gebruikt wordt en voor welke doelgroep of context het bedoeld is.

Display name

<entity> - <context of rol>

Richtlijnen

• Gebruik een duidelijke en functionele naam
• Vermijd generieke namen zoals “Main form 1” of “Custom form”
• Gebruik context of doelgroep alleen als dit echt onderscheid maakt
• Houd het aantal hoofdformulieren beheersbaar

Voorbeelden

• Account - Main
• Account - Sales
• Case - Service Agent

11.2 Tabbladen (Tabs)

tab_<tabname>

11.3 Secties (Sections)

tab_<tabname>_sec_<sectionname>

---

✅ Best practices

Onderstaande best practices helpen om naamgeving niet alleen correct, maar ook langdurig beheersbaar te maken.

---

📊 Samenvatting

Een consistente naamgevingsconventie zorgt voor betere leesbaarheid, minder fouten, snellere onboarding van developers en stabielere deployments. Daarmee is naming niet alleen een documentatieonderwerp, maar een structureel onderdeel van solutionkwaliteit.

Deze pagina vormt daarmee de basis voor alle ontwikkeling binnen het platform en ondersteunt een meer volwassen, voorspelbare en beheersbare ALM-aanpak.