For example I need to declare an item as a record.

  1. Apparently there is no REST API for record management. So no declarative workflow activity and REST service calls. That leaves me with a custom code activity - right?

    • Unfortunately deploying code activities appears to be quite painful. See here.
    • Also given the fact that my workflow service might run on a completely different host than my SharePoint server I may not use the SharePoint OM - only CSOM. Or REST calls. In both cases a security context has to be taken care of.
  2. As option #1 appears to be quite invasive in terms of deployment actions I'd prefer a more "SharePoint" way to solve this problem. I recently suggested to someone else not to create tons of code activities but rather make the required functionality accessible through web service calls. Sounds good, right?

    • If the required functionality were supported by CSOM I could rely on that - the web service could be hosted anywhere. Again - a security context needs to be taken care of.
    • If the required functionality is NOT supported by CSOM I'd need to deploy a custom web service on the SharePoint server itself to be able to use the full object model.
  3. Lastly I could simply decide to use SP2010 workflows. They run on the same machine by design (can use OM).

Anything I am wrong about? Any other recommendations?


One of the benefits of the 2013 workflows is that they will run in the cloud, but this benefit does not apply to a code based custom activity. Also, any deployment instructions that involve manually copying files to particular directories are problematic, as a year from now an admin may extend the farm with another server, and needing to also copy the dlls to the new server may cause issues at that point. (specifically, not knowing about it and not copying them will cause the issue).

So, perhaps:

Use the 2010 workflow engine. Custom code based workflow activities for 2010 are fully supported and have no deployment issues. (they don't work in the cloud, and yes, building new 2010 based workflows is indeed questionable).

Or, if it is supported by CSOM, then perhaps use a remote event handler to take care of that part of the process. It would make the workflow a bit more challenging, as the logic is now in a couple different components, but remote event handlers will take care of any security concerns.

  • I prefer not to use SP2010 workflows anymore. SP2010 workflows require farm solutions whereas SP2013 code activities might possibly (I'm not sure yet) have the benefit of having some dll deployment overhead but keeping the SharePoint solution "cloud capable" (might be an app solution). Can you elaborate on CSOM and remote event handlers? – lapsus Aug 19 '14 at 6:29
  • If there's a dll, it's not cloud capable. Custom code activities are simply not supported in O365. A remote event receiver is new for sp 2013, and is like an event receiver, but the code is hosted on your server (or azure). So, when a list is updated, for example, sharepoint calls the web service that is registered as a remote event receiver, which can take actions on the list item via CSOM. For a how to, see: msdn.microsoft.com/en-us/library/office/… – Mike2500 Aug 19 '14 at 12:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.