Note: Dynamic workflows do not as far as I know yet exist in any business process automation software or solution
A dynamic workflow is, very simply, a workflow that is automatically created and destroyed by the business automation software.
In traditional business process automation software solutions, such as Salesforce, you automate a business process by analysis the process and then coding it into the software. It is launched when one or more conditions are met and completed when all the actions associated with it are completed. Conditions can be based on any structured data that the software has access to and actions can be anything that the software can do itself or trigger in external applications through connectors.
An example would be to send a customer an email automatically on his birthday.
Problems with Traditional Static Workflows
This is great and it has enabled businesses to massively increase their productivity. There are a number of problems with this approach.
- It suits businesses with well known and well mapped processes
- It is time consuming and often tedious, difficult and expensive to implement (or all three)
- If the business changes a lot of the automation has to be reviewed for relevance and effectiveness
- It can increase the costs of organisational change
Creating a Static Workflow
An example is a small change that I made to a Salesforce instance recently. In this case there was a certain category of opportunity that was automatically generated on the system which needed to be passed to a partner. You simply had to tell the customer what was happening and pass the details to the partner.
- Clone an existing email template to the customer and update wording
- Clone an existing email template to the partner and update wording.
- Create two new email alerts
- Create the workflow
- Test
- Deploy.
All in it took about 90 minutes and it will save about 2 minutes every time that it is triggered. So you get the pay back pretty quickly. The trouble is as you work through a sales process and increase the granularity you find that there are hundreds and thousands of these small requirements. At some point the opportunity cost becomes too high and the Salesforce admin revolts.
When you use dynamic workflows in contrast you are able to see patterns of emerging demand for workflows through patterns of user behaviour and implement them automatically.
Creating a Dynamic Workflow
So to use the above example again.
Think of the sales person working through her email in box. She replies to an email and forwards it to a partner. A few minutes later she repeats the pattern of behaviour. The dynamic automation software sees this and looks at the emails, the recipients, the opportunities that they relate to and the text of the original email and the salesperson’s message. Critically it then goes back through much of the salesperson’s email history to validate the patterns it finds
It then suggests to the salesperson that a new workflow rule should be created. The response of the salesperson then helps train the system.
Depending on the scale of the organisation you apply this on a general basis or an individual basis. People have different styles of working so in much the same way that you may have different page layouts for different profiles you could well have different workflows for different users. These would be constrained by a general automation architecture that would place limits on both what is acceptable behaviour by the user and on their changes to the way the CRM is automated.
The key benefit is that, depending on how you set your system up, you are able to capture and automate a very significant part of user’s daily administrative work. It’s likely to achieve 80% over time with the remainder being edge and emergent cases that require more thought.
You are able to do this across the whole organisation, at once, continually, and as the organisation changes the workflows will adapt. So, if you get the architecture right, that’s not a small if, you will have a much more robust business process automation system that reacts quickly to the changing market with far fewer requirements for expensive integration consultants
Scaling at the Organisational Level
An alternate approach is to use dynamic workflow creation to generalise best practice across the organisation. So for example when you have 5 or 10 sales people in a large team repeating patterns of behaviour – even something as trivial as editing data or selecting products – you can identify that behaviour and then modify fields, layouts and workflows for the organisation as a whole to enforce the best practice again automatically.
A final example; consider a team, of sales people sending out customised proposals by email. By looking at the information that is sent to the prospect and how it is presented and then data on the prospects behaviour you can extract best practices that are then fed back automatically into the template for a process of continuous improvement.
Now there is no way that I am suggesting that any of this is easy. Ignoring for the moment the engineering problems in developing systems flexible enough to do this you also have a problem with the business process automation software which suddenly has to have another meta layer of complexity added to it. No fun at all for system admins.
The promise though is that using machine learning and other algorithmic tools you can start to reclaim much of the 60% of a salesperson’s time that is not spent selling. You are essentially shifting complexity from the human arena to the machine. By doing so you have many more tools to manage it effectively.
Some Thoughts on Creation of Dynamic Workflows
You need to have a confidence level. This can actually be set fairly high because a lot of the time the pain has to be fairly high for users to push for a positive change (as opposed to complaining about bugs). I find that when a user has to do a trivial task dozens of times a month they start agitating for a workflow.
Activation: Could this used unwisely trash an organisation? Sure. One trash case would be having emails hacked and used to send malicious messages. This could then trigger a dynamic workflow and thus perpetuate the hacking. So you need checks and controls in place. Mostly though normal management controls should be sufficient to control negative dynamic workflows. After all if staff use of the email and CRM system is non compliant with your procedures you probably have pretty big problems to worry about.
Senescence. People change. Organisations change. Certainly with Salesforce instances bloat over time as obsolete code is deactivated but not removed. It requires constant admin focus to keep it lean. If you are dynamically creating workflows based on user demand then you build in graceful senescence. If a workflow is not used over time it is deactivated and eventually archived.
Data size. Now this is interesting. One of the big trends of the last 5 years has been the rise of big data as Google, Facebook et al struggle to extract value from the torrents of data that they gather. Most businesses are relatively small, and even for larger businesses relatively small numbers of people use the same processes. Large multinationals may have hundreds or thousands of Salesforce seats. Rarely tens of thousands and never hundreds.
Further as you move from the traditional computer domain to the human one you see an increasing use of unstructured data. It can be analysed but more complex problems on smaller data sets are harder to solve with confidence. This is why the combination of email with the CRM system is so powerful.
You can look at the unstructured email data and match it to the structured data in the CRM. Depending on the organisation training will take a shorter on longer period of time. but it can be done.
Conclusion
I’ll say again. As far as I know know one is doing this at the moment. We’ve started experimenting at the edges seeing what’s possible. There’s definitely an opportunity there. Some of the bigger speculations? You’ll have to start reworking a lot of Salesforce architecture from the ground up to get this to work for example. Enabling user specific workflows as a subset of organisational workflows is a big change in itself and probably not on the SFDC roadmap.
But we are starting to get the tools and the experience in using machine learning that now makes this a plausible approach and one that could if successfully implemented provide massive value to corporations and the job satisfaction of individuals
