Comments
One of our customers has shared with us the work around they have used to link the correct account as bellow:add an extra field 'associated account to the contact for party tablevia javascript, fill the original associated account field with the value that was entered in the new fieldsave the record (MS plugin will update the associated account to another accountadd a power automate flow that will compare the new associated account and the original associated account - and update the original associated account with the value of the new associated account. that way we would always update the field to the value entered by the user - and avoid the problem that is created.
It would be nice to have a more sophisticated colorization in the calendar (on activitypointer) indeed.Any generic way to add color codes to activities would be a nice improvement. We had a color scheme before using different colors for each activity type and activity status (> in some other app). Sales reps could easily identify if an activity was (not yet) completed (or cancelled) in the calendar but also easily distinguish activity types. The calendar (v2) now already uses icons to distinguish that type but it could still be a nice improvement having some custom colorization in there too.We currently cannot do much on the activitypointer entity so we can't add colors via such binding.(that would only be possible when adding a calendar on appointments or elsewhere but not in activitypointer)Then again (or even on top), if using the outlook integration, it would not be present in the calendar there. Not sure if there could be some generic way to have such custom color scheme applied in any way.
It has now been six years since this request was made, and unfortunately nothing has changed in this area. Editable grid events still cannot be programmatically registered, and we continue to be limited to manually configuring handlers in the UI.For modern solution architectures, this is a real gap. The grid should expose the same event surface as forms — including OnSave, OnChange, and OnRecordSelect — with proper programmatic registration (e.g. addOnSave, addOnChange, addOnRecordSelect). Without these, developers must duplicate configuration across many forms and grids, and cannot apply consistent logic centrally.This is increasingly problematic in environments with multiple grid types, dynamic UIs, or large implementations where manual event registration becomes both error-prone and hard to maintain. A proper client API for editable grids would significantly reduce configuration effort and would finally make grids behave like first-class citizens in the model-driven UI framework.It would be great if the product team could revisit this request. The need is still very much present, and exposing these events via API would remove one of the long-standing limitations when working with editable grids in Dynamics 365.