Dynamics 365 – Problems debugging fields on a form

“ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” – Edsger Dijkstra

Dynamics 365 is a place where only dirty entities and fields are saved! The clean fields are ignored #HoskCodeWisdom

  • Junior developer – assumes how things work
  • Good developer – finds out through trial and error
  • Great developer – does not assume and methodically confirms

Dynamics 365 can frustrate developers (The Frustrations of a CRM Developer), developers are provoked by the idiosyncratics, limitations and bonkersness of Dynamics 365 as Microsoft works on new ways to annoy developers 🙂

Bugs and problems areopportunities to gain a deeper knowledge of the workings of Dynamics 365.

New developers get caught out such as in the CRM 2011 (good old) when SetSubmitMode was a rite of passage for Dynamics CRM developers – CRM 2011/2013 – What does setSubmitMode do? and how does it work?

Unless you made the field dirty and change SubmitMode the field was not sent to the database to be saved

Try, Try and try again

On creation of an appointment the start and end times should be editable, on a form update those fields should be readonly.

Examples of using the SetDisabled(true) were found in the code, copied and adapted for the start and end times on the appointment entity.

He kept debugging and being puzzled because the start and end times were not changing, but why not?

Insanity: doing the same thing over and over again and expecting different results.  Albert Einstein

Developer Insanity: Testing the same code over and over and expecting intermittent result #HoskCodeWisdom

Hosk developer debugging beliefs

  • Investigate bugs with an empty mind
  • Microsoft 365 is full of quirks which make sharing knowledge between team members important
  • Bugs are not a sign of a bad developer, they are a sign of a developer developing #HoskCodeWisdom
  • Always help your fellow developers, big projects need a strong team.  Never leave a developer stranded
  • Don’t suffer in silence if you are not making progress, get help and get direction #HoskWisdom

SetDisabled = true

The way to make a read-only field editable is to use the Dynamics 365 JavaScript Xrm, get the control and use the setDisabled(false)

Xrm.Page.ui.controls.get(“your field name”).setDisabled (true); //Field readonly you can’t write any thing on field

if you change true as false;

Xrm.Page.ui.controls.get(“your field name”).setDisabled (false); //Anyone can put value on this field

I looked at the code, it looked fine, we checked a few things

  • Is there any other code changing the field back to read only –> No
  • Checked the line worked in the debugging console –> Yes
  • Was there a JavaScript error –> No
  • Debug the code, does it run the line of code which enables the field –> Yes

Appointment entity

In this example we used the appointment entity, which is an odd entity.  It‘s not possible to add new forms for the appointment entity Dynamics 365 – You can’t add new forms to the appointment entity There is code running on the appointment entity which a CRM developer has no control over, cannot see and cannot edit.

When you book appointment it sets the user who booked the appointment as the organizer of the appointment.  This is fine for Outlook but not what I wanted to happen in Dynamics 365.

Adding hidden custom code which developers can’t disable is frustrating as much as it is undocumented, believe Microsoft should write customizations in the same way standard Dynamics 365 developers do. This would allow us to see, modify, disable or extend the default behavior.

Stop, think

When you rule out the obvious, it’s time to check the stupid – #HoskWisdom

Appointment entities don’t allow you to add new forms (or change the status/status reason of the appointment) because we couldn’t add new forms, we had JavaScript which when the regarding field was set to a specific custom entity we disabled the default section and showed a new section with custom fields on.

Usually a developer would create another form but we couldn’t because it was the appointment entity

This resulted in the same fields being on the form twice, the start and end times.  So the code was working, except it was making the fields on the hidden section and the first fields on the form.

To resolve the problem go to the section (in code) and then retrieve the field you want and then make it make it editable.

Hosk values with bug fixing

  • Developers who fix a problem which doesn’t keep popping back because it‘s not properly fixed
  • Developers who use a bug as an opportunity to learn how Dynamics 365 works
  • Developers should try to resolve the problem first before asking for help
  • Don’t spend too long being puzzled by a bug before asking for help, Dynamics 365 has odd quirks and limitations which can take hours to resolve.  Get direction from a colleague after 1 hour of frustration
  • Developers should not assume, they must clarify (I wasted hours looking in the wrong place because I didn’t check my assumptions)

On a separate note but relatedish – Developers using JavaScript onload should be careful when setting and changing values because it can frustrate user by asking them to save a form when they haven’t change any values When to automatically change fields using Javascript 

picture from here

Don’t let a marshmallow crush your project


“The only real mistake is the one from which we learn nothing.” – Henry Ford

When people can think of the team before themselves, the team can achieve great things #HoskWisdom

Code not in production has no value, you don’t know if it will work, get it live in the shortest time possible.


  1.  Get your code finished into production and the customer starts to get value
  2. The longer code isn’t in production, the larger the risk it won’t work or be what the users need
  3. Test your design with a prototype is always better than having a design on paper
  4. Politics and positioning for power can slow and divert projects
  5. Adults fear failure/mistakes more than children and because of it they make bigger mistakes

Build a tower

A popular team building exercise sets teams of four people to build the tallest tower possible using 20 sticks of spaghetti, sticky tape, string and a marshmallow which has to sit on top.

Ted talk – Build a tower, building a team

here are some crazy designs

I attended a similar exercise using spaghetti and jelly babies.  It was a fun(ish) but lacked a point but getting to know your team is important, so it all helps.

Common problems

Many individuals waste time jockeying for position, trying to assert their authority at the expense of doing the task well.  The video states children don’t waste time doing this, they focus on the task not people and position.

Many of the people doing the exercise will create the spaghetti tower and leave putting the marshmallow on the top at the end, with one minute to go.  This leads to a either successfully putting the marshmallow on the top or the marshmallow destroying the towr because it‘s too heavy.

Most teams leave creating prototypes and testing their designs until the last minute, with no time to adjust.

Mr Stay Puft visits your project

Dr Ray Stantz: [after Ray thinks of the Stay Puft Marshmallow Man and it appears, stomping through New York City] I tried to think of the most harmless thing. Something I loved from my childhood. Something that could never, ever possibly destroy us. Mr. Stay Puft.

Dr. Peter Venkman: Nice thinking, Ray.


Leaving the marshmallow until the end is the classic waterfall approach to projects, the marshmallow in the project can be

  • Show the customer and finding out it‘s not what they want
  • The functionality does not work
  • The functionality doesn’t work the way the users/business needs
  • performance problems
  • The integrations don’t work

Waterfall projects leave the risk (the marshmallow) until the end and leaving no time to change or adapt.

You can tell Mr Stay Puft will visit your project when the requirements and functionality are not linked to business goals and there is a lack of business input.  IT projects are a collaboration between the business and developers.

If it smells like agile

The most successful teams created prototypes and put the marshmallow on their tower at the earliest moment.  Creating working examples is key, you can try a different design if the marshmallow squashes your design and you can adapt working designs.

Agile aims to get functionality finished and into production as soon as possible, allowing user to see and use it as soon as possible.  This stops the two sides drifting apart because at the end of every sprint they are pulled together to review progress and get feedback.

Agile is great when done well and the customer engages in the agile process, I have discussed Scrum in a blog post before

There are many projects which are Agile in name but chaos in reality #HoskWisdom 

Many businesses cannot fight the desire to plan out the project and costs, despite everyone knowing long term planning is never accurate.  It helps to remember another name for estimate is guess and adjust your confidence levels accordingly.

On your next project, get code into production as soon as possible to ensure you are creating what’s needed, what’s wanted and what works.

pictures from here, here