Client CasesTo client cases overview
How Mcon Services use QuivvyTools to debug Podio systems
Meet Kamil Makowski
Kamil is the founder and CEO of Mcon Services. Mcon aims to create more time for small and medium-sized business owners, by initiating digital transformation, process optimization, and process automation. One of the systems they use to make this happen is Podio. Depending on the client and process, they use it either as an interface, interactive database, or a system of record for more extensive integrations or ERP-like solutions. Kamil is also responsible for developing Mcon's internal Podio system, which they use to manage all of their production and client processes.
QuivvyTools really shortens the debugging jobs
How does Mcon use QuivvyTools?
My development team uses QuivvyTools extensively. The most often used features are:
- Searching for anything flow/custom var related
- Flow/field dependencies
- Manual flow triggers
- Brick numbers
- Error reporting
As we see it, there are 3 main areas in which QuivvyTools is invaluable:
When we get corrections from clients or encounter unsuccessful tests, the first thing we do is open QuivvyTools and narrow down the problem - if not to a specific field or GlobiFlow brick, then at least to the correct flow.
Almost all business processes are interlinked in one way or another. So when we implement new processes, we often have the option to optimize the existing processes further. This is when we jump into QuivvyTools and get started with investigating dependencies and figuring out optimization points. These points can be either Podio architecture related or GlobiFlow logic related - both can be seen in QuivvyTools.
As you all know, it is not straight forward to create a good separation between a production and test environment (yet). Most often, people work directly in production. This means that anytime we delete a GlobiFlow or anything in the Podio architecture, we first verify it through QuivvyTools.
For my situation, it would be very helpful if QuivvyTools developed these functionalities:
1. The ability to track hook event triggers
2. When you click on a field and get the GlobiFlow list, it would be great if we'd be able to split the list by dependency type, e.g. triggers, update from current item, update from referenced item, used in cust var, used in filters,...
The last points might be harder to accomplish since the field might be used in multiple ways in one flow, but just showing which flows a field triggers would be amazing.