Configure the Customer Service data model
Dynamics 365 Customer Service uses the Dataverse data model to connect cases with customers, activities, queues, knowledge, service-level agreements, entitlements, and other service records. An extension is easier to support when it builds on this shared model instead of creating another place to store the same information.
Before changing the schema, define the information that the service process needs and why the standard model doesn't meet that need. A form request might appear to require a new column, but the information could already exist on a related record. A new custom table might seem convenient, but an existing activity or case relationship could provide the required behavior with less maintenance.
Reuse the standard data model
Start with the standard Customer Service and Dataverse tables. Reusing them preserves relationships and product behavior that other features depend on. For example, a case already relates to a customer, contact, activities, knowledge articles, entitlement, queue items, and service-level agreement information.
Consider these questions before adding a component:
- Does an existing table or column already represent the business concept?
- Does the information describe one record, or does it need its own lifecycle?
- Can one record relate to many cases, customers, or representatives?
- Does the value drive routing, automation, reporting, or security?
- Who creates, owns, updates, and retires the information?
If the organization needs to record a service-quality score for each case, a few columns on the case might be sufficient when each case has one simple review. A separate Service quality review table is more appropriate when a case can have multiple reviews or when each review has its own status, owner, evaluator, findings, and corrective actions.
Select tables and ownership
A Dataverse table stores records for a business concept. Extend a standard table when additional information belongs to that record and follows its lifecycle. Create a custom table when the concept needs independent records, relationships, ownership, security, or automation.
When you create a custom table, select an ownership type that supports the access model:
- User or team owned records have an owner and participate in business-unit, role, team, sharing, and record-level access.
- Organization owned records don't have individual owners. Access applies across the organization according to table privileges.
The service-quality review scenario benefits from user or team ownership because a quality team can own and reassign individual reviews. A reference table that contains organization-wide evaluation categories might use organization ownership.
Some table properties are difficult or impossible to change after creation. Confirm the ownership, activity behavior, auditing needs, and other table capabilities before building dependent components.
Add columns and choices
Columns define the data collected for a table. Select a data type that represents the value and supports its intended use. For example, use a choice for a controlled set of review outcomes, a date and time column for completion, and a lookup for the person or related record.
Apply these design practices:
- Use existing columns when their meaning matches the requirement.
- Give new columns clear display names and descriptions.
- Require a value only when every valid record must contain it.
- Use a choice when reporting and automation depend on consistent values.
- Avoid putting sensitive information in names or other fields that appear broadly in lookups and search results.
- Enable auditing only for data that the organization needs to track.
Changing a column after data and automation depend on it can affect forms, views, flows, reports, integrations, and imports. Review dependencies before changing a data type or removing a component.
Connect records with relationships
Relationships connect tables without copying the same data into multiple records. A lookup column creates a many-to-one relationship from one table to another. One-to-many and many-to-many relationships support other business structures.
For the service-quality solution, each review can look up one case and one evaluator, while a case can have multiple reviews. A separate corrective-action table can relate several actions to one review. These relationships make it possible to display reviews from the case and report on quality outcomes by customer, representative, category, or time period.
Relationship behavior also affects what happens when a related record is assigned, shared, deleted, or merged. Select cascading behavior deliberately. Automatically deleting child records with a parent might be appropriate for temporary detail data, but it could remove review evidence that the organization must retain.
Design for downstream use
Data-model decisions affect more than storage. Forms and views need appropriate columns and relationships. Security roles need privileges for custom tables. Routing, business rules, cloud flows, reports, search, and integrations need stable schema names and consistent values.
Create schema changes within an unmanaged solution in a development environment. Add the required tables and components rather than relying on changes in the default solution. Use a publisher that follows the organization's naming standards, and include dependent components when the solution moves to another environment.
Before implementation, document the proposed tables, columns, choices, relationships, ownership, security, and retention requirements. Review the model with process owners and the people who use the data. This review catches duplicated concepts and missing relationships before they become dependencies across the solution.
For more information, see Tables in Dataverse, Columns in Dataverse, and Table relationships.