Okay, let's roll. So, this talk is about workflows in SharePoint 2013. I assume all of you are somewhat familiar with SharePoint.

SharePoint 2010 at least, and you've tried and used SharePoint in general, and especially the workflows part of SharePoint 2010. And this talk takes from that knowledge base and basically talks about what are the new enhancements in workflows in SharePoint 2013, and how we can benefit from them.

I think if you've attended any of my previous talks, I've been to Norway various times, and I've never been a proponent of workflows. Workflows in SharePoint 2010 and 2007, I've done various trainings over here, and in every training I've basically said, avoid it, right?

It's not that they're bad or what, the vision is very good. But I just didn't think the biggest problem was performance and scalability, and developing them wasn't a lot of fun either. So has the situation changed in SharePoint 2013? Well, let's find out.

So a little bit about me. My name is Sahil Malik. I live in Washington, DC, but I travel quite a bit. And I'm a trainer and a consultant. My areas of interest are SharePoint, SQL Server, .NET, and iOS. iOS is basically like Objective C programming and all. I think it's time that I feel we should all look into diversifying our skills, and that's one of the things that I've been doing.

And I work mostly in America and Europe. I live in America, but I'm in Europe quite a bit. And my next trainings here in Norway are, they're with program with Vik Ling in Fornibu. And the next training is on September 2nd on WCF 4.5. After that is September 9th, SharePoint 2013, and Office 365 end-to-end five-day

training. And then the next one after that is in London on November 25th on WCF 4.5. So let's talk a bit about what is the value of workflow, right? We are techies. And when the Microsoft releases this new Surface tablet, we get pretty excited, and some of us go and buy it, right?

Why do we buy it? Of course, we love technology, that's part of it. But the other part behind this is that it's an investment in our career. We want to learn what is new, right? We want to write Win8 apps, and we don't want to work with an emulator. We want a real device to try things out, right? And the Surface tablet is $4.99 or $5.99.

They're selling it for $99 at TechEd, I heard. And it's an investment. And if it breaks, you can return it and get a new one. It's a very predictable investment. But still, we think for a long time before we make that purchase. Now, think of it from a company's perspective. A company wants to start a project,

because they want some automation done using software. And the rules are in the business user's heads, and basically they hire a team, a team of developers, a project manager, and so on and so forth. And when you hire a developer, in the first one hour or even 30 minutes, he costs more than the Surface tablet cost you, right?

And then it's not really until a month later that you know if he or she is any good, right? And also the failure rate of projects is quite high, right? So most projects and many projects go over the timelines and etc. My point is it's a huge investment for a company to hire developers and write software.

And this proposition of a business user being able to craft up the flow of what they're trying to accomplish in a tool like Visio, something that they're already very familiar with, and have it running without involving a developer, that is very, very compelling. And that is the challenge that workflow tries to solve.

So a brief history on workflows in the Microsoft platform. Workflows in SharePoint have always been three stories, out of the box workflow, some that come right out of SharePoint. SharePoint designer based workflows that you can craft them on your own. And Visual Studio based workflows where you want to add some logic or

that Microsoft didn't think of. So in 2007 is when SharePoint and Workflow were introduced to us. Workflow Foundation was a part of .NET 3.0. And SharePoint 2007 was the first engine or client that has implemented workflow

introduced in .NET 3.0 inside of SharePoint. So whenever you run a workflow in SharePoint, workflow as in 2007 and 2010, that workflow is basically a class. And the class gets instantiated and it runs inside of a process called owstimer.exe.

And the way this works is that if you've created, let's say, an approval workflow, and there are 15, 20 instances of approval workflow running on your farm, there is one instance of that class created in owstimer.exe. As you go from activity to activity, doesn't matter how many users you have,

doesn't matter how many instances of the workflow you have running, you are multiplexing one instance of that class. So what happens is that the entire state of the workflow has to be read out of the database, hydrated into that class, and then that activity runs, and then the whole thing gets dehydrated back into the database. So essentially workflows are single threaded, but

the bigger problem over here is that the workflows, they have to pay a big penalty for the serialization, deserialization cost. And in SharePoint, the database you're saving to is the content database, which is not the best performing database, it's not like finely tuned for performance, let's call it that. And also the objects that you're hydrating and dehydrating are very, very heavy.

As a result, workflows in SharePoint 2007 suffered from performance and scalability concerns, right? So there are various limits, like you can only have 100 events run at a time. You can only have 15 workflows per web front-end in a farm, right? Just 15, right?

And these limits are obviously tweakable, but even at 15, even with the out-of-the-box workflows like approval, etc., which is literally just like a one-step workflow, it would really, really hammer your SQL server. So performance was a big problem. Also, in SharePoint 2007, you had another situation where you had some of these out-of-the-box workflows,

and using them was very, very quick. But if your boss came up and said, hey, I want to change this text at the top, you're like, well, this is going to take me four months, right? And basically, those out-of-the-box workflows were not customizable. They were what they were, you know, complete black box. So the editing experience or the ability to create new workflows

was basically restricted to two tools, SharePoint Designer and Visual Studio. The problem with SharePoint Designer-based workflows in SharePoint 2007 was that you had to develop directly on production, right? It hard-coded all the goo. It hard-tied your workflow to a particular list, right?

