Tonkean Foundations - Maker Best Practices

It's easy to focus on our needs, preferences, and goals when creating workflows to automate our internal processes. This is understandable, but it's a common trap many internal, shared services teams like procurement and legal fall into: focusing too much on the ideal process for procurement or legal and not necessarily for the requester/stakeholder. Often, this approach results in processes that are too cumbersome for requesters or other users, which leads to low process adoption and a host of other problems that you're specifically trying to avoid by using Tonkean.

Instead, as you map out your process and how it will work in Tonkean, focus on the journey of each persona who's engaged in your process. This likely includes an internal requester, a reviewer, an internal service provider, and other stakeholders. Ask yourself the following questions:

With clear answers to these questions, you can tailor the relevant parts of the experience to each persona. This customization can include various things, from creating separate modules to provide a unique view of each item to each persona, or specialized review interfaces for different stakeholders. Regardless of the specific details, it's important to remember that a great experience leads to process adoption—and considering your audience's specific needs is the most powerful tool for creating a great experience.

When creating a new workflow, create the smallest, simplest version of that workflow that accomplishes your goals and then test it. If it tests well, begin to iterate from there, adding the more complex or nice-to-have features you want to include, and testing after every major version.

This strategy is counter to the tendency some teams may have to create their entire process, including all of its complexities, before they begin to test or check for performance. By the time all of that logic is added, testing and troubleshooting become far more challenging. Instead, follow an agile approach by starting with the MVP of your process and building on it from there.

While individual modules are flexible enough to handle complex workflows with various branches of logic, it's helpful, or even necessary, for some processes to use separate, coordinated modules.

Processes that include multiple entry points to the same core workflow commonly separate that process across multiple modules. For example, if your legal team accepts requests for legal documents from email, Slack, and online forms, and processes all these requests using the same core workflow, partitioning off that core workflow in a separate module may be the best way to build the solution.

Similarly, for processes that include a hand-off to a separate business unit for something like review or translation, separating out that part of the workflow using a stand-alone module can make the overall solution much neater and easier to maintain.

Separating a complex workflow into multiple modules has several benefits:

In general, if you can separate parts of a complex process, it's worth considering using separate modules to benefit from the decreased maintenance and added simplicity. Additionally, as items move between these related modules, automatically created matched items allow you to maintain visibility and track field changes across the entire process, where relevant.

Whenever possible, separate the business logic in your module from the data being processed by that module. For example, if your workflow involves assigning task owners based on request type, avoid putting those owners' email addresses directly into the module action blocks. Instead, create a simple external spreadsheet that includes owners, email addresses, and request type, and connect that sheet to Tonkean. You can then reference this table to determine who to assign a task to. This setup allows you to easily change assignment rules by updating the spreadsheet, not the module logic—and even users who aren't Tonkean makers can make those changes.