There was a time when Dynamics did not want to assign optionset values in the workflows. If you are wondering how it was, the issue(and a possible workaround) is best described here:
https://crmtipoftheday.com/870/how-to-set-an-optionset-value-in-the-workflow/
So, earlier today when somebody showed me how they still can’t assign an optionset field I was 100% certain that’s exactly the same problem. Turned out it’s not necessarily the same, though, since somebody else came up and said “try a global optionset”. Surprisingly, it worked.
So, if you are experiencing the same strange behavior in the workflow designer (if you are trying to assign one optionset field from another and it does not work), you might try using the same global optionset for both fields – it works then.
Interestingly, it also works when you are using a lookup to the same entity. It’s almost as if there were a “type validation” of some kind. Apparently, it passes for the global optionset. It also passes if it’s the same attribute of the same entity(not necessarily the same record):
PS. As a couple of people pointed out(no less than George Doubinski and Gus Gonzalez.. I guess they took it to heart that somebody is still using local optionsets), workflow designer has never had the ability to map local optionsets. And yes, the article below is talking about this behavior in CRM 2011:
I guess I simply managed to avoid this problem so far by always using global optionsets most of the times (and by not using a lot of update steps to set optionset values in the workflows:) )