I’ve had several conversations in the last 30 days with both direct customers and OEM partners interested in using Decisions to add an “Automation Layer” to a database that they maintain. 

The objectives for this Automation Layer are straightforward: 

• State Management 
• Escalations
• Automated Tasking

Most of the conversations start with an explanation of how manual it is for them to update the state of any given object. Usually this requires a person submitting a form where they selected a state from dropdown list. Instead, they want Decisions to monitor key attributes of that object in the database and automatically change the state based upon some business rules. We love this use case! 

There are several ways to go about this – but one common method is to use a 1) scheduled job that runs on some regular interval that 2) kicks off a workflow where 3) rules are used to evaluate certain data and 3) based upon the rules outcomes trigger actions such as updating data or nearly any other step one could use in a workflow. 

This monitoring pattern can be used in a similar way for escalations and automated tasking. It all comes down to what steps you have in the workflow that is triggered from the business rules evaluation. This could be an email notifications, text message, automated phone call, or maybe an event kicked off in a third party system. Tasks could be assigned to users based upon the objects attributes, attributes of the roles or team members associated with that object, time of day that the assignment is made, or any other criteria that is important to your business. 

For direct customers, this becomes an easy to understand model of automating key activities related to an organizations critical business objects. For OEM partners, this becomes a value-adding offering where customers can craft their own rules about objects in their software package they want to have custom activities for without having to write any code or go through any special feature request processes.