Integrations & Tickets

Overview

ET Ducky supports both native ticketing (ET Ducky tickets stored in your organization) and third-party integrations (Jira, ServiceNow). You can use one or both: create and view native tickets from the dashboard and Run Troubleshooting, and optionally connect Jira or ServiceNow so automated troubleshooting can link to and update external tickets. End users on any agent-installed machine can submit a support ticket without opening the full desktop app via the ET Ducky Support shortcut.

Integrations Page

Available from the user menu (avatar dropdown): Integrations. Only organization admins can add or edit integrations.

Ticketing (Jira, ServiceNow)

  • Add integration — Choose provider (Jira or ServiceNow), enter base URL, credentials (API token or Basic), and optional project/table, host field, and query template.
  • One active integration per organization — When you run troubleshooting or view tickets by agent, the active integration is used to list and update tickets.
  • Credentials are stored securely; only metadata (URL, project) is shown in the UI.
  • Use Edit to change settings; leave password/token blank to keep the existing credential.

Once configured, you can select tickets from the integration when using Run Troubleshooting and push the resulting report back to the ticket.

Tickets Page

Available from the top nav or user menu: Tickets. One list, shown as a board or a table.

All tickets

Lists all native ET Ducky tickets for the current organization: title, device (agent), status, assigned to, submitted by, and created date. Tickets appear here from three sources: created from the dashboard, submitted by an end user via the ET Ducky Support shortcut on an agent, or raised automatically by the agent's behavioral security monitor.

  • Filter bar — Search by title or device name, filter by status (Open, In Progress, Resolved, Closed), or filter by assignee. Filters apply instantly without a network request.
  • Inline status — Change a ticket’s status directly from the Status dropdown in the row; the change is saved immediately.
  • Inline assignment — Assign a ticket to any org member from the Assigned to dropdown in the row.
  • View notes — Click any ticket title to open the ticket detail modal, where you can read all notes and add new ones. Notes are appended in chronological order.
  • Start live session — Click Start live session next to a ticket to open a live agent session. The session modal opens directly to the Guided Troubleshooting tab with that ticket pre-selected, ready to run diagnostics.
  • Board view — Switch to a column-per-status board and drag a ticket between columns to change its status. Click a card to open the same detail modal the table opens.
  • Right-click a ticket (or long-press on a touch screen) for open, live session, archive and select-all. Tick the checkboxes to act on several at once.

Jira and ServiceNow tickets in the same list

If a ticketing integration is configured, tickets from Jira or ServiceNow appear in the same list as native ones, marked with a Source chip. They are matched to a device by host name using the integration’s host field and query template.

  • Status is the provider’s. The dropdown on an integration row offers what that provider actually allows: for Jira, the transitions its workflow permits from the ticket’s current state; for ServiceNow, the state values configured on your instance. It is not ET Ducky’s four statuses, because a Jira issue may have no legal transition to “Closed” from where it is. If the provider will not say what is available, the status shows as read-only text.
  • The title links out to the ticket in Jira or ServiceNow. Notes and assignment stay with the provider — there is no mapping between ET Ducky users and Jira accounts, so assigning from here would put tickets on the wrong people.
  • Archiving is for ET Ducky tickets only. Integration rows cannot be selected for archive; close them in the system that owns them.
  • Coverage is reported. Integration tickets are fetched one device at a time, because a custom query template is written per host. If that sweep is cut short — a rate limit, a rejected credential, a provider outage — a notice above the list says how many devices were checked and why it stopped. A short list is never presented as a complete one.

