Configuration
Tune posting modes, auto-analyze thresholds, time buffers, custom field mapping, and the public reply template per binding
Each support desk binding has a set of knobs that control how SigSentry interacts with your tickets. Configure them under Project → Support Desk → Configure on each binding.
Result posting mode
Where SigSentry posts triage and analysis results.
| Mode | Triage post | Analysis post | Best for |
|---|---|---|---|
internal | Internal note | Internal note | Default — agents see results, customers don't |
public | Public reply | Public reply | Auto-acknowledging tickets visibly to customers |
both | Internal note | Public reply (templated) + internal note | Customer-facing acknowledgment plus full detail for agents |
public mode posts content directly to the customer. Use the
public reply template (below) to control the wording — never let
raw triage notes go to customers without templating.
Auto-analyze threshold
The minimum triage severity that triggers a full analysis. Triage runs on every ticket; the full analysis only runs when severity meets the threshold.
| Threshold | Auto-analyzes |
|---|---|
disabled | Never — only triage runs |
critical | Critical only |
high | High and critical (recommended starting point) |
medium | Medium and above |
low | Low and above (most tickets) |
For most teams, high is the right starting point: critical and
high-severity tickets get the full analysis treatment, and lower-
severity ones get just a triage note.
Default time buffer
When the ticket doesn't specify a time window (e.g. "Checkout has been broken since 9am"), SigSentry needs to pick one for the analysis. The default time buffer is how many hours back to query.
Default: 2 hours. Range: 1–24 hours.
If your incidents typically manifest gradually, raise this to 4 or 6. If your services are noisy and analyses get drowned in unrelated events, drop to 1.
Custom field mapping
Map SigSentry's structured triage output to your platform's custom fields. Each platform's field naming is slightly different — see the platform-specific page:
- Zendesk — uses numeric field IDs
- Freshdesk — uses field names with
cf_prefix - Intercom — uses custom attribute names
The fields SigSentry can populate:
| SigSentry field | What it contains |
|---|---|
severity | The triage classifier's severity (e.g. "high") |
affected_service | The service the triage thinks is affected |
analysis_url | Link to the SigSentry analysis (only set when auto-analyze fired) |
Mapping is optional. If you don't map any fields, SigSentry just posts the internal note and skips field updates.
Public reply template
When posting mode includes public, the message uses a template you
can customize per binding. The default:
Hi {{requesterName}},
Thanks for reporting this. Our team is investigating and will follow
up shortly.
— SigSentry Auto-TriageAvailable variables:
| Variable | Substitutes |
|---|---|
{{requesterName}} | The ticket requester's name |
{{ticketId}} | The ticket's ID (numeric or alphanumeric depending on platform) |
{{severity}} | Triage severity ("low", "medium", "high", "critical") |
{{affectedService}} | The service the triage thinks is affected |
If you want different templates per severity, use a single template and let your support team's escalation rules handle it downstream — Zendesk triggers, Freshdesk automations, Intercom workflows can all react to custom field values.
Editing configuration
Changes take effect on the next incoming ticket. Existing tickets already triaged aren't re-processed.
To re-trigger triage on an existing ticket, edit the ticket in the support platform (any change triggers a new webhook event).
Per-binding configuration
All the settings above are per-binding. So if you have multiple Zendesk bindings (different subdomains for different teams), each can be configured independently.