Hi,

Once you realize that simply storing your data in SharePoint lists doesn't actually do anything, you know you need to throw automation and business process management into the mix. Whenever a user saves an item, things need to start happening behind the scenes, such as additional updates, additional items being created, external systems being called, emails being sent and so on. And as a SharePoint professional, you know that all you need is the good old workflow engine, right? Well, not necessarily.

Despite being deeply integrated in the SharePoint experience, workflows are not always the right tool for the job. I personally had a lot of experience with workflows back in the day, building custom ones using Visual Studio (and other tools) or even simply using SharePoint Designer. And I always had a feeling that things are just too complicated for a tool that is supposed to give a quick and easy solution to regular users, not hardcore developers. There are just too many moving parts, too many steps and even the approach itself targets mainly people with prior knowledge or experience in workflows.

There is one scenario I like bringing up while talking to people. When I create an item in a regular SharePoint Contacts list, I have a field for Last name, First name and Full name. Full name is basically a combination of First name and Last name, so the question is: would you create a workflow to fill in Full name automatically if left blank? I would say that almost everyone I talked to said no, it's not worth the trouble. They would prefer their users to work a bit harder, than to develop, deploy and support a workflow. And this is how we know we have a problem.

You could say, workflow engines are great for complex, multi-stage processes, that's their main purpose. I will not argue here, although not sure I would agree either. The thing is that the vast majority of automation needs are not those complex processes, they are actually the small improvements, like the Full name above. Those completely fall under the radar, because they are not worth the effort of the workflow developer.

This is why we had to develop a solution that would be simpler, easier, non-technical, but yet as powerful. And we developed Actions. Actions are everything workflows are not. They are light-weight, autonomous, simple to configure and require no deployment. They can be added, modified and removed one-by-one, without distrupting the whole system, as the need occurs, and do not require extensive workflow-specific knowledge. In fact, there is no flowchart involved whatsoever! And creating a solution based on actions takes minutes, not days.

Let me list just a few of the main differences between actions and workflows and let you make up your own mind:

Initiation

Workflows are started automatically, when an item is created or updated or they can be started manually. Actions can be initiated through a variety of events (item created, modified, attachment added, document checked in, etc.), but they can also be started on a timer (2 days before the due date, or every Friday), and manually (a lot simpler, through a dedicated ribbon button, that can be shown or hidden based on the user permissions. Another huge differences: actions can even run before you save the item, so you can perform additional checks and even prevent the item from being saved if needed. Quick example: room reservation system that will prevent you from double-booking resources!

Action Types

Built-in workflows (using SharePoint Designer, without any fancy 3rd party extensions) are pretty limited. Even when using Flow, the extent of customizations you can implement is not that impressive. How about creating a new SharePoint site, managing item permissions, creating a user in Active Directory or even simply create an item in a list that the user doesn't have permissions for? You can do all that with actions, simply and easily.

Development Time

Workflow starts with a flowchart. Even the simplest one. You wouldn't believe how many people would stumble at this step already. Despite what you keep hearing, it's not natural for everyone to think about what they need to do in the way of a visual flowchart, some people just don't work that way. Actions don't use flowcharts. Each action is created separately and is simply configured to run when it's needed (for example, when an item is created or the approval status is set to Approved). Save the action and it's ready to go, there is no deployment, multiple workflow versions and no specialized tools to learn. It's not uncommon to develop and deploy a whole solution using actions in under 20 minutes!

Ultimate Forms Integration

Because Actions are a part of Ultimate Forms, there are many ways in which they interact with other UF components or provide unique functionality. There is an action to generate Associated Tasks based on a user/group field value (each person get an individually generated task) or you can use Signature columns in conditions as Yes/no. There are lots of other examples as well.

The purpose of actions is not to replace workflows. In fact, there are many scenarios where a workflow might be the right tool for the job. Actions are there to provide you with an alternative and to avoid complexity where none is needed.