Freshservice (Two-Way)

Page your on-call team when an important Freshservice ticket is raised, keep paging until someone responds, and write the response back to the ticket.

Plan availability: The Freshservice integration is included on the Professional plan and up. See Plans & Billing.

What you'll get

Paging for the tickets you choose. Pick the priorities, ticket types and groups that should page someone. Everything else stays in the queue as usual.
Acknowledge from anywhere. Responders acknowledge from the phone call, a text reply, the Teams or Slack card, the mobile app or the Incidents page. JAMS Incident Management adds a private note to the ticket naming who responded, and stops paging everyone else.
Resolve from anywhere (optional). If you turn it on, responders can also resolve the ticket, which sets it to Resolved in Freshservice.
Paging stops on its own. When the ticket is resolved or closed in Freshservice, the alerts stop. If the ticket is reopened, paging starts again.
Open tickets from other alerts. A JAMS Scheduler failure, an email alert or any other flow can let the responder open a Freshservice ticket from the alert. See Open a Freshservice ticket from any alert.

What you'll need

A Freshservice account on any plan, and an account admin to create the workflows.
A Freshservice Integration User for JAMS Incident Management (Step 1). It holds the API key, so notes on tickets are clearly ours and nobody's personal key is in use.
Admin access to JAMS Incident Management.

Plan limits are yours to watch. Freshservice limits API calls per minute and, on some plans, how many automations that call outside apps can run each month. JAMS Incident Management makes one API call per ticket it is sent and one per response, so ordinary use is far below either limit. The way to stay well clear is to page only for the tickets that need it: put conditions on Workflow 1 (below) rather than sending every ticket.

Step 1 — Create an Integration User and copy its API key

In Freshservice: Admin → User Management → Integration Users, and create one named JAMS Incident Management. Copy the API key it shows.
Open it, go to Permissions → Roles → Edit, and give it the IT Agent role across all groups (or only the groups you will page for). It starts with no role at all, and until it has one every ticket request is refused.
Make sure it belongs to the workspace your tickets are in (on most accounts, IT).

Don't give it an admin role: it only needs to read, update and create tickets.

"Your API key is disabled" on your own profile? That's expected on newer Freshservice accounts, where personal API keys are off and integrations use Integration Users instead. Use the steps above.

Anything we write to a ticket is attributed to this Integration User.

Step 2 — Create the Connection in JAMS Incident Management

Go to Integrations → Freshservice.
Name the Connection, for example it-urgent.
Freshservice account: enter your address (the part before .freshservice.com) and paste the API key. Click Test connection. A green tick means the key works and can read tickets. "The API key works, but its user cannot see tickets" means the Integration User still needs its role or workspace (Step 1).
Which tickets page? Tick the priorities that should page someone (Urgent and High to start with). A successful Test connection loads your account's own ticket types and groups; you can also click Load groups and types from Freshservice. Leave a section empty to accept any value.
Write-back to Freshservice: choose whether responders can resolve the ticket (Let responders resolve the ticket). If flows will open tickets from other alerts, enter a requester email: Freshservice requires a requester on every ticket. Use a mailbox your team owns, such as alerts@yourcompany.com. Freshservice adds it as a requester and, with its default notifications, emails it when a ticket is opened.
Who gets notified? Add people, groups, on-call schedules or Teams/Slack channels, choose channels, and set the escalation interval.
Click Save Connection. The page shows your webhook URL and the exact setup for Freshservice. You can reopen it at any time from Show the Freshservice workflow setup under the Connection.

One Connection, one set of recipients. To page different people for different tickets (say, Network tickets to the network team), create one Connection per team, each with its own filter and its own pair of workflows.

Step 3 — Workflow 1: page when a ticket is raised

