This is a guest blog post from Zach Chaitman, managing director at Rappid. Rappid is a team of technologists and business process experts helping turn ideas into software with our proven delivery methodology, framework, and Retool.

In today’s rapidly evolving technological landscape, businesses are constantly seeking ways to optimize their business operations. At the same time, there is no shortage of purpose-built SaaS products on the market aimed at automating processes and integrating systems.

Purpose-built SaaS tools may seem to provide the perfect confluence of wants and needs, but as businesses grow and evolve, their needs tend to change—which may mean a once-ideal SaaS solution is no longer a fit. Because SaaS platforms are not inherently interoperable, switching platforms can introduce complications, especially when it comes to maintaining business critical operations. In this article, I’ll walk you through how to reduce risk by limiting reliance on platform-specific workflow features.

At Rappid, we know how quickly market conditions can change and an organization’s ability to adapt their operational tooling quickly is the key to taking advantage of opportunities when they arise. Retool makes this possible by way of their Workflows product. Workflows provides users with the building blocks needed to replace platform specific workflows so that you’re empowered to select the right platform for the right reasons and not be held hostage by a single platform feature. Not only can Workflows be used to create cron jobs, custom alerts, and ETL tasks, but since it’s part of the Retool ecosystem you also have access to the full suite of Retool UI components and recently released Retool AI features, should you need to build a frontend to your process.

The importance of limiting SaaS platform reliance

When we’re consulting with customers on their project requirements, we highlight three key areas to ensure a successful outcome now, and in the future, as the customer’s business continues to grow and change. 

1. Flexibility: When workflow logic is decoupled from SaaS platform-specific features, it becomes easier to adapt and switch to alternative tools or SaaS platforms without disrupting business operations.  

2. Continuity and stability: By reducing your reliance on platform-specific features, your business logic is owned by you. As the business process matures your systems can grow in parallel.

3. Scalability: Decentralized workflow logic can allow for easier scalability, as it eliminates dependencies on specific platforms. This means that as your business grows or your needs change, you can more seamlessly integrate new tools or platforms into your existing workflows and dev tooling.

A real-life use case

Recently, we were asked to help a customer prepare for a migration of their Zendesk platform by offloading their ticket workflow logic. Zendesk provides a good-enough solution for basic triggers, workflows, and routing, but it’s not known for its flexibility, and it can’t translate directly to other platforms.

Here’s a screenshot of Zendesk’s workflow trigger builder where you can see the UI-based approach to building logic.

Zendesk workflow logic builder
Zendesk workflow logic builder

While it can handle a variety of use cases when compared to the total control you get from JavaScript or Python it falls short. Additionally it’s not exportable which means it can only live inside an instance of Zendesk.

Our criteria for success on this project were to:

  1. Allow Zendesk to continue functioning as normal while other products were being evaluated.
  2. Make current triggers, workflows, and routing activities platform agnostic so that any platform with an API was a contender.
  3. Develop the logic in a way where it was safeguarded from platform-specific risks while creating process efficiencies.

Our solution

We chose Retool as our workflow platform of choice because, unlike other ‘integrators’ out there, Retool offers infinitely customizable frontends and the ability to integrate your existing dev tooling and processes into the solution. Retool Workflows specifically can be developed using JavaScript or Python, can include custom libraries where necessary, and can accommodate a variety of ways to configure role-based access controls (RBAC).   

Workflows in Retool are made up of blocks designed to compartmentalize your process. Resource Queries, Code, and AI Actions are ideal for bringing data into your workflow, modifying it, and triggering actions like DELETE or POST requests. 

Between these blocks you can use Filters, Branches, and Loops to control the flow of your data and ultimate outcome of your workflow based on the business process. You can make use of standard JavaScript as well as a variety of helper libraries to speed up development.

Keep reading to see how we used branching blocks specifically in our solution.

Retool Workflow block options
Retool Workflow block options

The first workflow we replaced for this customer was a critical one: customer support escalation. This process ensures the correct internal users are notified when a support ticket is received. Our customer also requested we add a custom step for enterprise customers. 

We decided to use the Retool native connectors to Zendesk, Salesforce, and Slack to create a customer support escalation workflow that met all of the customer’s needs and requirements. The ability to use Retool’s native connectors also allowed us to implement this workflow faster when comparing build speed to other platforms which may require individual custom endpoints or additional integration services to be set up.

Data and transformations

The workflow we built for customer support escalation is initiated via webhook from Zendesk anytime a support ticket is received from a customer. (An alternate configuration would be to schedule a recurring GET request to a given endpoint and pull back relevant records.) 

Next we pull back the account details for this customer which we’ll need in order to determine if they’re an enterprise customer. The data from the first two blocks pictured here are combined in our first code block, which is used to classify the request into one of three agent tiers for triaging.  

Steps 1–3 of the Retool workflow the author built, featuring various modules and code
Steps 1–3 of the Retool workflow we built

This query is set up to allow for ticket classification based on the following criteria, all of which can be easily refined and updated by the user.

  • Net promoter score (NPS)
  • Ticket type
  • Keywords 
  • Enterprise status

Branching logic and alerts

The workflow now has what it needs to branch according to our provided parameters. To determine the appropriate escalation path we use a branch block. This block type is a visual way to develop if-then logic which routes the process to subsequent steps. Using simple && (and) || (or) operators we can fine tune our workflow to route according to any specification we need. 

Now that we have our basic escalation paths we can send a  GET request to identify the assigned agent from Zendesk and then issue a POST request to update the ticket.  In the case of an enterprise customer we also want to alert the account team responsible for that relationship which is what we’ll walk through next.

Image of "Else If" modules of branching logic
Step 4 of our Workflow branching logic

Salesforce, Slack, and exception handling

A simple SOQL query against our Salesforce resource brings back the account owners email. Then, in the event there’s an account owner associated with that ticket, we utilize a GET request to match the Slack handle for that user which we’ll use in our final step. There’s another branch here set up to manage an exception in the event a Salesforce owner is not found. 

Modules showing the Salesforce exception handler
Our Salesforce to SQL exception handler

The final step includes one more exception handler (in the event a Slack user is not associated with the Salesforce user) and consists of two POST requests to Slack. The first is a DM to the specific owner of the account while the second creates a channel message which has more visibility. In our view, one of the great things about Retool Workflows, and Retool in general, is the ability to seamlessly combine JavaScript (shown in green between the {{ }}s) and plain text, as we did here to send dynamic alerts in Slack.   

Modules of the Salesforce to SQL exception handler
Our Salesforce to SQL exception handler

Results and next steps

What I’ve shared here was the first of several workflows we built for this customer. We’ve found that one of the best parts of Retool Workflows is the ability to reuse both logic and resources, and once we had our Slack and Salesforce resources set up we were able to quickly reconnect and utilize them for other use cases. That helped us fully replace all business-critical Zendesk workflows for our customer without a single interruption to their routine. 

By removing their reliance on a SaaS platform and leveraging Retool to create custom, dynamic, and flexible workflows, our customer is now able to select a new customer support platform without the added concern of business continuity. They’ve shared that the increased transparency into workflow operations has also led to a 15% improvement in ticket response times.

Conclusion

So there you have it—a cut and dry example of building better business workflows with Retool. Retool empowers businesses to streamline and automate complex business processes. By leveraging Retool Workflows’ robust functionality, including native connectors, an intuitive visual interface, and workflow logic blocks we were able to deliver a high-value solution to our customer faster and with enhanced business process longevity.