3. Tonkean Foundations - Modules
Modules are self-contained units that monitor, coordinate, and execute business workflows created and defined by you within a solution. They can be as simple as handling the intake of requests in Slack or as complex as coordinating a sophisticated review and approval process that stretches across multiple departments.
When turned on, a Tonkean module is always monitoring your connected data source(s) and the various actions you configured it to perform. A module works similarly to a complex function in a programming language, where it takes in information and performs certain actions with that information. But unlike a conventional "if" statement that only performs an action if something happens, modules perform an action when something happens. Basic module logic can be read as "when this event takes place, do these actions."
This basic module architecture is especially powerful because it allows Tonkean to track the status of all the applications and systems connected to it, recognize when a relevant change has occurred, and take the appropriate action.
What Can Modules Do?
Modules are incredibly powerful and flexible, and can do almost anything you can imagine if they can access the right data. The best way to think about an individual module is as a self-contained business workflow. If you were to open up your favorite workflow diagramming tool and create an entire workflow, that's what is encompassed by a module: it's where all the workflow logic is mapped out.
Triggers
Triggers are the conditions that you want the module to look for. These are the "when" statements. Some examples include:
When a new Slack request comes into the Legal Ops workflow with the text "conflict waiver"
When a sales team member hasn't updated their Salesforce Pipeline in 3 days
When a ZenDesk Support ticket comes in from a tier-1 client
Actions
While triggers will tell the module when and what to look for as it's monitoring your various data sources, actions tell the module what to do after the criteria's been met. There are three different tiers of actions that power Tonkean modules:
People Coordination
There are many different ways that Tonkean can interact with people. In each workflow, whether before or after an event happens, there's a good chance a person either needs to be directly involved in the process or a human is needed to make a decision because a module isn't informed enough to make the right decision. If it's the latter, Tonkean modules will reach out to the correct person, at the right time and wherever they're already working (email, Slack/Teams, etc.), giving them a very simple way to tell the module how to proceed.
Workflow
These are the conventional data-related actions that you need in almost all business processes, whether that is updating a specific field, changing the status based on what phase the workflow is in, waiting a certain amount of time before taking another action, or, for more advanced cases, getting another module to take a set of actions.
Data Source
With over 150 native integrations ready to plug and play, you can incorporate data from your systems and applications in a multitude of ways. Based on the information you may have asked a colleague through one of the People Coordination actions, you likely want that information sent and saved somewhere. Or when a client sends you an attachment in an email, you probably want that attachment stored somewhere and not just sitting in the inbox.
That's where data source actions come into play. These actions provide access to actions specific to a connection application. Below are some example use cases where data source actions are helpful:
When the Sales module asks the salesperson to update the stage of an opportunity that hasn't been updated in 5 days, the module will take their answer and automatically update that stage in Salesforce using a Salesforce action.
When the "NDA" email request hits the Legal Request inbox, the module automatically creates a new copy of the NDA Google Doc template, creates a new Google Drive folder, fills the correct fields within the template, and sends back the finished NDA to the original requester using Gmail.
When the Tier 1 Client submits a support ticket in Zendesk, we can make sure that the #Tier1 Slack Channel is notified, CC'ing the Client's Account Manager (that we looked up in Salesforce). Anyone in the #Tier1 channel can select the button that's either "Close", "Delegate", or "Escalate", and the module takes the correct course of action based on what the stakeholder decides.