And those workflows, you know, you could not move them from one environment to another. So when you're basically moved from QA to production story was, you know, have the same guy who built the workflow in QA and have him repeat those steps carefully in production. That wasn't a very good story. You couldn't, like, export the workflow to a WSP and so on and so forth.

In Visual Studio-based workflows, you know, the developing experience was fine. It wasn't the easiest. It wasn't the most intuitive. But let me just say this, that if you're editing UI, if InfoPath was your best story between InfoPath and ASPX, then we had a problem, right? InfoPath is not the easiest thing to manage, especially when it comes to deploying across environments.

So obviously, workflows in SharePoint 2007, you know, had issues. But I would say Microsoft had a vision, and they continued to push in that vision. So in SharePoint 2010, they introduced some changes. But one thing they could not change is workflows, even in SharePoint 2010, were .NET 3.5 SP1, which is still CLR 2.0.

So they still suffered from the same performance and scalability concerns. But they introduced some very welcome changes, mostly in SharePoint Designer, some in Visual Studio, and a little bit in the API. So out-of-the-box workflows could now be edited and modified. You can open them in SharePoint Designer, edit them as you wish, save a copy, et cetera, right?

So that was a big plus. SharePoint Designer workflows now became portable, right? You could export a workflow and move it into another environment or even import that into Visual Studio. Practically speaking, importing that into Visual Studio was not a very good alternative. I'll get to that in a second. And they introduced this capacity

of being able to create Visio visualizations. So you could take basically a Visio diagram, export it. You had to use a special stencil to create it. It was called as a SharePoint 2010 workflow stencil. Export that as a VWI file, Visio workflow interchange, and then import that inside of SharePoint Designer. Or you could go the other way.

You could go from SharePoint Designer to Visio. The end result was that an end user is crafting up a workflow visually, like drawing a diagram, and the workflow is, you know, the user sees that diagram running inside of a page. You know, they see that I am on this block and the previous block, this was the output, and this is the user that approved it. So using Visio services, they were able to render it.

And they improved the Visual Studio experience, as in that the ASPX forms are actually pretty good now, and they introduced the concept of site workflows. So they made some improvements. But there was still one big problem, that workflows still did not scale. So the question is, what have they improved

in SharePoint 2013? I would say before 2013, those workflows are so bad, I call them workflows. So I would say in 2013, the general story is still the same, right? You can go between Visio and SharePoint Designer as much as you wish, right? And SharePoint Designer can export a WSP, Visual Studio can export a WSP,

and you can do a one-way import from SharePoint Designer to WSP, right? So the general story is still the same, but they've added a couple of things. Number one, the import export story, VWI still works, but you don't need to do VWI anymore. You save it as a VSDX file, which is the XML version of the regular VSD file.

So you use Visio 2013, and you save a VSDX file, and you can import that VSDX file directly inside of SharePoint Designer, right? So the advantage over here is that if somebody crafts a workflow and they did not use the standard activities that you're used to in a SharePoint stencil, it could still be imported in SharePoint Designer, right?

So usually when somebody's crafting up this workflow, what they found is that every now and then, most of the activities or the blocks they threw on the diagram were correct, but every now and then, they've decided to put a pretty picture for a server, and you couldn't import anything. So now you can import it. Obviously, you can't turn it into a workflow, but inside of SharePoint Designer,

you can make these minor fixes. The other big thing they've introduced is that you don't even need to go between these tools anymore. Now, you still can. If somebody prefers to use Visio and only Visio and no SharePoint Designer, you can still do that. That's not a problem. But when you're inside SharePoint Designer, you can expose that Visio surface

right inside of SharePoint Designer and basically be able to craft up that visualization right inside of SharePoint Designer. I'll show that in a demo pretty soon. And then, obviously, exporting to Visual Studio, et cetera, but one thing that they've introduced is now workflows can run as an app, and they can run as a sandbox solution.

By the way, if somebody tells you that sandbox solutions are deprecated or WSPs are history, and you don't need to worry about them anymore, that's not true. WSPs are still very much with us, and it is still required for a lot of key scenarios. In fact, when you deploy a SharePoint hosted app,

a SharePoint hosted app internally builds itself using a WSP. So WSPs are not history, right? So don't forget all that knowledge that you've learned about WSPs. So I have a little quiz for you. Can anybody guess what is this picture?

Looks like a pretty complicated picture. I've heard also, this looks like a machine part. I've heard all sorts of answers to this. This is the out-of-the-box approval workflow which is one step, and I added a log to history activity at the end in SharePoint Designer, and I exported that as a WSP,

and I imported that inside of Visual Studio, right? And this is what Visual Studio creates after about 30 minutes of machine getting frozen, right? So in this little dot that you see at the very bottom, that is the log to history activity, right? So the rest of it is the approval workflow.

So even the out-of-the-box approval workflow which is probably one of the simplest workflows they have, That workflow, when you export from SharePoint Designer and import inside of Visual Studio, you can see that it's not very practical. You can't really maintain it. So basically what I'm trying to get to is that this picture right here

is practically unusable, right? You're gonna make some minor tweaks here and there, but it's not something that you can use for development. It's a one-way export anyway, but the end result produced like this is not usable. So workflows in SharePoint 2013, let's continue diving deeper into that.

