Workflow Wizards: Breaking Big Tasks into Small Chunks Helps Brandon Martinez Deliver Huge Value

Discover how Brandon Martinez, Senior IT Manager at eTop, leverages Rewst to automate efficiently, freeing time for larger company initiative

The value of an RPA platform increases exponentially when MSPs dedicate an Automation Engineer to build workflows. While these Automation Engineers have strong technical understanding, their mindset is equally as important as their skillset. They’re creative problem-solvers who ask questions, challenge assumptions, and constantly seek better ways to do things.

Today, we’re launching a new series called Workflow Wizards, where we showcase the best and brightest Automation Engineers in the Rewst community. Let’s help you learn who your go-to gurus are for a successful automation implementation.

First up is Brandon Martinez, Senior IT Manager at eTop Technology. eTop was one of the first Rewst customers and more recently became a Professional Services partner, offering services to help other Rewst customers build custom workflows. In this profile, Brandon shares the wisdom of breaking big tasks into smaller chunks, why his process for creating workflows starts in Microsoft Word, and what IT troubleshooting and making electronic music have in common.

What is your professional background? ​

I’ve worked in IT for 10 years, pretty much since it was legal for me to work. I started at a retail repair shop, fixing laptops and phones. The biggest transferrable skill to working in business was customer support.

From there, we started an MSP with the owner of the retail repair shop. I worked there for a few years and then moved to eTop. I started as a tier 2 helpdesk technician, mainly front line taking in tickets and fixing people’s problems. Now, I’m a senior IT manager, focusing on making things run smoothly on the back end.

Did you have any automation experience before Rewst?​ 

I’ve always been in technical roles but didn’t do much programming until eTop. I wrote some PowerShell scripts, but nothing at the level of what I’m doing with Rewst. Before Rewst, my view of automation was automating one system. If I had to provision a virtual machine ten times, I would write a script and let it run.

The power of Rewst is that it ties all of our platforms together, which has shifted my mindset from streamlining an operation on a small scale, like provisioning a VM, to something much broader. How can we provision the VM, reach ConnectWise PSA to say it’s been provisioned, notify ImmyBot to install the provisioning package, and so on?

How were you introduced to Rewst? What was your initial reaction?​ 

eTop’s owner sent me a link to the Rewst website, and I thought it looked cool. To be honest, it took a bit to grasp the platform entirely. I think that’s because I was trying to automate processes that were too complicated for someone just learning the platform.

When people first get into Rewst, they have grand ideas, but they’re so large they can’t reasonably implement them. They’ll say, “Let’s automate our entire user onboard process!” But if you don’t have that defined already, you end up spinning in circles trying to automate a process that doesn’t fully exist.

What was most helpful when learning Rewst? Did you have any ‘Cluck yeah!’ moments?​ 

One aha moment was learning to break a big task into little tasks. Instead of trying to automate everything in one workflow, break it up into smaller, reusable chunks called sub-workflows. An action to get users from Microsoft Graph doesn’t change between processes, even if the end goal differs. By creating it as a sub-workflow, it’s adaptable from the start. I don’t have to rip the logic out of one workflow and refactor it for another.

One aha moment was learning to break a big task into little tasks. Instead of trying to automate everything in one workflow, break it up into smaller, reusable chunks called sub-workflows.

Another big help was the Rewst community. I can’t think of many other products where if I have a problem, I can go into a community Discord or Slack channel and get responses—not just from the vendor, but from other users in the community. I’ll post an issue in the Kewp, and within 15-20 minutes, someone replies, “Have you tried this?” And it often solves the problem.

What are some workflows you’ve built? Which are you most proud of?​  

In total, eTop has 40 workflows running in production. My favorite is a Teams helper bot. Figuring out how to get the bot framework to start having one-on-one conversations with a Rewst workflow was a mind-blowing moment. One function that we use frequently is the note summary. We’ll send the notes from a ticket to our private OpenAI instance and have it return a three-sentence summary. When asked questions about a ticket they’ve never seen, a service manager can get a high-level overview of what’s happening.

The smallest workflow we get the most value from is syncing contacts between 365 and ConnectWise Manage. Whenever someone gets onboarded or offboarded, part of that process is going into the Manage company and adding or removing their contact. It saves 30-40 seconds, but you do that on every onboard/offboard, which adds up. The workflow pulls the tenant 365 users, and every licensed and enabled account automatically syncs to ConnectWise. If that account becomes unlicensed or disabled, it gets marked as inactive. Automation completely handles this process.

What’s your approach to building a new workflow?​  

Step 0 is defining the process. I don’t touch Rewst until halfway through the new workflow process. The first thing you want to do is figure out the end goal and how you get there. Most people only have the first part figured out, and that’s where they encounter problems.

I’ll open a Word document and start typing a process. Once I have that defined, there’s the blueprint for the workflow. I’m not trying to figure out the technical part and the process part at the same time. I can focus purely on the technical aspect and debugging.

Building workflows is a collaborative process. I’ll build some workflows independently, but I try to involve our team in most of them. For our internal processes, if a technician makes a document, we expect it to be peer-reviewed. I treat Rewst workflows the same way. I don’t want to define a process and later find inconsistencies or that it’s not as efficient as possible. I’ll put the doc in our Teams channel and ask for feedback. This lets me refine the process before I start building in Rewst.

How has using Rewst impacted your role at eTop?​ 

I’m spending less time doing manual stuff, which has given me more time to investigate new things. Many people think automation is going to replace them. I believe automation and AI can augment people’s abilities. You’re giving them more time for what they enjoy and to learn new things.

At some point, when we don’t have as many tier 1 tickets coming in, we can shift our tier 1 technicians into a hybrid automation engineer role and teach them how to build automations in Rewst. We’ll have more people building workflows, our output will accelerate, and we’ll get ideas directly from people on the front lines.

What advice would you give to new Rewst users?

Don’t be afraid to engage the community. We don’t bite. We’re very helpful. If you have questions, ask them in Discord or Slack. Even if people ask a question several times, or it’s a simple question, we never respond hostilely. No one says, “Read the manual!” It’s more like, “Have you tried this? Here’s how it works.”

What did you want to be when you  grew up?​

I wanted to be a doctor. When I was 6 or 7, we had an old John Hopkins medical book, and I would read it constantly. I always wanted to help people. It’s gone from diagnosing people to diagnosing computers, but I’ve always had that investigative process. Here’s a problem; how do we get to a solution?

What do you like to do for fun?

I do a lot of maker stuff. I have a 3D printer that I used to print some Rewst trophies once.

I also enjoy music—making, performing, and listening to it. I do computer-based production and make instrumental electronic tracks. It’s a lot of trial and error. Sometimes, I’ll play for 6 hours and come up with nothing. Other times, in 15 minutes, I’ll have something flowing that sounds good. It’s a lot like troubleshooting in IT. There isn’t always a clear path forward. Sometimes it works perfectly the first time; sometimes, it takes a bit.