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 ***.
You may wonder why is this part 3 when there is no part 1 and part 2. The reason is simple. Bob Guidinger already covered the introduction to the custom dialogs well enough and you can read about it here in his blog post. Please, do so, I’m going to refer to it quite often.
When I was reading the post, I immediately wanted to try it out in my own environment. However, the blog post doesn’t cover much about more complex ways of using custom dialogs. So I decided to deep dive into this topic.
PowerApps component framework has been in public preview for a while now. While it allows you to create wonderful customizations, you may want to make use of React and Office Fabric UI for your components. In this article, we are going to show you how.
When you are managing services which deal with customer’s data, sensitive information etc. you should never allow users to directly access the data. Instead, you should use some privileged identity management solution. In this article, we are going to look into how to implement this on our own with the use of SharePoint and Microsoft Flow.
Have you always wondered why we need to activate workflows, when every other component, from entities to forms, needs to be saved and published? Is workflow somehow different from other entities in Dynamics? Just to clarify, we are talking about workflows and actions, not business process flows.
Well, yes and no. The definition of a workflow is, of course, stored as records inside of the CDS. CDS uses the entity Workflow (which you won’t find in advanced find) to create records of concrete workflows. This entity can be accessed via the WebApi on the /workflows endpoint.
But if you call this endpoint and see the list of all the workflow records you have in your environment; you may notice that some workflows are there multiple times. That is thanks to the way CDS works with workflows under the hood.
You see, when you create a workflow, CDS creates a “Parent” record of your workflow. This record has all the typical information in it, such as the name, if it’s activated, ownerId and the xaml definition of the logic. Every workflow record also has two single-valued navigation properties: activeworkflowid and parentworkflowid. As you have probably guessed, the parentworkflowid is set to null, because it itself is the parent.
At the same time, CDS creates another record for the very same workflow. Let’s call it “Active”. This active workflow then gives its id to the parent and sets it as the activeworkflowid, while it gets reference to the its parent.
And here we finally answer the question: Why do we have to activate workflow, instead of publishing it? The answer is simple: Every time you publish something in CDS, you change an existing thing. With workflows, every time you activate a workflow, the CDS creates a new record in your database, and sets it as the active workflow to its parent. This would be useful if it was just a change tracker, but the record gets created even when the workflow is the same.
So what? One record cannot be that bad, even though our customizers probably reactivate workflows dozens of times, it does not matter, because when moving solutions between environments, only the Parent workflow gets packaged, and the children stay in the dev. Instance.
True, this will probably not be a problem for you, unless you start comparing these workflow ids. In practise, let’s say you have an entity “Workflow manager” that is there to watch the runs of his workflow. Typically, you would create an entity, give it a lookup for workflow and then compare the ids in a code activity or plugin
But this is the part where we run into a problem. The record being referenced in the lookup is NOT the same that is used when executing a workflow. The record in the lookup is the Parent record,while the one executed in the async operation (found under owningextentionid) is the active workflow. Meaning that if you wanted to return all async operations of workflow from Workflow managers lookup, you would have to query for parentId, and not the id of the workflow.
So, there we have it, this is how CDS handles different versions of workflows, and why you must activate it instead of publishing. Give the endpoint a try and check if you didn’t accidently create dozens of records by reactivating your business logic.
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?