Native ET Ducky Tickets

  • Create from dashboard — When running Guided Troubleshooting, you can create a new ET Ducky ticket (title, optional description) instead of linking to a Jira/ServiceNow ticket. The ticket is associated with the agent and appears on the Tickets page.
  • Ticket notes — Click any ticket title on the Tickets page to open the detail modal. Add notes (e.g. steps taken, findings, follow-up actions) and view the full note history in chronological order. Notes also get added automatically when you push a troubleshooting summary to a native ticket.
  • Status lifecycle — Update status directly from the Tickets page table (inline dropdown) or from the Guided Troubleshooting result step (select ticket and new status, then click Apply to ticket). Statuses: Open, In Progress, Resolved, Closed.
  • Native tickets are permanent — Unlike ETW event data, native tickets are stored indefinitely with no automatic retention policy. They accumulate until you close or manually delete them.
  • Reportable — Tickets and ticket notes are available as data sources in the Data Explorer and Smart Reports. Filter by status, group by device, or chart ticket volume over time. Built-in templates: “Ticket Status Breakdown” and “Tickets by Device.”

Automatic Security Tickets

When the agent's behavioral rule engine raises a detection, it can open a native ET Ducky ticket without anyone asking it to. This is on by default for any detection above low severity, and it is how a ransomware detection reaches a human when nobody is watching the dashboard.

  • Submitted by — ETDucky Security Monitor. Filter or search on that to separate automatic security tickets from user-submitted ones on the Tickets page.
  • Title — [SEVERITY] Rule name on process.exe, so the severity and the offending process are visible in the list without opening anything.
  • Body — rule ID, severity, process name and PID, the detection's title and description, and the host isolation state. The isolation line is always present: it says whether the machine was taken off the network, or if it was not, why not: below threshold, matched a response exclusion, not armed, running in dry run, or the isolation failed outright.
  • Assignment — Auto-assigned to the first user assigned to the agent's registration token, if one is set; otherwise unassigned. Status opens as Open like any other ticket.
  • Debounced per rule — One incident trips one rule across many processes, and that is one incident worth one ticket. Repeat firings of the same rule are suppressed for 15 minutes. Detections are still recorded in full on the agent's detections panel during that window.

Automatic security tickets fire the ticket_submitted automation trigger exactly like any other native ticket, so the normal automation routes (email, webhook, chat) work on them without special handling. If you want detections in Jira or ServiceNow rather than as native tickets, that automation is the supported path; so is the separate security_detection trigger, which fires on every detection rather than only the ticketed ones. See Behavioral Detections → Response Actions.

Turning it down without turning it off. Automatic ticketing is configured per rule, in a rule’s Tune panel under Systems → Security, scoped per organization, per tag, or per agent. It is governed separately from the auto-isolation threshold on purpose. Raising the bar for cutting a host off the network should not quietly raise the bar for telling a person. If one rule is too noisy for your fleet, set Open a ticket to Off on that rule alone and leave the rest as they are — you no longer have to choose between blanket ticketing and none.

End-User Support Shortcut

Users on a machine where the ET Ducky agent is installed can submit a support ticket without opening the full desktop app or having dashboard access.

How it works

  • The installer creates an ET Ducky Support shortcut on the Desktop and in the Start Menu (under the ET Ducky Agent folder).
  • Launching the shortcut runs the agent with --support: a small form opens (subject, description, optional name). Submitting the form sends the ticket to your organization via a local listener on the agent; the agent then forwards it to the cloud API using its own credentials.
  • No full desktop app UI and no technician login required. Tickets appear in the dashboard under Tickets, against the device that submitted them.

Security

The support listener runs only on 127.0.0.1; the agent bearer token is not exposed to the form. Only the organization that owns the agent receives the ticket.

Approved Applications

Maintain a workspace-scoped list of approved software. Smart Reports uses the list to surface unapproved installations across your fleet — e.g. “show me apps installed in the fleet that aren’t approved.”

Add an approved app

  • Open Integrations and find the Approved Applications card.
  • Enter the application name (matched case-insensitively against installed-software inventory) and an optional note explaining why it’s approved.
  • Click Add. The entry is visible to every member of the workspace immediately.

Querying against the list

Once the list has entries, open Smart Reports and ask questions like:

  • “Which agents have software installed that’s not on the approved list?”
  • “Show me unapproved apps installed in the last 30 days.”

The report planner joins your installed-software inventory against the approved list and excludes matches.

Only organization admins can edit the list. All members can read it (so unprivileged queries still work).

Security

