How can you predict the behavior of the effect of record deletion on its related records?

If you are aware of the "Type of behavior" of the relationship between two entities in Microsoft Dynamics 365 CRM then you can understand it as follows easily.

Primarily there are two types of relationships - one is Referential and another is Parental. Let's talk about each of these relationships one by one.

If the relationship is Referential and Remove Link on Delete: then any actions taken on one will not affect the other.

If it is Referential and Restrict Delete: then any action taken on the parent record will not be applied to the child record, but the parent record cannot be deleted while the child record exists.

Next is the Parental relationship, which establishes a very tight link between records.

If it is Parental: then any action taken on a record of the parent table is also taken on the related child table records.

If it is Custom: then Custom behavior for each possible action is applicable. For Custom behavior, setting up detailed cascading options for Delete, Share, Reparent, Assign, and Unshare can be possible.

However, the "Type of behavior" option is not applicable for many-to-many relationships, where any actions taken on one will not affect the other.

Dynamics 365 (or D365) is an Enterprise Resource Planning (ERP). I can remember D365 used to be known as a CRM solution from Microsoft. However, with the progress of the solution, upcoming additions of various modules, and feature enhancement, I was pretty sure that one day it is going to be a full-fledged ERP solution. And the most exciting part is that this is going to be an online or cloud-based ERP.

Today with the modules like Finance, Operates, HR, and Supply Chain in D365 we can see the time has arrived when we say that D365 is an ERP solution. This is also established by Gartner® Magic Quadrant™ where recently Microsoft is named a Leader for Cloud ERP.

Moreover, D365 has the Commerce module and easy integration with Office Solutions as well. This is not very common with other ERP solution packages. Otherwise, these had to be a separate and disconnected solution again.

So this was my point of view for the latest D365 avatar, if you have any other such point of view then please let me know.

Hello Friends, Implementing Dynamics 365 can be a fun and a lifetime experience if you love cloud business solutions. I had a similar experience in recent years of my long journey around the line of business applications. From the very beginning of my IT career, I was fascinated by computer applications over the internet. Even my postgraduate degree project was also based on ASP that is to say Active Server Pages. I can remember, that time I had to set up my private cloud on the LAN of the school where I had implemented it. From the infrastructure to the development, I had to do everything myself.

Now the scenario is very different. We have cloud technologies and business solutions like Dynamics 365 in hand. At the beginning of the Covid 19 Pandemic, my dream came true and I got the opportunity to work on these latest technologies. I have written the complete experience in a blog, the link has been given in the description. Please have a look. I believe you will enjoy the story.

Here is the blog link: https://bit.ly/3nxoSAC

There are a lot of exciting stories about my business solution implementation. I'll try to share all of them here, at least the ones around Microsoft business solutions. Thank you.

While working with Power BI I primary faced two types of languages or scripts they are Power Query and DAX. Power query is very powerful in transforming the source data before they load into the reports or the user interface. Power query uses the M functions to write the data transformation codes. That is why they are also called M queries. If required we can use the R and Python scripts here while transforming data in Power BI. Once the data is transformed, the real-time measures and other data processing can be done using the DAX language. The full form of DAX is Data Analysis Expression. This is used once the data is processed using a Power query. This is available on the front end of power BI. But this is optional, DAX is needed only when we need to add any data processing logic in the report once the data is loaded. So in summary I find that the Power query or M query is for the backend data processing and DAX is for the front end data processing in Power BI.

There are many such observations around Microsoft Power BI that I am trying to share in this episode.

Hi Friends, have you seen the charts and dashboards in Microsoft Dynamics 365? What do you think – how many charts and dashboards do you need to fulfil your reporting and data analytics needs? If you think carefully and list them then I am sure there will be many. So eventually you must prepare many charts and dashboards that we used to do in our old ERP systems.

I can remember that in my first ERP implementation the client had given me tons of hard-copy sample reports and documents of their business to prepare 100s of reports out of that. It was a pathetic experience. However now in the solutions like Dynamics 365 – you know, a single chart can serve the reporting needs of several aspects of the business. It saves time of the implementer a lot and saves your time by avoiding switching from one chart to another chart frequently.

I have created a small video for an idea of what it may look like in D365. You can refer to that video, the link is provided in the description. Please comment if you need more on this. Thank you.

Here is the video link (https://bit.ly/2RI0uiN).