As you can see, the structure behind a workflow is very similar to a plugin. The syntax and the objects to retrieve the organization proxy service and the context are different, and the way to access the input parameters is also different. However, once inputs are established, the business logic and the data access layer remain untouched.

In step 1, we started by importing namespaces specific to workflows that give us the parent CodeActivity class, and the input parameter class and attributes.

In step 2, we changed the class definition to inherit from CodeActivity, which helps Dynamics 365 identify that this is a custom workflow activity.

In step 3, we defined a workflow input parameter to feed the workflow activity the account GUID. This step is not necessary for the workflow, but it will be used in the next recipe.

In step 4, we changed the signature of the Execute method to override the CodeActivity parent class Execute method.

In step 5, we refactored the code to allow us to extract the organization proxy service from the workflow context.

In step 6, we retrieved the account GUID from the context primary entity ID if the input parameter is an empty GUID (not set). We then traced the value that was passed to the input parameter (again, this last step is optional). We passed the GUID to the GetEmails method. The rest remained the same.