Everything before this, so the workflows that we used to have before this, you know, 2007 and 2010, now they call them SharePoint 2010 style workflows, right? And that's basically a dead end, as in all the investments that you've done in SharePoint 2010 style workflows, which is workflows in SharePoint 2010 and before,

they will run in SharePoint 2013, but they run as what we call as SharePoint 2010 style workflows. No improvements there. They'll still continue to not perform well. They'll still continue to have all the problems that we had with them in the past, right? And they are available in SharePoint Foundation and all SKUs of SharePoint, but if you have SharePoint Enterprise,

like you know, SharePoint 2013 is SharePoint Server, and then you buy Cal. So if you enable the Enterprise Cal, then you can use what they call as SharePoint 2013 style workflows, right? Now these SharePoint 2013 style workflows and 2010 style workflows are completely different from each other, right? They're very different from each other.

So what are SharePoint 2013 style workflows? They run in a completely separate product called as Workflow Manager. Workflow Manager is not a part of SharePoint. It is developed by a completely separate team, and SharePoint is one of the first clients that uses Workflow Manager. Could you write your own application in .NET

that uses Workflow Manager? Absolutely. You can write these workflows in XAML. They don't use XAML anymore. So in fact, what you can do is that you can craft up a workflow, and because SharePoint 2013 uses PowerShell 3.0, PowerShell can now instantiate these workflows very, very easily, right? And they don't even have to be SharePoint workflows.

They can be any sort of workflow, and you can leverage them via SharePoint workflows or you can leverage them via PowerShell or any other platform you wish. So they run in a completely separate product, right? And that separate product is a server, a Workflows Manager, that integrates inside of SharePoint using a couple of PowerShell scripts you have to run.

So inside of Office 365, this is already set up for us, and they're using OAuth2 over there. And on-premises, they use a different protocol called S2S Trust, which some people call as one-legged OAuth, right? So it's like a diet version of OAuth. S2S Trust is not a standard, but it is something that we're hoping

will become a standard. But on-premises, you would register this server using S2S Trust. These workflows, because they run outside of SharePoint, they can actually scale and perform quite well. And you can, even out of the box, even on one server environment, the performance is like hundreds of times better. Like literally the same workflow written

is hundreds of times better. Remember that you get 100 times better performance with the same convenience that you have in SharePoint Designer, like you can craft a workflow visually. In fact, they've made some improvements over there too. So finally, they're sort of delivering on their promise here. And the users, however, will notice just one big difference,

that you can no longer attach the SharePoint 2013-style workflows to a content type, right? If you're very used to attaching a workflow to a content type, SharePoint 2010-style workflows can still be attached to a content type, but 2013-style workflows attach basically the item content type. Why did Microsoft do this? Because basically attaching a workflow

to a content type is a very cumbersome operation inside the scene, and especially when you update the workflow, they have to iterate through all the instances of the content type, all the inherited instances, and basically run a lot of code to fix that. So a better way to do that is basically, you have the content type column available to you, you can just check it as a string,

even the content type ID, you have that available to you, and you can base your logic based on that, right? So they've basically, you don't attach them to a content type anymore. SharePoint 2013, SharePoint Designer. What are the improvements they've made there? Number one, they've added the concept of loops, right? Doing loops in SharePoint 2010 was possible,

but it was very cumbersome. There's some black knowledge that you place your activities in a certain way when you get a loop. They've introduced the concept of stages, and they've finally given us the ability to do copy-paste of activities, right? Copy, paste, cut, redo, undo. These are basic operations that you could not do in SharePoint 2010,

SharePoint Designer 2010. As I mentioned, Visio is embedded inside of SharePoint Designer, and you no longer need the VWI format. You can work directly with the Visio format. If you want, open that in SharePoint Designer directly. What are the improvements they've made in Visio Studio workflows? I think from a maintainability point of view, the one biggest improvement I see

is that these workflows can now be deployed as apps and as sandbox solutions. One little point I'll mention I'll make is that the out-of-the-box templates, when you create a workflow, it adds the workflow, and it adds the feature in a SP site scope feature, and that's a bug in the current Visio Studio tools,

even in preview too. What you have to do is that for you to be able to see that activity, you have to change the scope of the feature to web, and then you'll see that feature. We'll see that in a second. One other big change that they've made is that the extensibility story, or basically extensibility story is SharePoint Designer is not cutting it. I need Visio Studio to extend what workflow does.

So I'm gonna write custom activities. There are two kinds of activities you can write, one that you should and the one that you shouldn't. The ones that you should are the ones that can work in apps, they can work in Sandbox solutions, and they'll work in Office 365, and those activities are completely declarative.

You write them completely in XAML, and you'll see that writing that activity almost feels like you're working in SharePoint Designer. It's literally like drag drops at a bunch of properties, hit F5 and it works. Well, you have to do a little bit more than that, but it's almost that easy. You have to edit a XML file. And the other kind of activity that you shouldn't write is basically what is pretty similar

to what we used to do in SharePoint 2010 is that basically we would have to register the DLL, and then we have to go find this .actions file, edit it in Notepad because WSPs couldn't update that, and if you deployed a patch, like a service pack or something, you had the danger of losing your activities, and you'd have to redo those changes.

It's too much of a hassle. Even on-premises, I would argue that it's too much of a hassle, so I'd just say stay away from writing those sorts of activities. Instead, just use the declarative activities and put your custom logic in web services. But the bad news. The bad news, SharePoint 2010 workflows continue to suck.

