Comments
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.
Product families does not cover it mostly because of the cost calculations for different outputs. You need also to specify somewhere the coefficents for quantities and cost rates as there may be situation where the quantity output of one of the produced part is large but the cost of the item is actually very small.There was a product named naviMeat, I worked with in Customer site, what had this feature (no associations with the company - I do not know do they even exist any more)
Actually, Arabic localisation has been requested many times by different partners and customers across the region, but until now, Microsoft has given zero tangible feedback.It’s clearly not in their priorities at the moment, even though Arabic is a strategic need.We all hope Microsoft will finally take this seriously, because the demand is real and urgent.