Dynamics Community Forum Thread Details

Case Form - Product Lookup

I have a project where the case is related to Multiple product. From the product I would like to see all the related cases. Right now only 1 product is connected to a case.

Several options would be to:

1) create multiple case one for each product (Seems Super Redundant) (1:M)

2) Create more lookups on the Table (Could be up to 15 products)

3) Convert the Lookup to a PolyMorphic Lookup? (A PCF Conrol that Allows for multiple Lookups)

4) Create more a sub grid connecting Cases to Products (Most extensible) (M:M)

I am thinking 4 is the best way to do this. My main question is do I "Break" any convetnions with AI scoring Cases and the KBI Scoring that might be effected by chaning this OOB function?

Thanks

Categories:

Dynamics 365 Customer Service

Hello PH-02041644-0,

You've correctly identified the limitations of the standard 1:M (one case to one product) relationship when dealing with cases related to multiple products. Your proposed options each have trade-offs, and you're leaning towards option 4 (M:M relationship with a subgrid), which is generally the most flexible and scalable.

Let's analyze your options and address your concerns about AI scoring and KBI scoring:

Analysis of Options:

Multiple Cases (1:M):
- Pros: Simple to implement.
- Cons: Highly redundant, difficult to manage, fragmented case history, poor user experience.
- Verdict: Avoid this option.

Multiple Lookups:
- Pros: Relatively simple to implement.
- Cons: Limited scalability (15 products is already pushing it), fixed number of products, difficult to report on, poor user experience.
- Verdict: Avoid this option.

Polymorphic Lookup (PCF Control):
- Pros: Potentially flexible.
- Cons: Requires custom PCF development, increased complexity, potential performance issues, may not be fully supported by all Dynamics 365 features.
- Verdict: Avoid, unless you have strong PCF development resources and specific requirements that justify the complexity.

M:M Relationship and Subgrid:
- Pros: Highly flexible, scalable, allows for any number of products, easy to report on, good user experience.
- Cons: Requires creating a relationship entity, slightly more complex setup.
- Verdict: This is the best option for your scenario.

Impact on AI Scoring and KBI Scoring:

AI Scoring (Case Similarity, Prediction):
- Potential Impact: If your AI models are trained on the existing 1:M relationship, changing to M:M will require retraining.
- Considerations:
  - The AI models need to be adapted to handle the new relationship structure.
  - Ensure that the AI models can correctly interpret the relationship between cases and multiple products.
  - Test the AI models thoroughly after the change.

KBI Scoring (Key Business Indicators):
- Potential Impact: If your KBI calculations rely on the single product lookup, they will need to be updated.
- Considerations:
  - You will need to adjust your KBI calculations to aggregate data from the related products.
  - Ensure that your reports and dashboards are updated to reflect the new relationship.
  - If the KBI’s are based on the product, you will need to make sure the KBI’s can handle multiple products.

OOB Functionality:
- General: Changing to an M:M relationship is a standard customization practice and does not inherently "break" any OOB functionality.
- Specific Features: However, any OOB features that rely on the single product lookup will need to be reviewed and potentially updated.
- Testing: Thorough testing is crucial to identify and address any potential issues.

Recommendations:

Implement M:M Relationship:
- Create an M:M relationship between the "Case" and "Product" entities.
- Add a Subgrid on the case form to display the related products.
- Add a subgrid on the product form to show related cases.

Retrain AI Models:
- Retrain your AI models to handle the new M:M relationship.
- Thoroughly test the models to ensure accuracy.

Update KBI Calculations:
- Modify your KBI calculations to aggregate data from the related products.
- Update reports and dashboards accordingly.

Thorough Testing:
- Perform comprehensive testing of all related features, including AI scoring, KBI scoring, and reporting.

Documentation:
- Document the changes and the rationale behind them.

In summary, using an M:M relationship is the most extensible and user-friendly approach. While it requires some adjustments to AI scoring and KBI calculations, it will not "break" OOB functionality if implemented and tested correctly.

If my answer was helpful, please click Like, and if it solved your problem, please mark it as verified to help other community members find more. If you have further questions, please feel free to contact me.

My response was crafted with AI assistance and tailored to provide detailed and actionable guidance for your Microsoft Dynamics 365 query.

Regards,

Daivat Vartak

Quick Links

Subscribe to this forum!