I started with series of articles about managed and unmanaged solutions from the ISV (Independent Software Vendor) perspective. You can find the first about merging forms and layering views here, and the second about missing dependencies here. I was thinking about the next topic in the managed vs. unmanaged series and decided to start over with best practices for CDS (Common Data Service) in general.
I just want to state one thing. We are ISV. We build and endorse managed solutions and these best practices are our own based on the documentation from Microsoft and implementations of customer projects.
In CDS, the Advanced find gives us a great tool for generating FetchXML files, but even it has some limitations that can be worked around. Today we will focus on more complex FetchXML queries, that require logical OR or AND groups that depend on fields that are not on a single entity.
This is the second part in my series of CDS/Dynamics solution development.
In the last article, I described why you should use managed solutions and why it’s not a great idea to use unmanaged ones. I want to support my suggested best practices in this series in the future so you have the option to make your own opinion. I’m strongly for managed solutions and I’ll tell you another reason why in this part.
Have you ever heard of “missing dependencies”? Well if you are CDS developer like me, I know you have and I know that they are pain in your ***.
If you are developing Model-driven app (business application) above the Microsoft Power Platform and you want to follow the best practices, you should deliver your complete solutions (zip packages) as managed solutions to all downstream environments.
Your goal should be to deploy your Model-driven app through AppSource. To achieve that, your app should be separated in smaller packages that can work on their own. For better understanding let’s say, that your app is separated in three main groups.
With v9 a lot of changed. One of the major changes is client
web API, some of calls were made deprecated and some were added. For example,
The new ‘Xrm.WebApi.retrieveRecord(entityLogicalName, id,
options).then(successCallback, errorCallback)’ can’t be made synchronous. But
imagine situation, in which you need to go through multiple entities (lookups).
In this scenario, you need the result of retrieved record to access the next
record. So how can this be done?
There’s no breakthrough in this blogpost… It’s just to show you how does the new .csproj look like, what basic things can be done in msbuild and how-to setup ILRepack for common data service painlessly.
Hello there, fellow power platform customizers/developers! Have you tried to override the default open behavior in subgrid and failed?
What I’ve found in my research:
Documentation by Microsoft says: “You can now create a command definition for an entity with Mscrm.OpenRecordItem as the value of the Id attribute (<CommandDefinition> (RibbonDiffXml)), and define custom action for the command <Actions> (RibbonDiffXml). Customer Engagement will look for this command Id for an entity when you try to open a record from the entity-bound grid, and if present, will execute the custom action instead of opening the entity record (default behavior).”
IMPORTANT NOTE: This feature is supported only for Unified Interface.
Přesně před týdnem byl vypuštěn veřejný build verze 220.127.116.1134 ke stažení.
Pro On-Premises prostředí je to velká a zásadní aktualizace, která přináší rozdělení aplikací a platformy a funkcionality, které již dlouho známe z cloudové verze Customer Engagement.
Velkou a nejviditelnější novinkou je příchod Refreshed a Unified Interface. Klasické rozhraní je vylepšené a uživatelé již neuvidí moře bílé plochy. Získájí přívětivější rozhraní, vylepšené ovládací prvky, ohraničení elementů. Pokud vytvoříte v řešení Application Module, můžete se těšit na nové, krásné a responzivní formuláře (UUI), které jsou konzistentní napříč klienty:
Finally, it’s the weekend and I have some time to focus on an issue which bothered our team for a few months. As always we wanted to do it the right way so it will be fast, reusable, continuous integration compatible and without spawning unnecessary workflows and plugin instances.