Freshservice Integration

How a ticket flows

1. Ingest. Your Workflow Automator rule POSTs the ticket to POST /api/v1/tickets/ingest with a scoped API key. One ticket is ingested at most once: retries and rule re-fires return the original run instead of posting a second card.
2. Classify. AscendCore classifies the ticket text into a runbook intent with a confidence score. Low-confidence or unrecognized tickets are received, audit-logged, and left alone (no_action). Nothing executes on a guess.
3. Approve.The matching runbook's approval card is posted to your IT admin channel (Slack, or Teams for Teams-channel orgs), with a threaded note showing the originating ticket number, a link back to it, and the AI's classification and confidence. A human approves or denies. Every runbook is approval-gated. There is no autonomous path.
4. Execute.On approval, the runbook runs against your stack (Okta, Entra ID, M365) and the action is recorded on the org's tamper-evident SHA-256 audit chain.
5. Write back. The decision (approved or denied, by whom, at what time) is appended to the originating ticket as a private note. Your ITSM keeps the complete story.

Step 1: Create a scoped API key

In your admin portal under API, create a key with the ticket:ingest scope. Least privilege applies: a key with only this scope can submit tickets but cannot execute runbooks directly, read audit rows, or browse the catalog.

You will paste this key into the Automator rule's webhook headers in the next step. It is stored inside the rule, visible only to Freshservice admins who can edit workflows.

Step 2: Add the Workflow Automator rule

In Admin → Automation & Productivity → Workflow Automator, create a new ticket workflow:

• Event: Ticket is raised. Add a condition (for example, category or group) if you only want a subset of tickets routed to AscendCore.
• Action: Trigger Webhook, with:
  • Request type: POST
  • URL: https://ascendcore.ai/api/v1/tickets/ingest
  • Custom headers: Authorization: Bearer ak_live_...
  • Encoding: JSON, with Content set to Advanced (custom payload), below

{
  "source": "freshservice",
  "ticket": {
    "ticketId": "{{ticket.id}}",
    "subject": "{{ticket.subject}}",
    "description": "{{ticket.description_text}}",
    "url": "{{ticket.url}}",
    "requesterEmail": "{{ticket.from_email}}"
  }
}

The {{ticket.id}} placeholder emits a bare number; the API accepts it quoted or unquoted. {{ticket.description_text}} is the plain-text form of the description, which keeps HTML markup out of the classification input. Raise a test ticket to confirm a 200 before relying on the rule.

Payload reference

Supported intents in this release

Tickets that classify to anything else are acknowledged with no_action and audit-logged. Additional intents arrive as additive extensions; your Automator rule does not change.

What the write-back looks like

When the approval reaches a decision (from Slack, Teams, or the dashboard), AscendCore posts a private note on the originating ticket:

[AscendCore] Runbook decision: APPROVED
Runbook: MFA Reset
Target user: Sarah Chen (sarah.chen@acme.com)
Decision by: slack:U0123APPROVER at 2026-06-09T17:42:11.310Z
Action executed by AscendCore after explicit human approval.
This decision is recorded on the org's tamper-evident audit chain in AscendCore.

Denied requests get a note too, stating that no changes were made. The note is private (agent-facing, off the requester thread) and is posted with a Freshservice agent API key you provision during onboarding (note permission on tickets; least privilege applies). The write-back is deliberately non-blocking: if your workspace is unreachable, the approval flow itself is unaffected and the decision remains on the AscendCore audit chain.

Security model

• Scoped bearer auth.The integration reuses AscendCore's standard API-key model. Keys are salted-hashed at rest, scope-gated, rate-limited, and revocable from the dashboard.
• Approval-gated, always. Ingested tickets follow the same human-in-the-loop policy as every other trigger. AI classifies; it never executes.
• Audit-chained.Every ingestion (including no-action dispositions) and every decision is recorded on the org's tamper-evident SHA-256 audit chain, usable as evidence for SOC 2 and ISO 27001 reviews.
• Idempotent. Duplicate submissions of the same ticket return the original run. Retry storms cannot flood your approval channel.
• Sandbox-aware. If your org is in Sandbox Mode, ingested tickets exercise the full approval flow with mocked execution and no real write-back.