There are no changes there. And there is no upgradability story from SharePoint 2010 style workflows to SharePoint 2013 workflows. So basically if you've invested heavily in SharePoint 2010 style workflows, the only thing you can do is that you can instantiate

a 2010 workflow from 2013 workflow and a 2013 workflow from a 2010 workflow, and that's it. There is no point-and-click upgrade process, and this applies to even all the third-party products that have invested heavily in Workflow Foundation. So we know they're going to have to come up with their own solution.

There are a lot of limits that apply to workflows. You'll get a copy of all these slides, so there's no need to read each one of these one by one, but as you can see, there are a lot of these that have a postponed threshold, 15, right? It's 15 concurrent running, it's a workflow timer batch size, 100,

picks up 100 jobs at a time. Workflow associations, not published, 100 per list. So there are a lot of these limitations that feel like they're pretty low, as in that you can't have a, it's not something that can support thousands of users on one web front end, for instance, which is not that much to ask for, right?

The good news is most of these don't apply to SharePoint 2013-style workflows. SharePoint 2013-style workflows, there's just a couple of these in here that say maximum workflow definition size is 5 MB, right? So if you're written five megabytes of XAML, well, maybe there's a different problem there,

but that's the maximum size you can go to. That applies to SharePoint 2013-style workflows. I'd say that is not such a big deal, and you can go up to 121 levels deep in nesting your workflow, right? Well, that's not such a problem. 121 levels is quite a lot. There is another limitation that the workflows you want to talk to on-premises service bus on Windows Server App Fabric,

you know, there's a timeout issue because it's basically a WCF service you're talking to, but that's like 120 seconds. Again, not that much of an issue, right? So the workflow limits for SharePoint 2013-style workflows, not so bad. Let's talk a little bit about setting up Workflow Manager. Setting up Workflow Manager is quite easy.

Step number one, you have to install Workflow Manager, right? On a dev machine, you know, when they RTM the product, you could not install it on the domain controller. In Beta 2, you could, okay? But in RTM, you couldn't. So I had a little chat with the program manager at Workflow, and he was like, hey, this is really gonna kill a SharePoint developer.

You have to allow us to install it on a domain controller because, you know, on our development VMs, we have a domain controller. We don't wanna have to run two VMs. SharePoint alone is heavy enough as it is. So they made a little change in the product in literally 14 hours, and they introduced Workflow Manager 1.1, which you can install on a domain controller, right?

So, you know, when you install it, it'll go through some prerequisites, and it'll update those on your server. And if you don't have access to the internet, I've included the offline installation command. It uses WebPI, but this offline installation command will basically go through the steps of, you know, it'll download all the necessary components, and I can tell you, on like two images, it gives you like a 404 not found,

but everything else it downloads, and you'll copy this entire installation, take it to your SharePoint server, double-click install, and I have a book on Amazon setting up your SharePoint 2013 dev VM, and I detail all the steps in there, including end-to-end setting up your SharePoint VM. So you download Workflow Manager, double-click on it, start installing it, right?

Basically takes you through a little wizard, right? So configure, refresh, then after it is installed, it'll present you with a screen like this, right? And this'll allow you to set up Workflow Manager. It's very simple, it'll ask you some basic questions, like I need to talk to a SQL Server database, what ports do I want to use, et cetera, right? So basically, and you can also, you know,

join an existing Workflow Manager form. So then basically it goes through this wizard, it gives you the option of doing this through PowerShell if you wish, right? And it'll actually generate the PowerShell script for you. And then you basically set this up, right? So at the end of it, Workflow Manager is set up, but then you have to do one more thing. And the one more thing that you have to do

is to register the Workflow Manager inside of SharePoint, right? So by default, not every SharePoint site will be able to use Workflow Manager. You have to explicitly allow it to be used. And I'll tell you all those historical sites, like the blank site and those enterprise, you know, the meeting workspace and all those,

they cannot use Workflow Manager, right? In fact, they've been removed from the user interface, but they're still there. And if you're using a SharePoint site in like SP 2010 compatibility mode, it'll run fine in SharePoint 2013, but it won't be able to use SharePoint 2013 style workflow. So, you know, running this will set up two IIS websites.

One will be running on HTTP for dev purposes. Another, that'll be running on HTTPS for production purposes. One golden rule about SharePoint 2013, everything should be HTTPS, everything, including on your intranet.

So one of the big changes, as you know, they've introduced as the apps model. I'm here for the rest of the day. If you're gonna chat about apps or anything SharePoint 2013 in general, I would love to brainstorm with you, right? But as a golden rule, everything in SharePoint 2013, even on an intranet, has to be HTTPS, or I would not consider that

as a production-worthy SharePoint installation. In fact, they're so firm about insisting on HTTPS that when you export an app out of Visual Studio, they won't let you specify an HTTP URL. Now, of course, you can get around it by renaming the app file to .zip and editing the XML and all that, but they try very hard to discourage you

from basically using HTTP URLs. Dev is fine, production, absolutely not. And this is the command you use to pair Workflow Manager with a SharePoint site collection, okay? So this is great. I mean, it works. Allow OAuth over HTTP, that's for dev purposes only.

