Workflows in SLINGR
Business processes are usually represented by workflows. They are one of the most important concepts in business apps, as they describe what are the steps to perform a task, which could be extremely simple or it could be composed by several steps and the interaction of multiple people and other systems.
In SLINGR we don't have an explicit concept of workflow. The reason for this is that workflows, when translated to an executable implementation, are composed by several reusable elements that wouldn't be efficient to repeat in every workflow or variations of it.
Instead, SLINGR provides the tools to support any kind of workflow through the following elements:
- Entities: represent the structure of the data, the information that needs to be persisted during the execution of the workflow.
- Actions: these are the actionable elements that can be used by users to change the status and provide input into the workflow. Additionally, external system can also call this actions through the automatically generated API.
- Listeners: listeners allow to trigger the execution of different actions based on events in the app. For example, it could be the processing of an external event, like a webhook, or perform some operations when the status of a record changes.
- Permissions: permissions are an important piece to implement workflows, as they will indicate which things can be done by who. For example, once an order is completed, only the manager can approve it.
- Views: finally, views are the interface users will interact with in order to review and change the status of the workflows.
Using these elements together it is possible to define any type of workflow in your app. And believe me, it is much more flexible and effective that most of the tools you will find out there where you need to draw a diagram.
Here you can find a tutorial to create a simple To Do app where you can see all the above concepts:
Here is a simple diagram to show what's the workflow:
In this sample app you can see all the elements combined to support this workflow:
- Tasks entity: here is where we store all the information of the tasks and their status.
- Actions over tasks: these are the actions that allow users to update tasks and move them from one state to another.
- Listeners to notify events: there is a listener to notify in a Slack channel every time a task is created.
- Permissions to restrict access: we have a specific group of people that can only see tasks that are assigned to them.
- Cards view to interact with tasks: in order to clearly represent the workflow, a cards view is used that allow users to see tasks and move them as their status changes.
Conclusion
You don't need to draw a BPM diagram in order to support workflows. It is actually counter productive in many cases, as good development techniques require a different organization of the app.
This was a very simple sample of the implementation of a workflow in SLINGR using the building blocks available in the platform, but they are powerful and flexible enough to automate any workflow that you run into.
SLINGR is a low-code rapid application development platform that accelerates development, with robust architecture for integrations and executing custom workflows and automation.
