All you want to know about “Rollup View“ Entity Relationship behavior in Dynamics 365

You might be wondering this is a pretty old feature and why I am writing this blog now. As I do quite a few trainings I always get lot of questions on relationship behavior. And specially related to Rollup behavior on entity relationship.I am not going to explain in this blog what this feature is and how you can use it. Rather I am going to list most frequently asked questions that I face on this topic.

Q1. What is rollup view relationship behavior?

Answer: Rollup relationship behavior allows activities of the related entity would show up in ‘Activity Associated View’ of the primary entity.

Q2. Can I have Rollup view relationship behavior for custom entities?

Answer: Yes, it is supported for custom entities.

Q3. Rollup view relationship behavior is not getting enabled when I am creating a relationship for the custom entity. What can be the reason?

Answer: There can be multiple reasons why the rollup view relationship behavior is not getting enabled.

  • Rollup view relationship behavior is only enabled when you enabled the Activities for the participating entities in the relationship.
  • It is only enabled  when you are trying the to create a relationship with Account, Opportunity and contact entity
  • Either Account/ Contact/ Opportunity should be the parent entity in the relationship.

Q4. I have a relationship where my custom entity is the parent and Account is the child entity. Will rollup view relationship behavior be enabled?

Answer: This has been answered in Question 3 itself. You can only configure rollup view relationship behavior where Account/ Contact/ opportunity is the parent and your custom entity is the child entity in the relationship. In other words, you cannot rollup account/ contact/ opportunity activities to your custom entity.

Q5. Can I change rollup view behavior anytime post creating the relationship?

Answer: Yes  you can do it anytime. Just edit the relationship and choose the options of “Cascade All” or “Cascade None”.

Hope this helps!

Debajit Dutta

(Dynamics MVP)

For consultation/ corporate training visit www.xrmforyou.com or reach out to us at info@xrmforyou.com

Our product offerings:

CRM-Sharepoint Attachment uploader and metadata manager (http://www.xrmforyou.com/sharepoint-integrator.html)

Notes Manager (https://debajmecrm.com/2019/02/28/add-metadata-to-your-notes-and-attachments-in-dynamics-notes-metadata-manager-from-xrmforyou-com/)

Role based views for Dynamics 365 (http://www.xrmforyou.com/role-based-views.html)

Record Cloner for Dynamics 365 (http://www.xrmforyou.com/record-cloner.html)

Get Transaction currency name for logged in user in Dynamics 365

Recently Microsoft have released quite a few updates to it’s client API and one such is the update to API for getting the currency name of the logged in user.

All this time, Microsoft had an API to get the transaction currency id of the logged in user using the API – Xrm.Utility.getGlobalContext().userSettings.transactionCurrencyId. You needed to run a separate query to fetch the currency name based on currency id. However it is being deprecated now and now the replacement API is Xrm.Utility.getGlobalContext().userSettings.transactionCurrency.

This wonderful api returns the name of the currency as well as the id and entityType.

Below is the sample output

{id: “e7dd9bc6-d239-ea11-a813-000d3a35b14a”, entityType: “transactioncurrency”, name: “US Dollar”}

Wonderful isn’t it?

Hope this helps!

Debajit Dutta

(Dynamics MVP)

For consultation/ corporate training visit www.xrmforyou.com or reach out to us at info@xrmforyou.com

Our product offerings:

Role based views for Dynamics 365 (http://www.xrmforyou.com/role-based-views.html)

CRM-Sharepoint Attachment uploader and metadata manager (http://www.xrmforyou.com/sharepoint-integrator.html)

Record Cloner for Dynamics 365 (http://www.xrmforyou.com/record-cloner.html)


Out of the box API to get Logged In user’s security role names in Dynamics 365 is finally there. Is the long wait finally over?

Checking for logged in user’s security role is a requirement I haven’t missed in any of my implementations so far. From enterprise implementations to projects spanning couple of months, this requirement I had everywhere. And as much crazy it may sound, until recently there was no way to get the security role names directly using client API. Even the unified interface introduced Xrm.Utility.getGlobalContext().userSettings.securityRoles which unfortunately had the same perennial problem – we shall get a the GUID of the roles user is having and then we have to fire a query to the server side to get the role names.

Thankfully Microsoft have slipped in an update to get the role names. Since this one came without much publicity, it didn’t get the media attention it deserved. Microsoft have deprecated – Xrm.Utility.getGlobalContext().userSettings.securityRoles and instead suggested to use Xrm.Utility.getGlobalContext().userSettings.roles. Use the getAll() function to take the output as array.

image

As seen from the developer console, it’s a relief certainly. We no longer need to query the separately to get the role names. Wonderful isn’t it. Finally a solution to a long standing problem? Well not exactly.

This method works just fine if you have the security roles directly assigned to the user. However if the user is added to a team and the team have a security role, the name comes as undefined.

image

Above is a screenshot for a user. The user is assigned to a team and the team is having Sales Manager role. Although the API is indeed returning the GUID of all the roles, the name of the security role coming through team association is coming as undefined.

Honestly I was bit surprised as it is kind of quite basic and this making the final cut with this issue is something I was not expecting.

I hope this is fixed quick by Microsoft.

Till then we wait with bated breath to use this for all scenarios.

Hope this helps!