But do you see a big problem with this command, right? Basically, what you have to do is you register at a per-site collection level. You can't say this entire web application uses it. So as new, I mean, you can run a PowerShell command that runs this in a loop and basically sets this up for all site collections that are currently in existence.

But what if you create a new site collection, right? You have to either run this PowerShell command again or basically write a feature, farm solution, to be able to do that, right? So that's something to keep in mind. So when we talk about workflows, there are three main things to learn from here. We talked about how to set up workflows. We know the history of workflows.

Now there are three main things to talk about. Number one, what are the improvements in SharePoint Designer? What does it feel like writing workflows for SharePoint 2013-style workflows in SharePoint Designer? Second, what does it feel like to write Visual Studio 2012 workflows? And third, writing a custom workflow activity.

This talk is just one hour, so I'll try and compress time a little bit. This is my SharePoint environment. I have central administration running, and I have a team site created. Remember that a blank site can't use these workflows. Even a blank site in 2013 mode can't use these workflows. So you see that I've created a site collection

at slash site slash WFS. So this site collection has the ability to run SharePoint 2013-style workflows. I've ran that PowerShell command on it already. So I'm gonna go ahead and open, let's say, SharePoint Designer, and I'm gonna open this site in SharePoint Designer. So everything is running on my VM.

You work with SharePoint to know that VMs can sometimes misbehave. So I open HTTP sites WFS, and I'm gonna look for the workflows node over here and click on this. So golden rule with SharePoint Designer, wait for this red thing to go away before you do anything. So here we go. So you see here that I already have a workflow.

And you see here that I have a bunch of buttons up here. List workflow, pretty much the same as a SharePoint 2007-style workflows. Hard ties everything to a list. Reusable workflow, you tie it to a content type. Site workflow that you don't need to tie it to an item, runs at a site collection level.

So those are things that are same as before. All these settings are probably pretty familiar to you. They've introduced a couple of interesting things. The import from Visio, they've added the option of importing directly from a Visio 2013 diagram. That's the VSDX format. It doesn't need to be a VWI format anymore. So that's an interesting thing.

I'm gonna go ahead and add a new workflow. So I'm gonna say new, let's say, let's go with site workflow. Actually, now let's do reusable workflow. So you see here, same as before, with one big difference. You see this content type is all, and it's disabled, because I've selected a SharePoint 2013-style workflow.

And if I choose SharePoint 2010-style workflows, I can associate it with content types, right? So SharePoint 2013-style workflows can't associate it with content type anymore. So I'm just gonna go ahead and create, let's say, a test workflow, and click OK. So you see here that it presents me with

what they call the text-based view of my workflow designer. And I can start typing in activities just like I used to before. So I can say, let's say, so as I type this, I hit enter, you know, it gives me these various options, right? I can go ahead and rename a stage. I can choose to add more stages.

So I can say go ahead and add another stage, right? So I can call it first stage. And here I can go ahead and add a second stage. And then let's say add two more stages. So let's say my logic over here is that the first workflow does something like start, then the second workflow checks for something,

and then it redirects either to the third stage or the fourth stage, like a success or a failure. So I'm gonna add two more stages, call one of them success, right? And then I'm gonna add another stage at the end here. So I gotta come in here and add another stage and fail, okay?

So I've added these stages, and they appear in sequence, but that sequence is actually arbitrary, because really the workflows are connected to each other through arrows, like, you know. So the sequence over here, the kind that I'm visualizing in my mind is like a Y structure. So first stage, then there's a decision, and then I go to either success or failure, right?

So how can I visualize this as a Y structure? You know, in the previous version of SharePoint, what I had to do is that I would have to, you know, I would have to export this to like a Visio format, try and visualize it over there. But now I can just go here, and I can go to something called as a visual designer view.

And in the visual designer view, it is generating the Visio stencils, and then the visual designer view will be disabled if you don't have the right version of Visio installed. So since I have that version installed, I can, you know, basically view this like that, right? And I can, you know, try to zoom out a little bit so we can see the whole thing, right? So this is how my workflow looks like.

If I was to drop activities inside of here, so I can basically just start going back and forth between these. So I can go back to the text-based designer, and then I can just go ahead and add a log which is workflow started. Okay, so I added this activity here. I'm gonna go back into this visual designer, it's thinking hourglass,

and you see here that, you know, the workflow appears inside of here, right? And I can now go ahead and start arranging these in a different way if I wanted to, right? I can say this basically goes down here, and this is the Y pattern, and from here I can go ahead and connect these dots like a connector tool. So I pick this, and this is a little tricky.

You have to basically hover right on the block where that square appears, and connect it from here to here, right? And I can, you know, go ahead and craft up my workflow like this. And then, you know, I can also do something called a generate stage outline. Now I have to resolve these issues. But in a stage outline, what happens is that it gives me like a zoomed out view of the workflow.

So, you know, it's basically if I want to see the details, I go inside the view, but if I want to see an overview, I go to a stage outline view. So it just shows me just the outlines of the stages that I don't want to see all the activities inside, right? So I can do all of those things. Let me go back to the text-based view. Oh, now it won't let me go there,

so let me just create a new one. So I'm gonna go ahead and create a new reusable workflow, test two. And I can also go ahead and start introducing loops inside of here. I can try to introduce something called as loop end times or loop with a condition. And, you know, basically, you know, so this is, again, something that, you know, doing loops has become fairly convenient.

