This week, we saw what I feel is the most innocuous, yet far-reaching change that Microsoft has made to Dynamics 365 Online and the Common Data Service (CDS). And I have to say; I don’t think I’m that conflicted over the changes.

First, let’s backtrack and be clear exactly what we’re talking about; namely, a buried away Microsoft Docs article change, relating to the Common Data Service, that informs us of some significant terminology changes:

Responding to customer feedback and data from user research, effective November 2020 we’re updating some terminology in Common Data Service to be more intuitive and make its usage more productive. The terminology updates are listed below, and we’re in the process of rolling them out across Microsoft Power Platform.

Legacy term	Current term
Entity, entities	Table, tables
Field, fields Attribute, attributes	Column, columns
Record, records	Row, rows
Option set, multi select option sets Picklist, picklists	Choice, choices
Two Options	Yes/No

The changes made here break with the everyday vocabulary of a system that many have worked with for well over ten years. You can’t teach an old dog new tricks they say, and indeed, for those long in the tooth with Dynamics CRM, Dynamics 365 and the Power Platform, this change may become a bitter pill to swallow. There’s already been discussion regarding this change within the community, such as by Daniel Cai and Alex Shlega. Outside of this, the general feel I’ve gotten from social media is that most people are receiving these changes somewhat negatively. Before I start wading into this debate myself, let’s take some time to review the background, to help understand the mindset and potential direction of travel regarding this change.

Don’t Forget what the Common Data Service is: A SQL Database

Those who are relatively new with working with the Common Data Service may not be aware of this. Still, it’s worth highlighting that the Common Data Service, in it’s basest form, is just a managed Azure SQL Server database, with a graphical interface that allows us to create the appropriate tables, columns and views in our backend database. In this context, the alignment of these terms to what we’d refer to them as in the underlying database system is pretty logical. It also allows us to refer to objects in a way that both Power Platform and SQL developers will readily understand.

Poor implementation of a concept does not make the concept itself a bad idea

These changes took me by surprise - I think I saw them applied within the Power Apps maker portal first before reading any of the social media posts on the subject. It also all feels very sudden. Instead of being applied on X date moving forward, the change happens now; no ifs, buts and - most importantly - an opportunity to discuss the change. And this is where I think most of the negative feedback stems from. If you are taking people on a journey with a new concept, you have to ensure they have an active role and that you give sufficient notice for people to react and respond accordingly. In the manner through which Microsoft has rolled out this change, I suspect a lot of people may be finding themselves scrabbling around to update documentation, refresh screenshots and explain to perturbed colleagues why something has suddenly changed, with no notice. Hence, frustration at having to do a lot of unplanned work manifests itself accordingly.

User Feedback is King

We must take Microsoft at their word on this one, but it would appear that the vast majority of actual users of these systems (i.e. not just people on their soapboxes, with blogs - like me 😀) seem to have a strong opinion on the legacy terms. It’s unlikely that I, or anyone else outside of Microsoft, will have sight of this feedback. But there must have been a majority of opinion for such impactful changes to have been authorised.

Tempting Microsoft Access Users to the Power Platform

Daniel Cai makes the following, great analysis within his blog post, which I feel is worth focusing on in more detail:

I have a suspicion, that the Microsoft Power Platform team is putting their every effort in making the CDS platform to work like the Access application. I have to admit, Access was really popular at its own time, and it had its great time, more importantly it covers pretty much all above new terminologies. I wonder why don’t the Power Platform team simply revive the Access application and polish it with some modern look and add some cloud fantasy, and announce it as a huge product renovation and call it a success. I might have gone a little wild on this, but I definitely see some coherence or at least some connections there.

The continued existence of Microsoft Access, to run your core business applications, feels very much like heresy these days. I have long seen the Common Data Service and Power Apps as the logical evolution of Microsoft Access and as a potential mechanism for people to migrate across their “legacy” applications into the cloud. I think Microsoft Access should have been deprecated years ago; however, I suspect that it still forms a core part of many peoples businesses today. When we start thinking about the terminology changes in this context, we could argue that Microsoft is attempting to align the Common Data Service better so that existing Access developers can more easily embrace the Power Platform moving forward. If this turns out to be one of the end goals - an eventual goodbye to Microsoft Access and alignment of the Power Platform as the successor product to migrate to - then a terminology change is a small price to pay to help achieve this.

The Joys of Being a Secret SQL Fanboy

I’ve worked far longer with SQL Server than I have with Dynamics CRM, 365 or the Common Data Service. And I will confess - I’m a true SQL geek, through and through. Nothing pleases me more than cuddling up with a hot drink and a detailed work item, that allows me to go off and build all sorts of lovely SQL Server tables, views and stored procedures. 🤓 So while I do get that the name change feels unnatural, having being used to calling an Entity an Entity for so long myself, my confliction on this subject does have some logic behind it.

So time to pin my colours to the mast…

…and say that I have no significant issues with any of these changes, bar one. Here are my reasons why:

• Table: As stated already, this is what we call the object in our backend SQL database. It accurately pictures, in my mind and many others, what the object is and how the platform utilises it.
• Columns: See above - this is a common term in the database developers lexicon.
• Rows: I’m 50/50 on this one. I would refer to a single SQL Server Table and CDS Entity row as a record, interchangeably. I also can’t see myself using this in common parlance either (e.g. “I’m just going to bring up that customer row”). However, it is an acceptable, technical term to use in the context of working with database systems. So a tough call either way and impossible to use a single word to please everyone.
• Choice: There are no related technical terms from a SQL standpoint that we can reference here. The closest we have is perhaps table constraints, but using this to describe option sets sounds wrong. I think there may have been some compromise, therefore, when agreeing on this, but the new name does accurately reflect what the field does.

The change I do not like (and I’m not just saying this prove I’m not a total fanboy 😛) is the renaming of Two Option fields to just Yes/No. Fields of this type can be of any display value, so it potentially presents a misleading impression of what this feature can do. A more sensible choice would have been Boolean or perhaps True/False instead. People working in IT will readily understand both of these naming conventions, and they more accurately reflect how SQL Server handles this type of data.

So there we go - I hope you’ve found this viewpoint interesting. I’ve been through my fair share of changes when it comes to the Power Platform and Dynamics 365 over the years, so perhaps I’m now used to when things get upended every year or so. 🤣 I’d be interested in hearing others thoughts on the naming change, and whether you think it was a good or a bad idea. Answers in a postcard below!