Switch on
Co-Founder, COO
I had recently joined a new team as a Staff Support Engineer, and we had a problem. Suddenly, seemingly without warning, a key automation in our help desk was no longer working. The previous Support Professional in charge of our help desk had moved on before I arrived, which left me aimlessly clicking through admin page after admin page trying to find the problem and fix it.
Thankfully, because this wasn't my first rodeo, it "only" took 6 hours or so for me to get a handle on how things were organized and which workflows were likely involved. I discovered the underlying issue was that we had been running a script on the old employee's personal laptop to make this work, and they had (rightfully) turned that off after leaving. A couple hours later and I had turned off the old workflows, created new ones that seemed to accomplish the same goals, and stood up the kludgy Ruby script that the workflow called out to on new infrastructure the company owned.
It wasn't perfect, but the important workflows were fixed. Some wonky errors would continue haunting that help desk for a few weeks while I sorted everything out. I never got around to learning what every workflow was doing.
Does this specific stress dream of a day sound familiar to you? If so, this release is for you.
Just one more workflow, I promise
Support Professionals are automation and productivity experts. When your performance is measured in seconds, it comes with the territory. Most colleagues of mine have tried every text expander, workflow automation tool, and task management application that exists looking to move just a little bit faster.
AI & LLMs are the newest technology we're reaching for, but automation has been a key part of every successful support team of the past 15 years or more, enabling computers to handle the repetitive, mundane, and error-prone tasks so that humans can handle the novel, challenging, and interesting work of support. We just wouldn't be able to support customers effectively without it.
With that having been said, our automation tooling has been stuck in a click-based, prescriptive mess for the last decade or so. Every team I've ever worked on has had hundreds of automations running independently with no real way to audit or understand them beyond a semi-documented, unenforceable, internal naming scheme passed down like oral history.
When we started thinking about how to empower Support Professionals in Yetto, we knew we wanted to build something that gave you both composability and maintainability. What we landed on actually changed Yetto entirely from the inside out.
I think I've seen this film before
One of Yetto's core ideas is that you should be able to talk to your customers and your colleagues without having to leave the help desk to chase people down. For example, you open an issue in GitHub by @-mentioning GitHub in an internal comment. When your team responds in that GitHub issue, their responses come back into Yetto as internal comments.
While making this idea a reality, we started to notice that no matter which plug we were working on, the data we needed to pass back and forth from Yetto to the plug remained the same. After teasing at the idea for a while, we developed a new automation framework and built all of our plugs on top of it. We call this automation framework "switches."
Switches are flexible, composable, event-based, JSON definitions of what you want Yetto to listen for and then do for you. For example: an email comes in, and a switch tells it where to go. Someone mentions @linear in a comment, a switch sends that message to the Linear plug and establishes a two-way connection for an internal conversation. At the end of the day, almost everything you see happening in Yetto is powered by switches.
Like I mentioned, we didn't originally build switches as an automation feature, they're just a core piece of how Yetto works. And today we're exposing that power to you.
The data you need, right when you need it
Switches are JSON based, so you don't need to write code or work with an API. They support Liquid templating, which we use to give you access to data in your organization - inboxes, messages, labels, and more.
All of that combined means you can create a switch that, say, automatically sets a custom status label and alert the Customer Success team for a specific enterprise account:
{
"version": "2023-03-06",
"events": {
"conversation.created": {
"conditions": {
// Check whether the email is from Important Co
"if": "{% data.yetto.conversation.originating_message.author.name contains '@important.co' %}"
},
"actions": [
// Make sure the status label is set to urgent, not just new.
// Bonus points: Give the company its own label to make filtering their conversations out easier.
{
"name": "Set all new Important Co Emails to urgent",
"uses": "apply_labels",
"add": [
"status.new.urgent.important-co"
],
"remove": [
"status.new"
]
},
// Send an alert to a Slack channel using their "incoming webhook" feature
{
"name": "Alert the Customer Success team in Slack",
"uses": "http_request",
"to": {
// The Slack "incoming webhook" URL
"url": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"
},
"with": {
// The method of this HTTP request
"method": "POST",
// The JSON body we'll send, in this case using Slack's Block Kit
"body": {
"text": "New Conversation opened by Important Co",
"blocks": [
{
"type": "button",
"text": {
"type": "plain_text",
"text": "Go to Conversation"
},
"url": "{{ data.yetto.conversation.html_url }}"
}
]
}
}
}
]
},
}
}
More to come
Today we're releasing the ability to create switches, and two actions: an acction to apply and remove labels, and an action to make HTTP requests. In the future, we'll be releasing additional actions and empowering you to do more with switches as we expand the power of our own system.
Want to try it out? Apply for access to the beta now!