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.
If you or your customers are running hybrid Microsoft Exchange deployment and you are using Microsoft Graph, you might have noticed that using the client_credentials grant flow doesn’t really work and ends with errors. Last week, we have had a customer who we have been integrating few systems for, and hit the exactly same issue.
Last week, we have hit a really interesting issue with our Linux machines in Azure. We “somehow” (will be explained later in the post) managed to get completely locked out of the machine, not even Serial Console could have been used to login. After bunch of time spent by investigating the situation, we managed to get it resolved.
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.
Imagine you have some tools or a framework you want to share with your company and reuse it on various projects. If you develop your tool in .Net standard, then you are in luck. Creating a NuGet package has never been easier.