Back to Dynamics 365 CE

Dynamics 365 Customer Engagement

Data architecture & modeling

Tables, relationships and security designed so the system stays fast and understandable as it grows.

Dynamics 365 data models

Proper data modeling is critical for scalable Dynamics 365 implementations. My approach includes:

21 tables
Contact → Account (parentcustomerid)Case → Account (customerid)Account → Territory (msdyn_serviceterritory)Customer Asset → Account (msdyn_account)Customer Asset → Product (msdyn_product)Customer Asset → Functional Location (msdyn_functionallocation)Agreement → Account (msdyn_serviceaccount)Agreement → Price List (msdyn_pricelist)Work Order → Account (msdyn_serviceaccount)Work Order → Work Order Type (msdyn_workordertype)Work Order → Incident Type (msdyn_primaryincidenttype)Work Order → Case (msdyn_servicerequest)Work Order → Agreement (msdyn_agreement)Work Order → Customer Asset (msdyn_customerasset)Work Order → Functional Location (msdyn_functionallocation)Work Order → Territory (msdyn_serviceterritory)Work Order → Price List (msdyn_pricelist)Work Order Incident → Work Order (msdyn_workorder)Work Order Incident → Incident Type (msdyn_incidenttype)Work Order Incident → Customer Asset (msdyn_customerasset)Work Order Service Task → Work Order (msdyn_workorder)Work Order Service Task → Work Order Incident (msdyn_workorderincident)Work Order Product → Work Order (msdyn_workorder)Work Order Product → Product (msdyn_product)Work Order Product → Warehouse (msdyn_warehouse)Work Order Service → Work Order (msdyn_workorder)Work Order Service → Product (msdyn_service)Resource Requirement → Work Order (msdyn_workorder)Resource Requirement → Territory (msdyn_territory)Bookable Resource Booking → Work Order (msdyn_workorder)Bookable Resource Booking → Bookable Resource (resource)Bookable Resource Booking → Booking Status (bookingstatus)Bookable Resource Booking → Resource Requirement (msdyn_resourcerequirement)ContactcontactcontactidPKparentcustomeridFKAccountaccountaccountidPKmsdyn_serviceterritoryFKCaseincidentincidentidPKcustomeridFKFunctional Locationmsdyn_functionallocationmsdyn_functionallocationidPKmsdyn_parentfunctionallocationFKCustomer Assetmsdyn_customerassetmsdyn_customerassetidPKmsdyn_accountFKmsdyn_productFKmsdyn_functionallocationFKPrice ListpricelevelpricelevelidPKAgreementmsdyn_agreementmsdyn_agreementidPKmsdyn_serviceaccountFKmsdyn_pricelistFKWork Order Typemsdyn_workordertypemsdyn_workordertypeidPKWork Ordermsdyn_workordermsdyn_workorderidPKmsdyn_serviceaccountFKmsdyn_workordertypeFKmsdyn_primaryincidenttypeFKmsdyn_servicerequestFKmsdyn_agreementFKmsdyn_customerassetFKmsdyn_functionallocationFKmsdyn_serviceterritoryFKmsdyn_pricelistFKWork Order Incidentmsdyn_workorderincidentmsdyn_workorderincidentidPKmsdyn_workorderFKmsdyn_incidenttypeFKmsdyn_customerassetFKIncident Typemsdyn_incidenttypemsdyn_incidenttypeidPKWork Order Service Taskmsdyn_workorderservicetaskmsdyn_workorderservicetaskidPKmsdyn_workorderFKmsdyn_workorderincidentFKWork Order Productmsdyn_workorderproductmsdyn_workorderproductidPKmsdyn_workorderFKmsdyn_productFKmsdyn_warehouseFKWork Order Servicemsdyn_workorderservicemsdyn_workorderserviceidPKmsdyn_workorderFKmsdyn_serviceFKProductproductproductidPKWarehousemsdyn_warehousemsdyn_warehouseidPKTerritoryterritoryterritoryidPKResource Requirementmsdyn_resourcerequirementmsdyn_resourcerequirementidPKmsdyn_workorderFKmsdyn_territoryFKBookable Resource BookingbookableresourcebookingbookableresourcebookingidPKmsdyn_workorderFKresourceFKbookingstatusFKmsdyn_resourcerequirementFKBooking StatusbookingstatusbookingstatusidPKBookable ResourcebookableresourcebookableresourceidPKuseridFK

The core of Field Service: work orders and everything around them, with the real Dataverse logical names and lookups.

Entity relationship design

  • 1:N relationships: Parent-child relationships with cascading behavior configuration
  • N:N relationships: Many-to-many associations using relationship tables
  • Self-referencing: Hierarchical data structures (e.g., account hierarchies)
  • Polymorphic lookups: Customer and regarding fields that reference multiple entity types

Data security & compliance

Multi-layered security model using security roles and privileges:

  • Business units: Organizational hierarchy for data segmentation
  • Security roles: Privilege-based access control at entity and record level
  • Field-level security: Protect sensitive fields from unauthorized access
  • Hierarchical security: Manager access to subordinate records
  • Audit & change tracking: Compliance with data retention and audit requirements

Performance optimization

I apply these practices for optimal system performance:

  • Indexing strategy: Indexing through alternate keys and Quick Find/Dataverse search columns; avoid leading wildcards and filters on calculated columns
  • Query optimization: Efficient FetchXML and QueryExpression design
  • Asynchronous processing: Background jobs for long-running operations
  • Caching: Strategic use of caching for reference data
  • Bulk operations: ExecuteMultiple and batch API calls for high-volume scenarios

Ready to transform your Customer Engagement?

Let's discuss how Dynamics 365 CE can drive your digital transformation. I'd be glad to help you design, build, and optimize your Dynamics 365 solution.