And cut, paste, copy, paste, those things also work, right? So I can just go in there and say run this loop, you know, 10 times, for instance. And, you know, whatever is inside of there will run 10 times, right? So writing a workflow in SharePoint Designer has become a lot easier. I've also deployed a custom activity over here. And that custom activity is something called as,

you know, it basically goes out to YouTube and fetches some songs. So I can go in there and I can say YouTube. And see, it finds my custom activity inside of here, right? I can hit enter, and then in this custom activity, you know, I can configure it in a certain way that I can pick the category, number of songs, and output to a certain variable type.

So I can make, this is like a dropdown, I can go ahead and say top 20 songs, and I can output to this variable called response content. Basically the output type of this particular activity was a new kind of data type that we introduced, something called as dynamic data. And what dynamic data allows me to do is that it is great to be able to stuff in

hierarchical information, like JSON. Hierarchical information that I don't know the structure of ahead of time. And then I can work through that information in a syntax that looks very familiar or very similar to XPath, right? It's not XPath, but it is very similar to that, right? So using that structure, I have the ability to look through that data.

So the response content automatically added a variable for me of data type response content because it knew that this was the output type. And this has basically been set up over here, right? I can add more variables, I can access these variables, et cetera. Anyway, that's how you write a workflow in SharePoint Designer. Let's dive into Visual Studio.

And I'm gonna put all these together in a working example at the end. So I'm gonna start up in Visual Studio. I'm gonna go ahead and create a new project. And I'm gonna go into Office and SharePoint, and I'm gonna go ahead and create a sandbox solution. You can do this as an app also, right? So I'm gonna go ahead and create a sandbox solution. Right click, empty project, right, okay.

And that's fine. And I'm gonna target slash site slash WFS. Okay, so in here, I can go ahead and I can say right click, add, new item. And remember, this is a sandbox solution. And now I have the ability to write, you know,

a workflow in a sandbox solution. But you see that the older project models, the sequential workflow and state machine workflow are still there. These are the SharePoint 2010 style workflows. So I'm gonna go ahead and add a regular workflow. I can also choose to add a custom activity, right? And you'll see that the editing experience of both of them is actually quite similar. So I'm gonna go ahead and add a workflow.

I'll basically make it a site workflow. Hit next. And history list, I'll just, you know, pick the existing history and task list, hit next. And user will start it manually and hit finish, right? And let's wait for this to load up. Now, you see that there is one big difference that I see over here already.

There is no on workflow initiated activity over here, right? In the previous version of SharePoint workflows, 2010 style workflows, I had to be very sure that the first activity was on workflow initiated because if I put my activity on top of that, basically everything was screwed up, right? My workflow would not run.

And sometimes, I ran into situations where even if I moved my activity down there, you know, it didn't really fix the workflows. I had to do like a get latest from source control again. Anyway, so you can see here that, you know, I can start writing activities inside of here, but I can also do something like, you know, create variables, right? So I can create global variables. Let me actually, before I create variables,

let me go ahead and drop an activity inside of here. Just any random activity. So let's say create list item, okay? So as I drag drop create list item here, it shows me these exclamation marks. It says one of the children has validation or error warnings. So list ID was not supplied, right? So I have to specify a list ID here.

And now Visual Studio is frozen. It's basically talking to SharePoint. Okay, right. So I have to specify a GUID. Can I query this GUID in a way? Yes. Basically, it's a simple REST call to be able to query that GUID and I can drop a HTTP send activity

to be able to query that GUID. But I'm guessing that when I query using HTTP send, I would want to store that variable, the output of it somewhere. And this HTTP send is gonna return me a value and it's going to be JSON. So how do I parse that JSON? So I'm gonna create a value or a variable

at the global level, at the sequence level. So I'm gonna go to variables and I'm gonna say JSON output. That'll be the name of the variable. And the variable type, I'm gonna basically browse for types and I'll search for dynamic value.

Okay, here we go. So to support this dynamic value concept, they've added a whole bunch of activities and improvements in the framework to be able to do that. So I added this dynamic value activity and now I can basically say list ID is equal to that,

what was the, forgot the variable name now. But I can just type in the variable name here and that is how I can exchange information between these. I can also go to this HTTP send activity and this is like a composite activity. Basically I can use like a tree view or a breadcrumb sort of a way to craft my workflow and I can go from one activity to another to another.

The cool thing is that everything that I'm doing over here is declarative. What you won't find in here is right-click view code. There is no such ability. I can't have code behind to this, right? Completely contained in XAML. This workflow is completely contained in XAML. Now what is it like? So this is a simple workflow being deployed

as a sandbox solution. We'll see a full example later. But let's also see how you can write a workflow activity. So I'm gonna say right-click, add new item, and I'm gonna choose to add a workflow custom activity. Now when I choose this, I'm creating the new good kind of activity,

the kind you should, right? So the XAML kind of activity. I'm gonna click on add, and it looks very much like writing a workflow, right? In fact, if you know how to write a workflow, you already know how to write an activity. It's basically the same way I can drag-drop, I can build URI, I can get S2S security token, right?

I can do all of these things inside of here. Get S2S security token. They've given us the ability to get that token so we can make an authenticated call into SharePoint when we are running as an app, right? Generally I want this above here, right? So I can edit the workflow very, very easily over here. So this is pretty good.

