Feature · Freshservice Teams Integration

Push Freshservice tickets to the right Teams channel with context.

IT teams running Freshservice as the service desk and Microsoft Teams as the chat surface need the two to speak so engineers see tickets where they already work. The naive integration posts every ticket to one channel and gets ignored within a week. Strkr sits between them as the open API layer: Freshservice posts a webhook on ticket events, a Strkr flow decides which Teams channel receives the alert based on category, priority, and the on-call rotation, and a reply thread in Teams routes back as an internal note. Native connectors are on the public roadmap, with reference flows available today.

Start free trial See pricing
Why the naive Teams bot fails

The five ways default service-desk-to-Teams bots lose engineer trust.

The naive integration enables the Freshservice Teams app, picks one channel, and sends every ticket. Within a week the channel is a wall of noise, engineers mute it, and the critical incident is buried under laptop requests. Strkr fixes the signal-to-noise ratio by making channel routing a rule the ops lead edits in minutes, not a per-ticket Freshservice automator block.

Firehose channel

One channel gets every ticket, everybody mutes.

The default bot posts every ticket to one channel. Within a week it is noise. A Strkr flow routes by category: network issues to #net-ops, access requests to #identity, hardware to #it-stock. Each channel sees only what its on-call owner cares about. The signal survives the week.

No reply threading

Engineer answers in Teams, Freshservice never sees it.

An engineer replies in the Teams thread with the fix. The naive bot does not round-trip the reply. The fix never makes it to the Freshservice ticket and the audit trail has a hole. A Strkr flow catches thread replies and writes them as internal notes with author attribution. The ticket history is complete.

On-call blindness

Alert pings everybody, nobody owns it.

A P1 alert @mentions a channel of twenty engineers. Everyone assumes someone else saw it. A Strkr flow reads the on-call schedule, @mentions the engineer on duty, and names the backup if the primary does not acknowledge in five minutes. Ownership is explicit, not diffuse.

Context thin

Teams card shows title only, no requester story.

The default card shows the ticket subject. The engineer clicks through to find out the requester is a strategic account on a renewal. A Strkr flow builds a richer adaptive card: requester company, ARR tier, last three tickets, asset history. The engineer reads the story before clicking.

Approval friction

Service request approval needs a Freshservice login.

A software purchase approval request requires the approver to log into Freshservice to click Approve. The approver works in Teams and the request sits. A Strkr flow renders the approval as a Teams adaptive card with Approve and Reject buttons that write back to Freshservice. The decision happens in Teams.

Mute escapes alert

P1 breach fires into a muted channel.

A P1 SLA breach lands on a channel the on-call engineer muted after the firehose incident. The breach is invisible. A Strkr flow escalates P1 breaches to direct message plus channel mention, so a mute does not swallow the alert. The escalation ladder is a visible rule, not a configuration deep inside Teams.

The flow template

What ships out of the box on day one.

Strkr publishes a reference flow for Freshservice-to-Teams that covers the common pattern: category-driven channel routing, priority-driven escalation, on-call @mention, enriched adaptive card, reply round-trip, and approval cards. The template is a starting point, not a cage. Flow authors fork it, change the routing table, and keep the audit log.

Category routing

Each ticket category has a dedicated channel.

The routing table lives on the Strkr side as an editable map. Category maps to channel ID, backup channel, and on-call rotation. The flow reads ticket.category, picks the row, and posts to the right channel. The ops lead changes the map without touching flow logic.

Priority escalation

P1 breaks past channel into direct message.

A P1 ticket @mentions the on-call engineer and sends a direct Teams message. A P2 posts to the channel with an @mention. A P3 posts without mention. The escalation ladder is a visible table and the on-call rotation data comes from a Strkr-side schedule the ops lead maintains.

Enriched adaptive card

Card shows the full requester story.

The adaptive card renders ticket subject, priority, requester company, ARR tier, last three tickets on the same requester, and the deep link to Freshservice. The engineer reads context before clicking through. The card template is editable from the Strkr admin page, not hardcoded.

Reply threading

Teams thread replies land in Freshservice.

A reply in the Teams thread fires a webhook back to Strkr, the flow writes an internal note on the ticket with the author identified, and the audit log records the round-trip. If the reply is marked public via a button on the adaptive card, it writes as a public note to the requester.

Approval cards

Approve and Reject buttons live in Teams.

A service request routed for approval renders an adaptive card with Approve and Reject buttons. The decision writes back to Freshservice as an approval event with the approver identity, the timestamp, and the audit log entry. The approver does not open Freshservice.

Status round-trip

Ticket resolve posts the fix to the thread.

When a Freshservice ticket moves to Resolved, the flow posts the resolution text, the time-to-resolve, and the acting agent to the original Teams thread. The engineer who helped debug sees the outcome without checking Freshservice.

Daily digest

Morning summary lands in #it-leads.

A scheduled flow posts the morning summary to the leadership channel: open tickets by priority, overnight breaches, high-ARR customers waiting, and the top three categories. The IT lead reads one message before standup instead of three dashboards.

Where it fits in the stack

The Teams integration is one piece of the IT platform.

The Freshservice-to-Teams bridge is not a point tool. It is one flow in the broader Freshservice integration surface that also writes to the CRM, the Projects module, the HRIS, and the audit log. The ops lead owns one platform, not a dozen vendor dashboards. The security review is one review, not a dozen.

Shared with CRM

Account context flows into the Teams card.

The requester ARR, plan, and renewal data on the Teams adaptive card come from the Strkr CRM. The enrichment is a single pipeline that runs once per ticket. Add a new field to the CRM and the Teams card picks it up without touching the Teams flow.

Shared with Projects

Escalations route to the Projects module.

