Skip to main content
The first sign is usually indirect. Someone notices QA has gone quiet, or a dashboard flattens out, and the conclusion is that the help desk connection has died. Sometimes that is exactly right. Often the tickets are arriving fine and something further down the line stopped, so the fastest route to an answer is to establish which of those two you are dealing with before you reconnect anything.

​
Are tickets missing, or just evaluations?

These look identical from a dashboard and have nothing in common underneath. Open the interactions list and filter by Workspace, which narrows it to a single connection, then find the most recent ticket that came through it:
  • Recent tickets, no recent evaluations. Syncing is fine. This is an evaluation problem; start with Why wasn’t my ticket evaluated? instead.
  • Nothing since a particular day. Something stopped, and that date is your most useful piece of evidence. Note it before going further; it usually lines up with a change on the help desk side.
Pick one ticket you know exists in the help desk and was created after that date, then search for it in Rulebase. A ticket that is absent confirms a sync problem rather than a display or filter problem.

​
What the Connections page tells you

Go to Settings > Connections. Each connected account appears as a row under its provider, labelled with the account it points at (your Zendesk subdomain, your Intercom app, your Jira site), which matters when you have more than one connection to the same provider and only one of them is stalled. The row carries one piece of diagnostic information: Last synced on, with a date. A date that sits close to your last known ticket is a strong signal you have found the right connection.
Not every connection shows Last synced on, and its absence is not itself a fault. Some connections receive data without recording a sync timestamp, so treat the date as useful when present rather than as a health indicator when missing.
Be aware of what the page does not do: there is no error badge, no red state, and no warning when credentials stop working. A connection that has been failing for a week looks exactly like a healthy one apart from its date. That is why the ticket-level check above is worth doing first.

​
Read the activity log

Open the row’s overflow menu and choose View activity. The Activity Log dialog lists what the connection has received, newest first, as a timestamp followed by the raw payload. It has a search box and a date range picker, so you can jump to the day things stopped and see whether anything arrived at all. Before you interpret it:
  • The log records data pushed to Rulebase by the provider. Connections that work by Rulebase pulling on a schedule will not have entries here, so No activity logs yet does not mean the connection is broken.
  • Entries stop at a fixed number per connection, with the oldest discarded, so a quiet connection can still show a full log from weeks ago.
The boundary is decisive. If entries run daily and then stop dead on the date your tickets stopped, the delivery path stopped on that date. Check the help desk’s webhook or app configuration first, and if that side looks right, contact Rulebase support.

​
Reconnect the account

Reconnecting is the same Add button you used the first time, in the provider’s row. There is no separate reconnect action, and you do not need to disconnect first. You need permission to manage integrations to use it; without that, the provider’s Add button is disabled. Authorize the same account you connected originally. Rulebase matches what you authorize against the connection it already has (by Zendesk subdomain, Intercom app, Jira site, Salesforce org, or Slack workspace) and refreshes that connection’s credentials in place. Your history, settings, and sync position survive. Authorize a different account and you get a second connection alongside the first rather than a replacement, which is worth avoiding: two connections to overlapping data is harder to unpick than the original problem.
Connections carry the access of whoever authorized them, so reconnect as an account with durable access rather than whoever happens to be at the keyboard. When a connection breaks shortly after someone leaves, the person who originally authorized it is usually the reason.
Because the connection is refreshed rather than replaced, it keeps its place in the sync. Tickets from the gap arrive over the following minutes rather than being lost, so give it a little time before deciding the reconnect did not work.

​
Disconnecting is not a repair step

Disconnect in the same overflow menu is a common instinct and rarely the right move. It asks whether you are sure and tells you the action cannot be undone, which is accurate about the connection itself. Your data is not deleted. Tickets, evaluations, and reports that came in through that connection stay exactly where they are. What you lose is the connection’s configuration and its place in the sync, so a reconnect afterwards starts fresh rather than resuming. Reach for it when you are deliberately retiring a connection or replacing it with a different account, not as a way of restarting one that stalled.
If you connected Jira and its service requests never appeared as tickets, this is not a sync failure. Open the row’s Configure action and check Import service requests as interactions, which is off unless someone turned it on.

​
Confirm tickets are arriving again

Give it a few minutes after reconnecting, then check in this order:
  1. The connection’s Last synced on date has moved to today.
  2. The interactions list, filtered to that Workspace, shows tickets created after the date things stopped.
  3. The specific ticket you looked up at the start is now present.
  4. Something raised in the help desk right now appears in Rulebase shortly afterwards. This is the only check that proves the connection is live rather than catching up on a backlog.
Tickets that arrive from the gap go through the same path as any other new ticket, so eligible ones are evaluated without anyone re-running them and the quiet period in your QA numbers fills in on its own. If tickets are arriving but evaluations still are not appearing, the sync is fixed and what remains is a different problem.