Automating Bug Reports with Tally and Make

When building my first proper Android app, Timety, I ran into a common issue: I wanted to collect user feedback, but since my app is privacy-focused, I wanted to avoid forcing users to create an account just to report a bug.

I found a great form-builder called Tally and created a feedback form. However, this introduced a new problem. Tally sends form submissions via email, but I manage my project board, bug reports, and feature requests on GitHub.

To bridge this gap, I built an automated workflow using Make to connect Tally, GitHub, and Discord. In this article, I'll walk you through how to set this up.

The Goal

I will explain my specific scenario, but you can easily tweak this logic for your own use case. In my setup, I route three types of Tally form submissions:

• 🐛 Bug Report: Creates an Issue on GitHub with a "bug" label and sends an alert to Discord.
• ✨ Feature Request: Creates an Issue on GitHub with an "enhancement" label and sends an alert to Discord.
• 💬 General Feedback: Creates a GitHub Discussion instead of an Issue.

The Workflow Overview

To get started, you will need a free Make account. You'll also need to connect your GitHub account (via OAuth) and set up a Discord connection (Make has a dedicated Discord module, or you can use standard Webhooks). Tally also has a native Make integration that is easy to enable in your form settings.

Here is what the full workflow looks like in Make:

The workflow triggers whenever there is a new Tally submission. (Note: Tally still sends an email backup, so if the Make automation ever fails, you won't lose the feedback).

The workflow uses a router to split into three branches based on the submission type:

1. Top & Middle Branches (GitHub Issues): These handle bug reports and feature requests. Because users can submit screenshots via Tally, I added a step to format those media URLs properly for GitHub Markdown. Once formatted, the GitHub integration creates the issue, and the success (or error) result is posted to Discord. Tip: Routing errors to Discord is a lifesaver for troubleshooting.
2. Bottom Branch (GitHub Discussions): This handles general feedback. Since I don't allow media uploads for general feedback, we can skip the formatting step and jump straight to creating the Discussion.

The GitHub Integration

To create the GitHub Issues, I opted to use a "GitHub" module with a POST request to the GitHub GraphQL API. Doing this, rather than using Make's default "Create an Issue" module, gave me much more control, allowing me to inject the data directly into my existing issue templates.

Here is the GraphQL mutation I used for creating an issue:

mutation CreateIssue($repoId: ID!, $title: String!, $body: String!) {
  createIssue(input: {repositoryId: $repoId, title: $title, body: $body, labelIds: ["LA_kwDOSA3zFM8AAAACfFlVUw"]}) {
    issue {
      url
    }
  }
}

For this to work, you need to set variables in Make for the $repoId, $title, and $body. The body variable can be standard Markdown, meaning you can just drag and drop the Tally form variables from Make into the exact layout you want.

Pro tip: Run the workflow once with dummy data from your Tally form first. This populates all the available variables in Make so you can easily map them.

Finding your GitHub IDs

To use the GraphQL API, you need the underlying Node IDs for your repository, labels, and discussion categories (like the LA_kw... label ID you see above).

You can easily find these by running a quick query in the GitHub GraphQL API Explorer. Log in, and run this query (replace owner and name with your details):

query GetRepoInfo {
  repository(owner: "Benji377", name: "Timety") {
    id
    labels(first: 10) {
      nodes {
        name
        id
      }
    }
    discussionCategories(first: 10) {
      nodes {
        name
        id
      }
    }
  }
}

This will output the exact $repoId you need, alongside the IDs for your labels and discussion categories.

Once you have your Discussion Category ID, you can use a very similar mutation for the bottom branch of the workflow to create a GitHub Discussion:

mutation CreateDiscussion($repoId: ID!, $catId: ID!, $title: String!, $body: String!) {
  createDiscussion(input: {repositoryId: $repoId, categoryId: $catId, title: $title, body: $body}) {
    discussion {
      url
    }
  }
}

Discord Notifications

For the Discord portion of the workflow, I simply pass the response URL from GitHub into a Discord message module. Discord supports a subset of Markdown syntax, so you can easily bold the titles, add links, and format it nicely.

Here is how my Discord module is configured:

If you prefer another platform, you can effortlessly swap the Discord module for Telegram, Slack, or any other messaging app Make supports.

Wrapping Up

Building this pipeline takes a little bit of initial setup, but once it is running, it is entirely hands-off. Tally form submissions map flawlessly to GitHub, and I get an instant ping on Discord, all without sacrificing the user's privacy. Make also has AI integrations, so if you wanted to build a more complex setup (like using AI to auto-tag or summarize bug reports), the foundation is already there.

If you want to see exactly how this is structured in the wild, check out the links below:

• GitHub Repository: Benji377/Timety (Check the .github/ISSUE_TEMPLATE folder to see how the formatting lands).
• The Live Form: Timety Feedback on Tally