Dynamics 365 Workflow – Why do we activate instead of publishing and why lookups lie

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.

Making Xrm.WebApi.retrieveRecord Synchronous calls in Common Data Service (D365 fo CE)

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)”

Co pro nás znamená nový způsob doručení aktualizací Dynamics 365 CE a jak se připravit

Microsoft chce dostat všechny zákazníky v cloudu na poslední (a tu nejlepší) verzi, a tak mění kompletně styl vývoje, podpory a nasazovaní aktualizací na kontinuální model s největší možnou kadencí.

Od V9 již není možné plánovat, kdy bude instance aktualizována.

Od února 2019 nejspíše všichni v online prostředí poběží na stejné verzi. Již nebude možné zůstávat pozadu. Krátce na to přijde nová verze V10 (duben 2019).

Nové funkcionality a případné breaking changes budou vydávány dvakrát ročně v dubnu a listopadu. Microsoft se pokusí zajistit zpětnou kompatibilitu pro rozšíření a úpravy.

Continue reading “Co pro nás znamená nový způsob doručení aktualizací Dynamics 365 CE a jak se připravit”

Unable to in-place update plugin in Dynamics 365 (with build or revision number changed)

UPDATE 19/9/18: It has been fixed in 9.0.2.5 version of Plugin Registration Tool https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool/9.0.2.5

If you use 9.0 version of Plugin Registration Tool to update your assemblies in Dynamics 365 you may encounter the following exception:

Continue reading “Unable to in-place update plugin in Dynamics 365 (with build or revision number changed)”

Novinka Common Data Service 2.0 v souvislostech

Pokud to trochu sledujete, ale začínáte se ztrácet v posledních novinkách v oblasti informačních systému Microsoftu, tak určitě nejste sami. Microsoft totiž chodí s kladivem, rozbíjí je na menší části a se snaží poskládat moderní platformu, která obstojí v dnešním cloudovém světě, kde se vše mění dříve než se to pořádně dostane k uživatelům.

Níže si můžete přečíst o situaci v kontextu CRM a platformy Common Data Service, kterou považuji za zásadní pokrok. Přinese totiž robustní informační systémy i do menších organizací a prováže technologie, které si dodnes spolu povídaly jen draze a složitě.

Continue reading “Novinka Common Data Service 2.0 v souvislostech”