EscalatePricing

Troubleshooting

A symptom-keyed cookbook for the most common product-behavior issues. Each entry: symptom → likely cause → recovery steps → escape-hatch.

What this page covers: Product-behavior failures that show up after Escalate is installed and running.

What this page does NOT cover: OAuth install errors. Those are vendor-specific and live at:

If your symptom is an error message from an OAuth callback page, start with the per-vendor page; if it's about something Escalate SHOULD have done but didn't, you're in the right place.

§1 Why didn't an alert fire on a stalled deal?

Symptom: Legal has been silent on a contract redline for 3 business days, and you expected an alert. None arrived.

Likely causes:

  1. The threshold hasn't crossed. Default Legal threshold is 2 BD. Run /escalate stats — if you see the deal listed in "covered" with no alert, the silence-tracker is running but the threshold may not have crossed (weekends + holidays don't count per Alerts).
  2. The classifier didn't categorize the message as a substantive ask. Routing questions ("who's the lead on Acme?") and completed-task messages ("done, see attached") don't start silence timers. Check the original message: if it's framed as a question that requires action ("can we accept this clause?"), it's substantive; if it's framed as a ping ("any updates?"), the classifier may have rejected it.
  3. The sub-thread isn't in a deal channel. Escalate only watches channels it auto-created. If Legal is being asked in a DM or in a non-Escalate channel, the bot can't see it.
  4. The workspace is in cancellation grace period. Alerts pause during the 30-day read-only window post-cancellation. The audit chain still records but no DMs fire.

Recovery steps:

  • Run /escalate stats to verify the deal is covered + the trigger is in-force.
  • Open the deal channel. If you don't see one, the trigger may not have fired — see §2 below.
  • If the sub-thread IS in the deal channel and IS a substantive ask, the classifier may have misjudged. Wait one more business day; the follow-up reminder cycle may pick it up.

Escape-hatch: If this doesn't resolve, email hello@tryescalate.com with the deal name + the original message permalink + the role you expected to alert; the founder has audit- chain access to trace what the classifier decided.

§2 Why didn't a channel auto-create?

Symptom: A deal moved into a qualifying stage in your CRM, but no Slack channel appeared.

Likely causes:

  1. The deal didn't clear minAmountUsd. Default is $75,000 USD. Deals below this don't qualify. Check the deal's amount field in CRM.
  2. The deal's stage doesn't match qualifyingStages. Default stages: Negotiation, Verbal Commit, Contract Sent, Proposal. If your pipeline uses different stage names (e.g., "Final Negotiation"), they won't match by default — see Triggers.
  3. The CRM amount field is null AND requireAmount: true. Deals without amount fields don't qualify under the default.
  4. The CRM polling lag (Salesforce only). Salesforce uses a 5-minute poll, so there's up to a 5-minute window between stage transition and trigger evaluation. HubSpot uses webhooks (~30s).
  5. The CRM connection broke. Token expiry or vendor-side revocation. Check /escalate stats — connection status is surfaced there.

Recovery steps:

  • Verify the deal's amount + stage against your trigger config: /escalate config trigger.
  • For Salesforce, wait 5 minutes after the stage transition.
  • If the CRM connection is broken, see §3.
  • If the trigger config looks right but the channel still didn't create, run /escalate retrofit (admin) to force a re-scan.

Escape-hatch: If this doesn't resolve, email hello@tryescalate.com with the deal ID (or name) + the stage name + the amount + a screenshot of /escalate stats; the founder can inspect the trigger-evaluation log.

§3 How do I reconnect a broken CRM token?

Symptom: /escalate stats shows "CRM connection: disconnected" or a deal that should have qualified didn't, and the connection status is degraded.

Likely causes:

  1. OAuth refresh token expired. Salesforce: tokens are refreshable for 1 year post-grant if used, less if dormant. HubSpot: refresh tokens are durable but can be revoked by the workspace admin.
  2. The HubSpot/Salesforce app was uninstalled OR revoked from the vendor side. Check your CRM's connected-apps panel.
  3. The OAuth user who originally connected the CRM was deactivated. Salesforce + HubSpot tokens are user-scoped; if that user is gone, the token's gone.

Recovery steps:

  • Re-run /escalate config crm (admin) and pick the vendor again. Follow the OAuth consent flow.
  • For Salesforce: in Setup → Connected Apps → "Escalate," verify the app is still authorized. Re-authorize if not.
  • For HubSpot: Settings → Integrations → "Escalate," verify the app is connected. Re-connect if not.

Escape-hatch: If the re-OAuth fails with an unfamiliar error, see Slack setup → Troubleshooting for the OAuth error-page recovery table, or email hello@tryescalate.com with the error text + the vendor.

§4 Why did my role-assignment vanish?

Symptom: You set Legal = @alice via /escalate config roles, but new deal channels are creating without Legal in the invitee list.

Likely causes:

  1. @alice was deactivated in Slack. Escalate skips deactivated users on channel invite. The role mapping persists; it just can't resolve to a live user.
  2. You re-ran /escalate config roles and didn't re-confirm Legal. The modal pre-populates with the current value, but if the user-picker was cleared (intentionally or accidentally) before submit, the field saves as null.
  3. The user joined a different workspace. Slack user IDs are workspace-local; if @alice was invited to a separate Escalate- installed workspace, the user-picker entry doesn't cross over.

Recovery steps:

  • Run /escalate config roles again; verify each role's user- picker is populated.
  • If a user shows as "deactivated," reactivate them in Slack OR pick a different user for that role.
  • Existing in-flight channels retain their original role assignments — new channels use the updated config.

Escape-hatch: If this doesn't resolve, email hello@tryescalate.com with the workspace ID + the role + the expected user's Slack handle.

§5 The bot isn't responding to slash commands

Symptom: You type /escalate stats (or any other slash command) and Slack returns "command failed" or nothing happens.

Likely causes:

  1. The Escalate Slack app was uninstalled and re-installed. The bot user ID changes; slash commands may briefly fail until the workspace re-registers. Wait 30s and retry.
  2. Slack's slash-command service is degraded. Check Slack status.
  3. Workspace exceeded Slack API rate limits. Rare but possible on workspaces with very high message volume. Retry in 1-2 minutes.
  4. The Escalate worker is down. Bot ingest will be lagging. /escalate stats will fail; alerts may also be delayed.

Recovery steps:

  • Retry the command after 30 seconds.
  • Run /escalate help <message> — if the help command works but others don't, the issue is command-specific (likely an audience tier — admin or founder-only — that you're not in).
  • Check the Escalate status page if you're seeing widespread bot unresponsiveness.

Escape-hatch: If this doesn't resolve within 5 minutes, email hello@tryescalate.com with the workspace name + the command + the exact error message (if any); the founder can check ingest health + bot heartbeat.

Next steps

  • Setup not yet complete? Start with Slack setup.
  • Want to inspect what's covered: /escalate stats or Coverage Report.
  • Found a behavior we should document better? Email hello@tryescalate.com — we add troubleshooting entries based on what customers actually hit.