Shared variables in Dataverse plugins. Surprise, surprise…

It’s a rare situation when 3 different Daraverse developers, all having quite a bit of experience with plugins, start talking about plugins functionality and can’t agree on how it actually works

Yet, this is exactly what happened when none other but Daryl LaBar suggested that I should be using shared variables to handle the problem described in the previous post

Actually, what led me to writing that post is exactly that shared variables did not work. However, I did forget that I should have looked in the parentContext, too.

That was an apparent omission, so I figured I’d find my shared variable in the parentContext. I ran a quick test… and it was not there. Huh?

Anyway, if you are curious, here is the code I used – highlighted is the line where I’m throwing an error if there is no shared variable. And that’s the error I saw:

This is where Martin Tölk mentioned we might be able to add shared variables from the organization service as per the link below:

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/org-service/use-messages#add-a-shared-variable-from-the-organization-service

Well, that’s where I had my “aha” moment! Because that should work, should not it?

Looks simple… so, here is my code this time:

Here comes the moment of truth… and it’s a bummer:

What just happened?

After digging around a little more, here is what I’ve found:

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/understand-the-data-context#shared-variables

Turned out this method only allows “tag” variable to be passed to the context.

Finally, my shared variable is there (I had to replace “test” with “tag” in the code sample above):

So, basically, I think the way shared variables work is:

• When all plugins in the execution pipeline are sharing the same context,  we can use context.SharedVariables to pass variables between plugins.
• If the context changes, though, we can only pass 1 variable using the method above, and it has to be called “tag”

By the way, we can also add that “tag” variable through Web API:

Well, that’s a viable option.

Although, given it’s only one shared variable we can use that way, I might stick to the “dummy field” method described yesterday, at least for the time being. Otherwise, there is always a chance “tag” variable would mean something completely different if other plugins/developers start using it for their own purpose, too.

Besides, it has one advantage over shared variables, since it could be used from SSIS and other ETL tools if I wanted to stop plugins from running when modifying data in the Dataverse (data migration would be one common scenario).

Well, this was interesting – not sure I’m still missing something there. Would not be too surprised (this time) if I am