When a site goes dark, SmartTile opens one Freshservice incident for it — with your impact, urgency, category and workspace, the customer, site, circuit and carrier already in the body — and keeps it current until the site is back.
A service desk that runs on Freshservice should not need a second screen to learn a site is down. ServiceAutomate connects SmartTile to your own Freshservice — per company, with your own API key — so the incident your agents work is the one SmartTile opened, already categorised and routed the way your ITIL process expects.
| The moment | Today | With ServiceAutomate |
|---|---|---|
| A site loses its circuit | An alert e-mail, then someone raises an incident and types the site, circuit and carrier from memory. | One incident opens when SmartTile opens the SmartChoice ticket for that site — Impact, Urgency, Source, Category, Sub-category, Item, Workspace, group and agent as you set them, plus a table: customer, location, device, circuit, carrier, carrier ticket, outage start. |
| More devices drop | A ticket per device — twelve incidents for one outage. | Devices that fail later at the same site are added to the same incident as a note. No second incident for one outage. |
| It comes back | Someone notices, checks, resolves. | A private RESTORED note with the time, the duration and the circuit. SmartTile resolves it only if you turn Resolve automatically on — off by default. |
| It drops again tomorrow | A fresh incident, history lost. | Within 48 hours the previous incident is re-opened (after checking it is not still open on your side) — your Ticket Flow policy decides reopen, note or new. |
| An agent writes a note | The carrier-facing NOC never sees it. | Every 5 minutes SmartTile reads the incident's conversations and carries each new human note to the SmartChoice ticket, marked and carried once. |
Your domain (the "acme" in acme.freshservice.com) and an API key from avatar → Profile settings → Your API Key. Each field has ⓘ help saying where to find it.
One named check per permission: authentication, tickets readable, groups readable, ticket fields readable, and that your requester e-mail exists — so a failure says exactly what is missing.
Groups, agents, categories and every ticket field (custom ones included) are read from your account, so the form offers your names. Set up my workflow fills sensible defaults for anything you left blank.
Open a test ticket shows the real result with your saved workflow. Send tickets here is the per-company on switch; Stop sending tickets here turns it off without deleting anything.
Type: Incident · Source: Portal · Impact / Urgency: Medium / Medium
Location: Head Office — 123 Example St · Device: FG-60F Head Office
Circuit: CKT-000123 · Carrier ticket: 0987654 · Outage started: 06:14
SmartChoice ticket: Rev.IO #83421 · links: open the device / location in SmartTile
Ticket type, Source, Impact and Urgency from lists; Category from your own category tree; Sub-category and Item exactly as spelled; Workspace for MSP accounts. A blank is never sent, so your Freshservice defaults still apply.
A JSON map from your custom field names to SmartTile values — {device_name}, {circuit_id}, {carrier_ticket}, {location_name} and more — rendered per incident. Empty values are skipped.
Priority for a device DOWN (High by default), the status we open in, the status we resolve to, and a tag (smarttile) on every incident so you can filter them.
SmartTile and CarrierAutomate updates go on as private notes (switchable). Agent notes on the incident are read back and carried to the SmartChoice ticket and your other connected ITSM systems.
/agents · /groupsTest connection and the routing lists/ticket_form_fieldsCategories and custom fields/requesters?email=…Confirm the requester exists/ticketsOpen the incident/tickets/{id}/notesPrivate notes: join, restore, carried notes/tickets/{id}/conversationsRead notes back (every 5 min)/tickets/{id}Is the previous incident still open?/tickets/{id}Re-open, or resolve (only if switched on)/groups · /requestersOnly if you allow provisioning (off by default)Each company connects its own Freshservice. The API key is encrypted at rest against that company and shown back only as ••••••••. Only admins of the company or its reseller can change it.
SmartTile writes tickets and notes, nothing else. Let SmartTile create what it needs (off by default) allows exactly two things: a group and the requester contact.
Per company: Send tickets here / Stop. Fleet-wide: the Freshservice / Freshdesk engine switch in Engine Safety stops every Freshworks call without a redeploy.
Every incident opened and every note carried in is a row in the Automation Audit Ledger, tenant-scoped. The ServiceAutomate Lab runs create → note → read-back → close against your account, even before the switch is on.
| Objection | Answer |
|---|---|
| “We resolve our own tickets.” | That is the default. SmartTile posts the restoration note and leaves the incident open until you switch auto-resolve on. |
| “A site outage will flood the queue.” | One incident per site; later devices join it as a note; a repeat inside 48 h re-opens the last one. |
| “We run workspaces for our clients.” | Set the workspace id and incidents route to that client's workspace. |
| “Our categories are custom.” | They are read from your own account — SmartTile never guesses them. |