How do I deploy this activity? If you go in here, and you see that there is this actions for file, I have to do two new things here. Basically just edit this actions for file to draft up the details of my activity. There is no visual designer for it. You have to do it by hand, but it's not difficult. And what I do, I pick a file from my C drive and I edit that.

That's the easiest way. And I have to come in here, go to the features node, and double click on feature two. You see that my activity has been, okay, so they fixed this bug. So this is in a previous preview. They would set this to a site level feature and then my activity won't show up. So this has to be a SP web level feature for the activity to show up inside of here, right? So now I can go ahead and package this up as a WSP,

hand it over to somebody, and they can deploy it and the workflow can run. So next I'm gonna talk about a functioning example of writing a full activity. And we'll see how exactly that works. But before we do that, let's cover some concepts about activities. So we talked about writing workflows

in SharePoint Designer. We talked about writing workflows in Visual Studio. Now let's talk a little bit more about custom activities. A workflow is made up of activities. Why did Microsoft give us this ability? Because Microsoft can't imagine every scenario that we may have to deal with. You know, clicking on this button approves that travel expense in an ERP system

and turns that TV on. Microsoft couldn't get this, right? So we have to have the ability to write these activities. Generally, a workflow is made up of activities. The XAML file, if you were to open up a notepad or right-click view code, this is what you will see there, right? So it's basically a sequence and a bunch of activities in here. So you see P build dynamic value, right?

HTTP send, right? So this is how a workflow looks like. And a activity, there are two concepts we need to know. Activities and actions, right? So an activity is what we use, right? Is what we use in a workflow is an activity. And an action is what an activity is built on.

So an action is like, you can think of it as a, you know, my class library that implements this action, right? So generally speaking, 99 out of 100 times, you'll see there is a one-to-one mapping between an activity and an action. Sometimes there are exceptions, like start a workflow, list workflow or site workflow. Underneath the scenes, it is basically the same action,

but with some XML, we can make it look like two different activities, right? So you define these actions in a new file format called as .actions4, right? It is embedded deep down inside your SharePoint 15 Hive. It is farm-scoped. But now you can also deploy it as an app

or as a sandbox solution, okay? So this .actions4 is a successor of the .actions file. By the way, when I say deploy it as an app, one thing I want to mention, even if you're using provider-hosted apps or workflow, you're going to need an app web, right? Because that's where you register the workflows. You need an app web there.

So it is a succession of .actions file. It is located at that place, and it basically contains a list of workflow actions or workflow for. This is basically where it lives, right? So you can see the .actions file is there. That's the older kind, and then the .actions4 file is there. So what I do, I open that in Notepad, copy an existing activity,

and start making changes to it. And this is what the out-of-the-box activities look like. For instance, you see that trim string activity, right? So you see here, it's got something called as, I have an action, class name, assembly, applies to all category utility actions, okay? It's pretty self-explanatory what that is doing, okay? Then I say, rule designer, sentence,

trim %1, output to %2. You know in my activity, I had download from YouTube in category, blah. That blah is a parameter, right? And that parameter, you would say %1, right? And in %1, down here, then you can define all the parameters, and also the data types of those parameters, right?

So this is how you write the .actions4 file. It is XML, yes, we have to edit that XML, but you see that it's not very hard to edit, right? So you see here, this is like one action, and I define the rule designer, and then I define the parameters. And this basically crafts up my activity, right? So as I mentioned, there are two kinds of activities,

declarative and coding activities. You know, we should just go with declarative. So I'll just code activity, just avoid it if possible. Already talked about dynamic value, so I'll skip over that. Prerequisites to write an activity, what do we need? We need SharePoint 2013, we need Workflow Manager, we need an environment that is running SharePoint.

But the good news is that, you know, if you're writing an activity that is completely declarative, you don't even need to run on the SharePoint VM. You can run Visual Studio on a Windows 7 or Windows 8 machine, and target Office 365, or target an on-premises environment, right? That will also work. But you do need the developer tools installed,

the Office developer tools installed. So let me go ahead and dive into a fully functional example. So this is a custom activity that I've written, that, you know, the same activity that basically gets songs from YouTube. And I double-click on this activity node.

You'll see here that I am, you know, there are two activities inside of this. So one activity has got two activities inside of it. First is build dynamic value, second is HTTP send, right? So basically what I'm doing here is I drop these activities

and I basically want to be able to craft up like a JSON URL with all the details. And then I do an HTTP send, which is just a JSON API to call YouTube, right? And this is the URL. And then I basically output that value into a sequence level variable. It is there, believe me, it's somewhere there.

It is there. But it outputs the value into a dynamic value type of an output variable. Once I've done that, I've crafted up the logic of my activity. Then I open the actions file and I start crafting up, you know, how this will look like in SharePoint Designer.

So when somebody searches for my activity, the sentence I want to show them is search YouTube clips in this category to top blah, right, so this is how it'll look like in SharePoint Designer. Number two, I basically say that I field bind ID is equal to one. So for the first field, right,

these are the drop down values that appear, right? So these are the possible values that the user can pick. Then the top end, I say that this is going to be of type, you know, integer. And, you know, designer type text area display name top end. And the last one is going to be dynamic value.

And the parameter data types are declared down here. This one is a string actually, right? So I define the data types, I define my workflow activity like this, right? And you see here that this is getting deployed

