Issues with Case Entity Deployment Across Multiple Teams in D365 Customer Service Workspace

Question

We are working in Dynamics 365 Customer Service Workspace, where multiple teams collaborate on the same domain. The challenge we face is with the Case entity, which has buttons owned by different teams (for example, Team A and Team B).

We follow the ALM cycle for deployments with the help of our DevOps team. The process is:

All changes are pushed into the DevGrp environment, which acts as the central point before moving into higher environments.

Whenever changes are required on the Case entity, we create a new solution in DevGrp1, add the Case entity including metadata, and import it into our respective lower environments (e.g., LowerDev).

Each team makes their changes in LowerDev and then pushes them back to DevGrp to ensure all updates are consolidated.

The issue is that when Team A pushes their changes from LowerDev to DevGrp1, the button changes from Team B are sometimes missing — and vice versa. Even though we collaborate to take the latest metadata, changes often get overridden. This results in duplicate work for both teams and slows down the deployment cycle.

Has anyone faced a similar situation? Are there best practices or alternative approaches to avoid overwriting each other’s changes when working on a common entity across multiple teams? Any suggestions would be greatly appreciated.

Answer 1

Good day D, 

Thank you for sharing your concern.   

Since this forum category primarily focuses on Office 365 products and your concern relates to Dynamics 365, I want to ensure you receive the most accurate and effective assistance. For this reason, I recommend posting your question in the Microsoft Dynamics 365 Community. In this forum, you'll get the most qualified group of respondents and other partners who read the forums regularly can share their knowledge or learn from your interaction.       

I apologize for redirecting you to a different community, as the members of this category focus on Office 365 concerns and have limited knowledge about Dynamics 365. To help you get quicker and better assistance, I am guiding you to the appropriate resource.    

Thank you once again for your precious time and engagement.    

---

If the answer is helpful, please click "Yes" and kindly upvote it. If you have any extra questions about this answer, please click "Comment".            

Answer 2

Yes. The pattern described matches the source-control conflict scenario for shared solution components: when multiple developers or teams change the same component, changes can collide if they end up in the same underlying file or metadata artifact.

Best practices to reduce overwrites on a shared entity like Case:

1. Use unmanaged solutions only in development environments Keep active customization in development as unmanaged, and deploy to non-development environments as managed. This helps keep development flexible while protecting higher environments from direct edits.
2. Move to managed deployments for test and production A documented ALM anti-pattern is allowing unmanaged solutions into test and production. That creates layering and integrity problems and makes it easier for teams to overwrite each other’s work.
3. Treat DevGrp as the controlled integration environment Instead of having each team independently re-add the full Case entity and push back broad metadata, use DevGrp as the place where changes are consolidated through a build/deployment process. The case study shows that a build process from development to test to production, with restricted developer access to higher environments, improves reliability.
4. Use source control for solution files The documented team-development model is:
   • each team gets the latest source,
   • works in independent environments,
   • exports and extracts the solution,
   • submits only the changed files when possible.
   This works well when teams touch separate files. If both teams modify the same Case metadata artifact, the order of reconciliation becomes important and the changes must be merged deliberately rather than overwritten by reimporting a broad solution.
5. Minimize broad entity-level changes in separate team solutions The main problem in the scenario is that both teams are packaging the same shared entity metadata. If both teams include the full Case entity in separate solutions, each import can carry an older version of shared metadata and overwrite the other team’s updates. Reduce the scope of what is added to each solution so only the required components are included.
6. Adopt automation and validation in the pipeline The documented guidance recommends partially automated ALM with Azure Pipelines, automated build deployments, and solution checker reports. This reduces manual packaging/import mistakes and improves traceability.
7. Establish governance for shared components For a common entity owned functionally by multiple teams, define a governance process for who can change shared Case metadata, how conflicts are triaged, and how fixes are promoted. The case study specifically calls out governance, bug triage, and restricting direct access as key improvements.
8. Keep publishers to a minimum Multiple publishers increase complexity when moving components between solutions. Keeping the number of publishers low is a documented best practice.

A practical approach for the scenario:

• Keep team work in separate development environments.
• Store solution files in source control.
• Before either team starts Case changes, sync to the latest source from DevGrp.
• Avoid exporting/importing a broad Case entity package unless necessary.
• If both teams changed the same Case metadata, reconcile those changes in source control before importing back to DevGrp.
• Use an automated pipeline to build and deploy the consolidated solution forward.
• Deploy managed solutions to downstream environments.

The core issue is not only collaboration; it is that both teams are modifying and redeploying the same shared entity metadata. The documented fix is a stronger ALM model: source control, controlled merge/reconciliation, managed downstream deployments, automation, and governance around shared components.

---

References:

• Source control with solution files
• Best practices for ALM in Dynamics 365 applications
• Case study in ALM strategy