Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Our Contacts to Case relationship is Parental.
This is causing a permissions issue for us because the owner of the Contact always has access to the Case that contact is on.
Would changing the relationship to Configurable Cascading be advisable and are there pitfalls etc?
It would involve over 100,000 Cases. Its seems the only way out of the issue.
Any advice appreciated.
You need to think about cascading the ownership. For instance, You need to answer to yourself what you want to do to the Cases when Contact's owner changes.
What i read above sounds it is better to change the relationship behavior.
If you need a specific ownership cascading, you might need to develop it.
Entity relationship behavior: docs.microsoft.com/.../entity-relationship-behavior
Hi thanks for reply,
Can I run this by you?
We need staff to only see Cases within their own business unit (BU level permissions). These Cases get assigned to the different business units (sections) by Customer Service Desk staff who have also created the contacts.
The issue is that these Customer Service Desk staff may get moved to different sections at some stage and their new Business Unit level permissions gets overruled with many Cases because they may have ownership of the contact on those Cases.
I thought I had a fix by just assigning the Contacts to a generic user; but this also assigns the Case to that user, this is no good (lesson learnt).
It looks like changing the Parental to Cascading is the answer but I suppose I am worried it may not be good practice to do it now after years of records etc.
thanks again for advice its appreciated.
As you described above, it doesn't seem you can go with the as-is cascading on Case entity. My understanding is that Contacts will be seen by organization level, however Cases will be seen by relevant Business Units.
So, if this is the situation, any user as owner of contact is fine in this case, the security role of users will have Organization level privilege. If the cases will need to be owned by business units, then you can use default business unit team as owner. You might need a WF to assign this. If the owner of case will be a group of people in a business unit, then you need to create a team and assign the records to that team.
Hi thanks for quick reply,
As is, all cases are assigned to the specific business units through the users of those business units.
All is working fine with Business Unit level access to Cases except for those staff that have previously created Contacts while with another business unit (Customer Service Desk).
As you mentioned Contacts is organisational and that's fine except for this Parental relationship to Case which is giving owners of the Contact full rights to those cases regardless.
Its is on the Contact entity 1:N to Case that I was considering the Parental relationship to Cascading (none). I was wondering would this be fine to do at this stage with many records?
The "type of behavior" change doesn't affect the existing records. It will work when a new record is created or a relation is updated such as creating a case or updating the customer of a case.
This is good news.
Once the behavior has changed; if I reassign ownership of a contact this should not affect ownership of the Case they are related too?
I am going to mark your last reply as answered and thanks again for your advice.
Once the behavior has changed;
I would suggest you do a quick test in Dev or Test environment for the sample of records that match the criteria in the live system before applying it to the live system.
Business Applications communities