as a module tag, okay? So basically I copy them into a certain location inside of the content database using SP web level feature. And I deploy this, and as soon as I deploy this, SharePoint Designer can see this activity. One thing I'll mention to you is that,

let's say we deploy this and you don't see this activity in SharePoint Designer, okay? What SharePoint Designer does is that when you open SharePoint Designer, it downloads all the data of the SP web, okay? And it caches that deep inside of your C user data folder somewhere, right? And if you don't see the activity, you need to go in there manually and delete that cache

and then open the site again in SharePoint Designer and you'll see it. There's a little issue in SharePoint Designer. So now I've crafted up a workflow based on this activity. I'm gonna click on Edit Workflow. So as you see here, then my workflow has got one stage and it's got one step and a loop, okay?

And step number one is I'm calling YouTube, right? And I basically search in the music category, top 10 output to this variable, right? Then I've created a global variable called index, right? The purpose of this index variable is that I've gotten the first 10 songs and I'm gonna run a loop 10 times

and I'm gonna increment index one by one. And I want to be able to find this particular data from the output JSON value, right? So this workflow knows a little bit about the JSON structure. If the JSON structure changes, my workflow will break. But you know, if the workflow breaks, it actually gives you a decent place

to see the full exception message now. Basically the workflow history shows you like an exclamation mark. You hover on it, shows you a tool tip with a full exception text and it's actually pretty easy to read. Variable response content, output variable title, okay? And then I create a list item in a list that I've already created, right? And output this to a variable called create, okay?

So then I increment the loop count and then I read on the loop, right? So when the loop runs 10 times, I've extracted all the items and basically that's all I need to do. Then I would save this workflow, I would publish this workflow, and now I have the ability to run this workflow. So I'm gonna go to my SharePoint site.

This is a YouTube list. You know, I don't see any workflow, any data in here right now. I'm gonna go ahead and visit that site in a separate tab. And where it's a site level workflow, so I'm gonna go to site contents and I will look for site workflows and I will start this workflow, right?

So hopefully I am online. Hopefully, we'll see. Yeah, so I am online. And if we give it a minute or so, you see that it was able to download

the first 10 songs, top 10 songs. Looks like Gangnam Style is on top again, right? So it's able to get the top 10 songs from YouTube and put them inside of this list, right? I was able to achieve this with zero code. Now, I can use another new facility in SharePoint 2013 to create a view on this list using a new facility they've introduced called JSLink, right?

Writing a view using JSLink is extremely simple, right? The good news over there is that I can write a view in JavaScript. I don't have to do it in XSL because you can't debug XSL, right? So if I do this in JavaScript, I can set a breakpoint, I can see what's going on, I can use CSS, I can use JavaScript. You know, just how we write views in other platforms,

now you can do that in SharePoint. And I could easily also save the URL of the video, that's part of the JSON feed, and render that as, you know, YouTube clips. That would maybe take 10 minutes to do, right? If I had the embed tag ready, it'd probably take 10 minutes to do, right? So it's very easy to be able to, you know,

set up something like YouTube or whatever scenario that you may envision, you can do that very, very easily using Workflow Foundation now. Okay. Last tips. I have seven minutes left, and it'll open for questions. Couple of best practices.

Number one common mistake I've seen with workflows is to use a workflow history list as an audit log, because, you know, they say, hey, workflows are great, because if anybody changed something, you can go in there four months later and look at the audit log and see who changed it, right? Okay, sounds good in theory. The problem is workflow generates a lot of audit logs,

and that audit log history list is going to get bigger and bigger and bigger and bigger, right? So the workflow history list, what you have to do, that you should set a policy on that to move items out of there and archive them somewhere else, okay? There's a list of millions of items, not a good idea. Number two, keep initiation activities to a minimum, right? So when the workflow starts and the first activity,

you just have basically like a placeholder activity, and the end user perception will be that the workflow started quickly. You know that's a working on it spinner? You won't see that for a long time if you don't have a heavy initiation activity. Number three, for very large lists, when you upload a new version of a workflow,

set the old version of the workflow to no new instance, because if you were to not do that, basically if you remove the workflow association, it basically removes that column that is associated with the workflow. And removing the column, the time taken for that is directly proportional to the number of items

that you have in a list, right? So if you have a very large list, remove instances in the middle of night, right? During business hours, set it to no new instances. And obviously, don't let workflow manager or any of the S2S certs expire. There's some partial scripts out there that you can run easily on your farm and find out exactly what certs are about to expire,

and that is something that you should diligently do, because then this is a problem we'll run into. You can analyze workflows in two different places. They've added, this is new in 2010, 2013, that they've introduced a category called Microsoft Dash Workflow. Any errors, et cetera, in Workflow Foundation will show up there, and a second location

is that in the database in Workflow Instance Management DB, there is a table called debug traces. It is perfectly okay to run a select out of this. You can run a select out of this, and if there are any issues that you're trying to diagnose around workflows deep down, you can do that from here. Here are a couple of links and references that I've included, and you'll get a copy

of all of these slides, or just email me, and I'll send you this list. But these are, if you're interested in SharePoint 2013 style workflows, in SharePoint or even otherwise, this is a very good reference for that. And please leave a feedback. Hopefully it's green, and I'd love to take any questions at this point. And thank you for attending.