How does it tell a real bug apart from a how-to question or feature request?

It first looks for tickets tagged as bugs, then reads the customer's description and the comment thread to confirm there is a real defect. Tickets that read like billing questions, how-to questions, or feature requests are skipped.

Will it create duplicate to-dos if the workflow runs again?

Each run only looks at tickets created since the last run, and the internal note posted back on the Zendesk ticket lets it recognize tickets that have already been handed off so the same bug does not get filed twice.

Can it post to a different Basecamp tool, like the message board or card table?

Yes. The default is the engineering project's to-do list, but you can ask it to use a different list or a different project entirely when you set it up.

What if my support team uses a different tag than 'bug'?

Tell the workflow which tag or set of tags marks an engineering issue in your Zendesk, and it will filter on that instead.

Does the original Zendesk ticket get updated?

Yes. After the Basecamp to-do is created, the workflow posts an internal note on the Zendesk ticket with the new Basecamp link, so support agents know the bug has been tracked without leaving Zendesk.

Auto-route Zendesk bug tickets to Basecamp engineering to-dos

Every 15 minutes, triage new bug-tagged Zendesk tickets into our engineering team's Basecamp project as ready-to-work to-dos.

Trigger: cron, every 15 minutes.

Step 1. Find candidate tickets in Zendesk. Use Search Tickets to pull tickets created or updated since the last run that carry a 'bug' tag (or whichever tag the user maps to engineering bugs at setup time). Also include tickets that do not have the tag yet but whose subject or first description clearly describes a defect, so the agent can catch ones support agents forgot to label.

Step 2. For each candidate ticket, use Show Ticket and List Ticket Comments to read the requester's description and the full comment thread. Decide whether this is genuinely a software defect rather than a how-to question, a billing issue, an account question, or a feature request. If it is not a real bug, skip it and move on.

Step 3. For tickets that are real bugs, draft a structured engineering to-do with: a short imperative title (for example, 'Fix double-charge on annual upgrade checkout'); a description with what the customer did, expected vs actual behavior, repro steps extracted from the thread, environment hints (browser, OS, plan tier, region) when mentioned; a severity label of low, medium, or high based on impact language in the ticket (data loss, blocked workflows, or revenue impact = high; degraded but workable = medium; cosmetic or single-user nuisance = low); and a link back to the original Zendesk ticket.

Step 4. File the to-do in Basecamp. Use List Projects and Get a Project to locate the engineering project and pull its dock so you can find the todoset id and the bug-triage to-do list inside it. If a 'Bug triage' list does not exist yet, use Create a To-Do List to make one. Then use Create a To-Do to add the drafted bug there. Set a due date proportional to severity: high = 2 business days out, medium = 1 week out, low = 3 weeks out.

Step 5. Close the loop in Zendesk. Use Update Ticket to add an internal note on the originating ticket that says 'Tracked in Basecamp' and includes the URL of the newly created to-do. The note must be internal only, never a public reply to the customer. This lets support agents see the handoff without leaving Zendesk and prevents the same ticket from being re-triaged on the next run.

Skip rules. Do not create Basecamp to-dos for tickets that are clearly questions, billing issues, account access problems, or feature requests. Do not create a second to-do for a ticket that already has a 'Tracked in Basecamp' internal note. Do not post any public comment back to the customer; the only Zendesk write is the internal note.

Ask me at setup time: which Zendesk tag (or tags) I want treated as 'engineering bug'; which Basecamp project is the engineering project; which to-do list inside it should hold new bugs; and whether I want a default assignee per severity level.

What it does

Checks Zendesk every 15 minutes for new tickets that look like real bugs.
Drafts a clean engineering to-do for each one with title, repro steps, severity, and a link to the ticket.
Files the to-do in your Basecamp engineering project's bug-triage list and sets a due date based on severity.
Posts an internal note back on the Zendesk ticket so support agents can see it has been handed off.

What you’ll need

A Zendesk account with permission to read and update tickets.
A Basecamp account with access to the engineering project where bug to-dos should land.
A convention for tagging or describing bug tickets in Zendesk so the agent can find them.

How to customize it

Change how often it runs, for example every 5 minutes for a noisy queue or once an hour for a slower one.
Point it at a different Basecamp project or a different to-do list, like a 'New bugs' inbox versus a 'Triage' list.
Adjust how severity maps to due dates, or add a default assignee for each severity level.

Use cases

Feedback Triage
Notifications & Alerts
Data Sync

Zendesk bug tickets to Basecamp engineering to-dos

Integrations

Type

Categories

What it does

What you’ll need

How to customize it

Use cases

FAQs

Related prompts