You know what a workflow is: everything that happens after a form is submitted. Jane needs to approve the purchase of a laptop when a new hire is onboarded. Roger has to deploy a new server so the team in Dallas can start development.
Many workflow processes have common features, like sending an email, requesting approval, or creating a ticket. Getting transparency into the process can be difficult. Did that email get sent? Jane is on vacation; who is handling her approvals? Kinetic Data's workflow engine brings transparency to the process.
Maybe you don't know the details of a process. Kinetic workflows act as self-documenting, automatic, repeatable representations of your processes. Once a process has been documented, it's easy to find improvement opportunities. This is how Kinetic's workflow engine lets you own your process.
The Kinetic Workflow engine has four main components that make up the bulk of the process development: trees, routines, handlers, and connectors. Builders create trees at the Global Workflow level, then populate those trees with routines, handlers, and connectors.
Trees are the entry point to a workflow. When a form is submitted, a webhook fires off a tree that begins the process. Every tree has a "start" node where the tree starts execution. The process continues through a path of connectors, handlers, and routines.
Routines encapsulate parts of a process that are used by multiple workflows. For example, let's say all of your workflows send an email. Rather than duplicate the logic used to look up the email recipient and send the email for each individual workflow, you can put the logic in a routine and reuse it.
Handlers are the workers of the workflow process. Handlers are snippets of Ruby code that do everything from create/read/update/destroy (CRUD) operations, data formatting and manipulation, process implementation, and so much more. Using our earlier example, the code to look up an email recipient could be in a "Recipient Lookup" handler, and the execution for sending the email could be done by the SMTP handler.
Workflows do not always follow the same path. Connectors allow you to create a path of execution through your workflow that can change. For example, let's say you are onboarding a new remote hire who requires a cell phone instead of a desk phone. When HR fills out the form to start the new hire process, they choose the "remote worker" option. When the workflow process reaches the point where it needs to know which type of phone to invoice, the workflow will check to see if the new hire is a remote worker or not.
Updated about 1 month ago