A ticket tagged for engineering generates a Projects issue, posts a thread to the engineering Teams channel, and keeps the two linked. The engineering lead sees the issue in Projects, the thread stays live for debug, and status changes round-trip. One flow, three surfaces.

Shared with HRIS

Onboarding tickets ping #new-hires.

The BambooHR-driven onboarding flow posts a thread to the new-hires channel when a provisioning ticket opens, so the hiring manager watches progress in Teams. The same flow drives the ticket in Freshservice. The Teams visibility costs no extra wiring.

Shared audit log

Teams round-trips land in the central audit.

Every reply round-trip, every approval decision, every mute escape writes to the Strkr append-only audit log. A compliance audit for IT runs one query across the service desk, the Teams integration, and the CRM. The answer is one URL, not three.

Compliance and trust

What the security review already covers.

Integration flows run inside the same tenant boundary as the CRM. Credentials are stored in KMS-backed encrypted storage, every webhook delivery is signed, every outbound API call carries a per-tenant rate budget, and audit logs are append-only. The security review for the Freshservice-Teams bridge is a subset of the review already completed for the Strkr platform.

HIPAA with BAA

Protected health info stays inside the tenant.

IT teams at healthcare software vendors run Freshservice with HIPAA-covered tickets. Strkr is HIPAA compliant with a BAA available on request. The integration flow runs inside the tenant boundary with no third-party processor in the data path. Teams receives the alert through the Microsoft Graph API inside the tenant Microsoft 365 boundary.

SOC 2 posture

Type II audit in progress through 2026-Q4.

SOC 2 Type II is in progress through 2026-Q4 with the control inventory published to prospective customers under NDA. The integration flows inherit the controls: access reviews, change management, incident response, and logging. The security review for the Teams bridge is a short checklist on top of the main audit.

GDPR right-to-delete

Deletion propagates through Teams audit entries.

A GDPR deletion request on a Freshservice requester propagates through the Strkr audit log, flags the matched Teams round-trip entries for redaction, and records the deletion event. The redaction preserves the ticket-event metadata the auditor needs while removing the PII fields.

Signed webhooks

Every inbound event is cryptographically verified.

Freshservice webhooks arrive signed with an HMAC the Strkr endpoint verifies before accepting the payload. Teams interaction callbacks are verified against the Microsoft Graph signing key. A replay of an old delivery with a tampered body is rejected and logged.

Scoped Teams app

Install into the tenant, not into the user profile.

The Teams app installs at the Microsoft 365 tenant level with least-privilege Graph scopes: channel post, interaction callback, and user lookup. The flow runtime calls Graph with the tenant token and never accesses user mailboxes or personal chats outside the configured channels.

Append-only audit

Who approved what in Teams, with timestamp.

Audit log entries carry the acting user from the Teams approval card, the approval decision, the Freshservice ticket ID, and the resulting write. An IT lead answering a procurement audit has the chain in one place: who approved the purchase, when, and from which Teams channel.

Make the service desk visible where engineers already work.

Reference flows for category routing, approval cards, and reply round-trips are production ready. Keep the audit log, keep the flat seat price.

Request integration access See IT service desk automation
Common questions

What buyers ask about this feature.

Does Strkr have a native Freshservice-to-Teams connector today?

Not today. The current pattern is webhook-plus-flow: Freshservice posts a signed webhook on ticket events, a Strkr flow routes to the right Teams channel through the Microsoft Graph API, and reply callbacks route back to Freshservice as internal or public notes. The native Freshservice connector is on the public roadmap. Teams integrating this quarter use the reference flow template, which is production ready and covers category routing, priority escalation, enriched cards, approval buttons, and audit.

How does channel routing work when a ticket spans multiple categories?

The routing table supports multi-match rules: a ticket can post to a primary channel and reference a secondary channel in the card. The engineer in the primary channel owns the ticket, the secondary channel receives a lightweight note that something crossed their category, and the audit log records both. The ops lead sets the primary-secondary preference per category pair on the Strkr admin page.

Can approvers approve service requests directly from Teams without opening Freshservice?

Yes. Approvals render as Teams adaptive cards with Approve and Reject buttons. The decision writes back to Freshservice as an approval event with the approver identity, the timestamp, and the audit log entry. If the approver needs to see more detail before deciding, the card has a View in Freshservice deep link. The common path does not require a Freshservice login.

What happens when an engineer replies in the Teams thread with the fix?

The reply fires a webhook back to Strkr, the flow writes an internal note on the Freshservice ticket with the author identified from the Teams user ID, and the audit log records the round-trip. A button on the adaptive card lets the engineer mark the reply as public so it goes to the requester as a Freshservice public note instead. The ticket history is complete without copy-paste.

How do we prevent the Teams channel from becoming a firehose of noise?

The default template routes by category and priority instead of posting every ticket to one channel. Low-priority tickets post as compact cards; P1 tickets break past the channel into direct message. The engineer only sees what matches their on-call surface. The ops lead can further tune by throttle rules so a surge of similar tickets collapses into a summary post with a count and a link.

What happens to the integration if we move off Freshservice or Microsoft Teams?

The Strkr audit log holds the full history of events, approvals, and round-trips. CSV export of the mapping and the event log is a one-click action. If the team swaps Freshservice for a different service desk, the Teams side keeps its channel routing and the new desk points at the same Strkr flow with its mapping adjusted. If the team swaps Teams for Slack, the Freshservice side keeps its webhook and the new chat surface points at the same flow. The orchestration lives on the Strkr side.

Related features

Pair this with...

Freshservice Integration Freshservice BambooHR Integration Freshservice Workflow Automator IT Service Desk Automation AI CRM Integration Services AI Workflow Automation API and Webhooks Automation Platforms

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing