We are so excited to announce that the Workflow behaviour has just been released for both of our bots on the Platform. Using either C#Bot or SpringBot, you can now easily incorporate workflows into your app using this new behaviour.
If you haven't come across this term before, behaviours are features or components which add functionality into your app without the need to write code. Essentially, Behaviours are cool things the bots can do. They are identified as part of the software development process, where we note any repeated patterns in the functionality or the interface of a piece of software. We have taken the time to make this pattern reusable and available for any application which may need it. The benefits of a behaviour are that they can allow an application to be built in a very short space of time, and it often requires little-to-no developer input to implement it in it's basic form.
In its most basic form, the Workflow behaviour does what it says on the box. It enables an administrator to create a series of states which can be applied against an entity, along with a series of transitions which can be used to move between them. Essentially, it it used to track the status of something. A workflow can be applied to multiple entities if required, or can be made specific to one particular one. Once a workflow has been assigned to an entity, it will appear on the entity's detail page as a dropdown which shows the available transitions from the current state.
If you are able to write custom code, it is also possible to add in event triggers which run when you transition to a different state, for example sending an email when a status has been updated.
Workflows can be helpful in a number of different scenarios, from onboarding someone into your system, to tracking a document's progress, there is always a need to track the status of something.
The process is very simple. You simply need to drag the behaviour onto the associated entity in the Entity Diagram, build your app, then configure the workflow in the administration section of your app, which, depending on the number of states you have, can be as quick as a few minutes work. All in all, you can be done with the whole process in less than 20 minutes.
We made the decision to split the configuration to give the users the maximum amount of control. If we left all of the configuration on the Platform, it would mean needing to release the product anytime a change was made, even for something as minor as a spelling change. It may even require involving the dev team, which can bring in a whole host of other issues. This would create problems for users who have extensive deploy processes and requirements, or irregular access to their developers. Instead you can make the changes from with the application and see them go live as soon as you hit the save button.
What we have released is just our MVP of the workflow behaviour. We have intentions to include a lot more functionality as our behaviour matures, including:
- Viewing your workflow as a visual diagram;
- An option to automatically allowing all states to transition into the selected state;
- Reversible transitions;
- Adding event triggers to transitions; and
- A few other things we will keep as a surprise.
We always welcome feedback and suggestions from our community. If you feel like there is a way we could improve our behaviours or platform, please feel free to shoot us through some feedback (using the feedback panel in the Platform). We love hearing about what you would like to see!
If you are already a user on the Platform, then you may have noticed a new qualification has popped up focusing on the Workflow behaviour. It goes more in depth into what is possible, who to implement it, and different ways you can use custom code to maximise your experience.