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.Continue reading “Just In Time Access with 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.Continue reading “Merging Forms and Views – managed vs unmanaged (Microsoft Power Platform and CDS)”
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, Xrm.WebApi.
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?Continue reading “Making Xrm.WebApi.retrieveRecord Synchronous calls in Common Data Service (D365 fo CE)”
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.
System.Runtime.Serialization.SerializationException: Type is not resolved for member ‘Newtonsoft.Json.JsonSerializationException’
If you ever run into this exception without any trace available it is most likely not like it seems. Microsoft’s internal wrapper for launching CodeActivity catches it and ignores your trace log entries. So if your code throws this exception the platform treats it like internal exception. It is probably because it serializes parameters for CodeActivity into JSON and this process can produce the same exception (in Microsoft’s internal code).
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.
Did this. No luck. What now? Google…
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.
As Alex blogged we are currently facing a caching bug of plugin assemblies in Dynamics 365 cloud instances (V9). You can do an in-place upgrade with Plugin Registration Tool without an exception now (see Unable to in-place update plugin in Dynamics 365 (with build or revision number changed)) but for some assemblies it just won’t propagate to your workflow definitions.
In the past we could fix it by clicking a save button in Properties tab of the assembly in Plugin Registration Tool but this does not work anymore in V9.
I have put together another workaround which is usable in release automation scenarios.
UPDATE 19/9/18: It has been fixed in 184.108.40.206 version of Plugin Registration Tool https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool/220.127.116.11
If you use 9.0 version of Plugin Registration Tool to update your assemblies in Dynamics 365 you may encounter the following exception:
ERROR: Occurred while checking whether the assembly exists
The PluginType(00000000-0000-0000-0000-000000000000) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.