Sign in Subscribe
Trello Automation

Project 2: Automating Case Management with Trello API

Matthew Monroe

• 3 min read

Disclaimer: All time spent on this project has been outside of my work hours. My employer is not paying me to work on this, nor are they aware of it (to the best of my knowledge).

One Step Forward, Two Steps Back

Today marked my first day back in the customer service department after spending almost a year and a half in the software engineering business unit. To say I’m disappointed is an understatement, but can I really blame them for their decision? I don’t think so.

The decision to relocate came after news of impending company-wide layoffs. My team was designated as "critical" during the first wave of layoffs last year, but this time, the same notion didn’t apply. My entire team was dissolved into various departments, and those who weren’t absorbed were offered severance packages as a final "thank you for your service."

My first day back in CS was largely unremarkable, save for one quick realization: I would need to adopt their existing processes, which caused a mix of disappointment and panic. Call me meticulous, but I like my processes for a reason—they’re efficient. One of my primary focuses in the software engineering department was on automation and scripting to streamline mundane tasks. Why spend a cumulative hour or two on repetitive tasks when I can just automate them?

That’s how I came up with my second project.

Trello: A Remarkable Asset

On my old team, we used Trello daily. It was a fantastic resource that helped us stay visually organized and on task. Despite using the free version, we were able to work quickly and accurately. Here’s how our flow was set up:

  1. A customer service representative encountered an unsolvable issue.
  2. The rep had the issue reviewed by a tech lead to ensure it qualified for escalation.
  3. Upon approval, the rep filled out a Microsoft Form.
  4. Power Automate created a Trello card with all the form’s information, giving my team everything we needed to investigate the issue.
  5. Once resolved—or if an RMA was required—we commented on the case, assigned it to the appropriate team, and closed it out.
  6. Resolved cards were moved to a "Completed" stack and eventually archived in the "Case Graveyard" board for record-keeping.

While not perfect, this process was robust, effective, and largely automated. The best part? It was our creation. My supervisor and her team designed this flow from the ground up, shortly before I joined the department. It was our pride and personal project.

Now, my new team uses an in-house proprietary tool that feels like a reskinned Excel spreadsheet. It’s clunky and inefficient. I voiced my concerns about its shortcomings, but the process is the process. Adhering to it is mandatory.

Or is it?

Reimagining the Process

Maybe I’m reinventing the wheel, but I see a clear opportunity for improvement. My new team is expected to become the spiritual successor to my old one, even though we’re not a true engineering team. This might even include a designation change to something like "Tier 3 Engineering", but I digress.

Here’s my vision for a better process:

  1. Create a new queue for escalations to my team.
  2. When customer service encounters an unsolvable case, they place it in this queue.
  3. An automated API runs a GET request at regular intervals (every 5 minutes, for example) to retrieve case numbers in the queue. It creates Trello cards for each one, ignoring duplicates.
    • This might require a database to track "escalated cases," which can be implemented with SQL (Primarily because my only experience with database management was with mySQL).
  4. A proxy server gathers all relevant case details via API and populates the Trello cards.
  5. Team members claim ownership of cards by moving them to their personal stack.
  6. Upon resolution or escalation, the team member updates the card with comments, case status, and the new owner using custom fields. A custom button triggers an API POST request that sends all updates back to the server, eliminating the need for manual updates.

The key difference here is the lack of a form to fill out and the introduction of automation. Every minute saved is a minute that can be spent helping another customer or solving a complex problem. Time is money, after all.

While I expect this to be a challenging project, I’m confident I can make it work. I’ll likely face issues like CORS errors again, but since I’m already familiar with overcoming them, I’m not too worried.

The End Goal

What’s my end goal? That’s a tough question. Ultimately, I’m still looking for work elsewhere. At the end of the day, I need to prioritize what’s best for me and my family. That means building my portfolio and staying ready for new opportunities.

While I haven’t had any interviews yet, I’m determined to keep improving. Who knows? If this project is successful, it might even lead to another role in the software engineering department. Whatever happens, this is an investment in my skills and future.

Final Thoughts

This project isn’t just about making my workflow easier—it’s about proving to myself and others that I’m capable of solving real-world problems through creative and technical means. Whether or not it changes my current job, it’s a step forward in my journey toward becoming a full-fledged software developer.