Actions are a great way to implement your sophisticated business logic without the complexity of workflows. Using Actions, you can perform changes both inside your SharePoint and in external system, such as Active Directory or line-of-business applications. Actions are easy to confgure, even for non-technical users, they do not require deployment and are ready to run as soon as you click Save. And with 15 different action types, there is nothing you can't do!

Actions can be executed in a variety of way. They can respond to list events (such as items being created, modified or deleted), they can run on a timer or they can even be executed manually by a user. Let's focus on the timer-based actions. Here we have two choices, either execute based on a date column (such as run an action two days before the Due Date, with the ability to repeat) or run on a daily, weekly or monthly basis at a specific time and day (where applicable). Our newest addition is the ability to run an action every hour, for your fast-changing applications.

I'd like to focus again on hourly/daily/weekly/monthly actions. We've covered this topic before in documentation and tutorials, but there is still some confusion. Every action needs an item to run on (what we call the "current item"), it doesn't necessarily mean that the action is supposed to change this particular item (in fact is could be working with an external line-of-business application), but the column values of this item will serve as input data for the actions and the action execution result will be written into the action history of this item. Without a current item to run on an action cannot execute. In most cases, with event-driven, manual or timer-based action involving a date column, the current item is selected implicitly. It's the item that was clicked on, modified or added or one with the date value matching the action settings (say, it expires in two days and that's when the action is configured to run).

But when an action is set to run hourly/daily/etc., it is simply executed during that time and does not have a current item to run on. Didn't I just say that every action requires a current item? There is no contradiction, these timer-based action do receive a current item, but in a special way. Such actions require one of more "static" conditions. What makes a condition static? Any action can accept conditions, they ensure that the action only runs when needed. For example, Status equals Completed makes sure the action only runs on completed items. In the condition settings you select a column on the left, an operator and a value on the right. For instance, "Status" was our column, "equals" was our operator and "Completed" - our value. (For more advanced users, yes, I'm omitting "always"/"after change" setting for simplicity). Now the value part is what's important now. Here you can set static values, such as Completed here, but you can also reference column values from the item, such as Due Date greater than [End Date], in this condition we compare column values of Due Date and End Date.

Hourly/daily/etc. actions require at least one static condition. When the action is triggered, it first executes the static conditions to query the list. Such as Status equals Completed will return all items with Status Completed. Now it will go over item by item and execute itself on it, passing that item as the current item. It will then execute the conditions again, this time all of them, not just static ones and continue as usual. This initial selection of items to run on requires static conditions and you won't be able to save your action without them.

Please make sure to configure your conditions careful and as narrowly as possible, you don't want to waste your server resources going over thousand of items each time the action runs.

Hourly actions are already available in the app version and will be added to the on-premises version soon.