The Security tab on the Integrations page groups everything related to behavioral-security detection: connections to third-party EDR/XDR providers and the behavioral-detection allowlist. (This tab was previously labelled “Behavioral Allowlist.”) Per-agent detection rules and response actions are configured separately under Systems → Security.

Security providers (EDR / XDR)

Connect a third-party endpoint security product so ET Ducky can surface its coverage alongside its own behavioral detection. Supported providers: CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint.

  • Add provider — Open Integrations → Security and click + Add provider. Choose the provider, give it an optional display name, and enter its API base URL, tenant/customer ID, and credentials (OAuth2 client ID + secret, or an API token).
  • Credentials are stored encrypted and are never returned to the dashboard — only metadata (provider, base URL, tenant ID, active state, last sync) is shown. Leave the secret blank when editing to keep the existing credential.
  • Connected providers’ coverage status appears on Systems → Security under Provider coverage.

Only organization admins can add or edit security providers.

Behavioral Detection Allowlist

Suppress false positives from the agent’s built-in behavioral-detection rules by exempting specific (process, rule) pairs. For example, AI coding assistants legitimately read many files for context analysis, which can trip the mass-file-access rule. Adding claude.exe + mass-file-access stops the false positive without disabling the rule for any other process.

Adding an exemption

  • Open Integrations → Security and find the Behavioral Detection Allowlist card.
  • Enter the process name (e.g. claude.exe, backup-agent) and pick the rule it should be exempt from (mass-file-access, suspicious-exec-chain, privilege-escalation, reverse-shell-heuristic, etc.).
  • Add an optional note for posterity. Click Add.

How enforcement works

  • The cloud API filters out detections matching the allowlist before they're persisted, so suppressed events never appear in the dashboard or fire alerts.
  • Agents fetch a per-org copy from /api/agents/me/behavioral-allowlist at startup and on configuration polls — future agent versions can self-filter so the bytes never leave the host.
  • Exemptions are scoped per-rule. claude.exe exempt from mass-file-access is still subject to every other rule.

Only organization admins can edit the allowlist. Keep entries narrow — broad exemptions weaken the protection model.

Script Repositories

Open Integrations → Script Repositories to manage every script your organization can run from a Live Session’s Shell tab, Fleet Tools, or an Automation rule. The page has two parts: built-in repositories that ship with ET Ducky, and connected repositories you wire up to external sources.

Built-in repositories

  • Default Scripts — A curated, read-only library shipped and maintained by ET Ducky: common diagnostics (CPU/memory, disk space, event-log errors), inventory (installed software, hardware info), and maintenance tasks (flush DNS, clear print queue). Available to every organization; you can’t edit or delete these, but you can view and run them.
  • Agent Generated Scripts — Your organization’s collection of scripts proposed by the AI during guided troubleshooting (see AI Diagnostics). Each one arrives pending review and only runs after an org admin approves it.

Click a built-in repository to open the viewer modal, where you can read the full content of any script before it runs.

Connected repositories

Click + Connect Repository to import scripts from an external source:

  • GitHub — repo URL (https://github.com/owner/repo), optional branch, path prefix, and a personal access token for private repos.
  • Azure Blob Storage — container URL plus a SAS token or key.
  • HTTP source — any URL that returns a file listing or direct downloads.
  • Distribution hubs — a distribution server registered under Distribution Servers can also be used as a script repository and browsed live.

For each connection set the file extensions to pull (default .ps1,.bat,.cmd), then use Test Connection to confirm credentials. Browse & Import lists the matching files; select the ones you want, choose a category, and import them into your org repository. Already-imported files are flagged so you don’t duplicate them.

Credentials & safety

  • Tokens are stored encrypted and never displayed again — leave the token field blank when editing to keep the existing one.
  • Removing a repository connection does not delete scripts already imported from it.
  • Imported and agent-generated scripts run through the same per-command security policy and org-admin approval gate as any other script — importing a script does not authorize it to run unattended.

Only organization admins can connect, edit, or delete repositories. All members can view and run approved scripts.