In Freshservice: Admin → Workflow Automator → New Automator. In Create Workflow, set Title JAMS Incident Management – page, Module Tickets, Workflow Type Event Based Workflow, and click Create.
Event: leave These events can be performed by on Anyone, choose Ticket is, then raised. Save.
Condition (from the left-hand list, connected after the event): Ticket Fields → Priority is Urgent, then Add new condition → Priority is High, with Match any at the top. Give it a label such as Priority is Urgent or High and Save. The setup panel on the Connection lists the exact conditions for your filter. JAMS Incident Management checks the filter again on its side, so a workflow set up too broadly still cannot page for tickets you didn't choose; the condition is there to keep other tickets from calling out at all.
Action (from the left-hand list, on the condition's YES path): choose Trigger Webhook. Use the Action block, not Web Request.
- Request Type: POST
- Callback URL: your webhook URL from Step 2
- Credentials: leave empty, and leave Custom headers unticked. The URL itself is the secret.
- Encoding: JSON, Advanced, with this body in Content (also on the Connection, with a Copy button):

{
  "ticketId": "{{ticket.id}}",
  "subject": "{{ticket.subject}}",
  "priority": "{{ticket.priority}}",
  "status": "{{ticket.status}}"
}

Test it before you save: under Test Input Params, enter the number of a ticket that matches your filter (for INC-12, enter 12) and click Test Webhook. Your recipients should be paged within about a minute. Leave the other values empty.
Save the action, then Activate the workflow.

Only ticketId is required. JAMS Incident Management reads the rest of the ticket from Freshservice itself, so a typo in the other fields cannot stop an alert. They are used only if Freshservice cannot be reached at that moment.

Step 4 — Workflow 2: stop paging when the ticket is resolved

Without this workflow, someone further down the escalation can be woken for a ticket that is already fixed.

New Automator: Title JAMS Incident Management – status, Module Tickets, Event Based Workflow.
Event: performed by Anyone, Status is changed from Any Status to Any Status. (Type status in the event box to find it.) Save.
No condition. Connect the event straight to an Action → Trigger Webhook with the same URL, settings and body as Workflow 1.
Save the action, then Activate the workflow.

Every status change is sent, and JAMS Incident Management decides: Resolved or Closed stops the alerts; a reopened ticket pages again, if it still matches your filter. Other changes are ignored.

How the two-way flow works

Voice call

The call reads the ticket subject and severity, then:

"Press 1 or say acknowledge to acknowledge this ticket in Freshservice."
"Press 2 or say resolve to resolve it in Freshservice." (only when resolving is turned on)

Text, Teams, Slack and the mobile app

The same choices appear as reply digits on a text message and as buttons on the Teams and Slack cards and in the app.

What changes in Freshservice

Response	In Freshservice	Here
Acknowledge	A private note: "Acknowledged by Jane Smith via a phone call in JAMS Incident Management." The status is not changed.	Paging stops. The incident shows as Acknowledged.
Resolve	Status set to Resolved, with a resolution note naming who resolved it.	Paging stops. The incident shows as Closed.
Resolved or Closed in Freshservice	—	Paging stops (Workflow 2).
Reopened in Freshservice	—	Pages again, if the ticket still matches the filter.

Acknowledge leaves the status alone on purpose. Freshservice has no "in progress" status by default, and moving the ticket to Pending would pause its SLA timer, which is not what "I've got it" means.

Resolve refused by Freshservice. Freshservice requires a resolution note by default; JAMS Incident Management always writes one, so that rule is covered. If your form requires other fields before resolving, such as a category, Freshservice rejects the update and the responder hears or reads which field it asked for, and paging continues. Test connection warns you about such fields in advance. Either make them optional, or turn resolving off on the Connection and resolve in Freshservice.

The Incidents page

Freshservice tickets appear on Incidents with Acknowledge and Resolve buttons that do the same as the call. If resolving is turned off on the Connection, Resolve closes the incident here only and says the ticket was left open.

Force close is for orphans, such as a ticket deleted in Freshservice. It closes the incident here without contacting Freshservice. If a responder acts on a ticket that no longer exists, JAMS Incident Management closes it here automatically and says so.

Open a Freshservice ticket from any alert

Any flow that isn't itself a Freshservice Connection can let responders open a ticket from the alert. Opening the ticket also acknowledges the alert.

Turn it on (admin, once per flow)

On the Freshservice Connection, set a requester email (Step 2, item 5).
Edit the flow (for example a JAMS Scheduler or email flow) and tick Let recipients open a ticket from this alert.
Ticket system: Freshservice. Freshservice connection: the Connection to open tickets in.
Instructions on failure (optional): the steps whoever picks up the ticket should follow. They appear at the top of the ticket's description.
Attach the alert's log to the ticket (optional): when the alert has a log, such as a JAMS Scheduler job log, it is attached to the ticket. Files are capped at 5 MB; a longer log keeps its end, where the error usually is.
Save the flow.

How a responder opens one

The alert gains a Create Freshservice ticket option: on the call ("Press 2 or say create ticket", using the next free number), as a text reply digit, as a button on the Teams/Slack card, and as Actions → Open a Freshservice ticket on Notification History. The call confirms with "Created Freshservice incident 12 and acknowledged the alert."

What the ticket looks like

Subject: JAMS Incident Management – <alert>.
Priority: follows the alert's severity (Critical → Urgent, Error → High, Warning → Medium, otherwise Low). Impact and urgency are set to match, so your priority matrix keeps it.
Description: the flow's instructions, then the alert text.
Requester: the Connection's requester email.
A private note naming who opened it and how ("Opened by Jane Smith via a phone call in JAMS Incident Management."), with the log attached when Attach the alert's log is on.

From then on, Acknowledge and Resolve on that alert sync to the new ticket, exactly as above. Pressing it twice does not open a second ticket. If the new ticket also matches Workflow 1, nobody is paged a second time: JAMS Incident Management recognises the ticket it just opened.

Verify it works

Raise a test ticket in Freshservice that matches your filter, for example Priority Urgent.
The Connection's status line should change to Last ticket received a few minutes ago, and your recipients should be paged.
Press 1 on the call. The ticket gets a private note naming you, and paging stops.
If resolving is on, raise another test ticket and press 2. The ticket moves to Resolved.
Raise one more, then resolve it in Freshservice before anyone answers. Paging should stop within seconds.
Raise a ticket that does not match the filter. Nothing should page, and the Connection shows Ticket … arrived and was not paged, with the reason.
If you turned on Let recipients open a ticket on a flow, trigger that flow and choose Create Freshservice ticket on the call. A new ticket should open with your instructions at the top, the private note naming you, and the log attached if you asked for it. The alert stops paging.

Troubleshooting

Nothing pages, and the Connection says no ticket has paged yet. Check Workflow 1 is active, its Callback URL matches the Connection's webhook URL exactly, and the test ticket meets its conditions. Freshservice's workflow execution log shows whether the webhook step ran and what we answered.

The Connection says a ticket "arrived and was not paged". The workflow is working; the ticket did not match the Connection's filter. The reason is shown. Widen the filter, or add the matching condition to Workflow 1 so those tickets are not sent at all.

Test connection: "Freshservice refused the API key." The key was not copied in full. Copy it again from the Integration User (Step 1).

Test connection: "The API key works, but its user cannot see tickets." Give the Integration User the IT Agent role and add it to your tickets' workspace (Step 1).

Acknowledge works but Resolve fails. Your ticket form requires a field before resolving (see Resolve refused by Freshservice), or the Integration User's role does not cover that ticket's group.

Paging continues after the ticket was resolved in Freshservice. Workflow 2 is missing or inactive, or its URL differs from the Connection's.

"Set a requester email on the Freshservice connection before opening tickets." Freshservice requires a requester on every ticket. Add one on the Connection (Step 2, item 5).

A ticket opened from an alert has no log attached. Check Attach the alert's log to the ticket is ticked on the flow, and that the alert actually had a log: a JAMS Scheduler job failure does, a plain email or manual alert may not. A file over 5 MB that isn't text is skipped rather than cut short.

The "Create Freshservice ticket" option doesn't appear on an alert. The flow must have Let recipients open a ticket from this alert on, with Freshservice and a Connection chosen, and the Connection must still exist under that name. Alerts that come from an incident source (Azure Monitor, or a Freshservice ticket itself) don't offer it.

The workflow's webhook step shows an error after the Connection was deleted. Deleting a Connection retires its webhook URL. Point the workflows at another Connection's URL, or deactivate them.