Skip to content
Flexday AI Docs
Sign in with GitHub

Use cases › Service Desk Copilot

Build and operate

How Harbourline builds the Service Desk Copilot with the Builder, configures what needs a person, goes live, and runs it day to day.

Written for
  • Everyone
  • Technical

Last reviewed

Harbourline builds most of the Service Desk Copilot by describing it to the Builder. People then do the parts that need a person: credentials, sign-in, the ServiceNow side, testing and going live. After that, running it is mostly watching the numbers.

At a glance

PhaseWhoRoughly
Build by conversationA builder with a sample exportA few Builder turns
Configure credentials and sign-inA builder with the ServiceNow and identity teamsDepends on your change process
Test and go liveThe builder, a Teams administrator, the service desk leadA short pilot
OperateThe service desk lead and the Solution's ManagersOngoing

1. Build by conversation

On the Studio home page, the builder attaches a sample incident export (CSV) and a few knowledge articles, and writes:

Build a service desk copilot for Harbourline's IT team.

Data: load the attached incident export as a Fact Base with incidents, incident events and sites. Incidents are keyed by the ServiceNow sys_id. Add saved queries for open incidents by priority, SLA at risk, incidents by site and the status of one incident by number, plus a write query that inserts or updates an incident, and one that adds an incident event.

App: a dashboard for IT staff with those three views, a site map, recent changes and a chat panel.

Knowledge: a Doc Base from the attached articles.

Agent: a service desk assistant that answers from the Doc Base first, with sources, looks up an incident by number, and runs a Flow to raise a ticket after collecting email, site, device and what was tried. It will answer in Teams, so no forms.

Flows: Ingest incident, Nightly reconcile at 02:00 Europe/London, Raise incident and P1 alert, as described in the attached design notes.

Done when:

  • Every dashboard view shows data from the Fact Base
  • The Agent cites an article when answering a VPN question
  • The Raise incident Flow uses the ServiceNow Create ticket action

The Builder creates the Fact Base, loads the rows, saves the queries, writes the dashboard, creates the Doc Base, the Agent and the Flows, and proposes the Variables it needs for the builder to confirm. Once the dashboard exists, each read query becomes a gateway endpoint as soon as it is saved, and the finish wires any still left. Its finish gate checks the "Done when" list before the turn ends. The builder then refines by chat: "put the site map above the table", "add a filter for priority".

The Builder for the Service Desk Copilot Solution: the request's three attached CSV files and the Builder's reply on the left, and on the right the Service Desk DS Fact Base it created, with its assets, services and incidents tables verified
From the documentation's demo build, which began with a shorter request than the one above: the Builder says what it loaded from the three files, and the Fact Base it made is open beside the conversation.

Tip

Put standing instructions (naming, tone, "never ask for a password") in the Solution's Brief. The Builder reads the Brief on every turn.

2. Configure what needs a person

TaskWhereNotes
ServiceNow ConnectionCredentials → ConnectionsKind Application, ServiceNow, OAuth client credentials; instance address; a duplicate-prevention field. ServiceNow's team creates the OAuth client and a service account that can read and write incidents.
VariablesThe Solution's Variables tabAssignment group, support email, SLA minutes, P1 contacts, and the status page token as a Secret.
Intake gateway and keyExecutors → Flex Gateways and Credentials → IdentitiesA second gateway with one flow endpoint for Ingest incident. An API key Identity: mint the key with New key on its Configuration tab, where it is shown once, then attach the Identity on the gateway's Authentication tab.
ServiceNow business ruleServiceNowAfter insert and update on incidents, call an outbound REST message to the flow endpoint with the X-Api-Key header.
Dashboard sign-inCognito and Credentials → IdentitiesSee Authentication.
Runbook audiencesThe Doc Base's Files viewTag runbooks it-staff; link the knowledge-exports store with automatic indexing.
EvaluationsThe Agent's Evals and Instructions tabsA golden set of VPN, password and ticket-raising cases, marked as the default set. Then switch on Require evals to pass before publishing on the Instructions tab: a publish is refused unless that set's latest run against the draft passed.
BotApps → BotsBound to the Agent. Choose Flexday.ai manages it where your deployment offers managed registration, otherwise Your own Azure registration.

3. Test and go live

  1. Test the Flows. Start a test run of Ingest incident's draft with a sample body through the Studio's API (its Test run button starts one with no input), then read the step trail in the Flow's Runs view. Once the Flows are published (step 3), point a ServiceNow test instance at the intake endpoint before the production one: an endpoint runs the published version, and Integration steps are safest tried against a non-production instance.
  2. Test the Agent. Use the Playground, and its Preview as an end user option (owners and admins) with and without the it-staff tag to check who sees runbooks. Anything that would send or write is refused while previewing.
  3. Publish. Publish the Flows and the Agent; each publish runs its checks and creates a version. Switch on Nightly reconcile so its schedule can fire.
  4. Deploy the dashboard. The first build deployed itself; deploy again after changes.
  5. Go live in Teams. On the Bot's Setup tab, run the credential checks, then choose Go live at the top of the Bot's page. Then have a Teams administrator publish it to your organisation's catalogue with Publish to your org, or by the manual app-package route the tab describes. On-call engineers then add it in Teams, which gives the Bot the conversation with each of them that P1 alerts need.
  6. Pilot. Start with one department and review Agent analytics after a week.
A run of the Ingest incident Flow with its Store the incident step open: succeeded on the first attempt, the input holding the saved query and the incident's fields from the trigger, and the output holding the stored incident's number, state, priority and site
From the demo build's cut-down Ingest incident Flow, started once with a sample incident: the step trail records each step's input and output.

Go-live checklist

  • The ServiceNow Connection has a duplicate-prevention field
  • Every required Variable has a value (Flows cannot be switched on without them)
  • The Harbourline SSO Identity passes Check a credential for a real user
  • Runbooks carry the it-staff tag; public articles carry none
  • The Agent's evaluation set passes on the version being published
  • Nightly reconcile is published and enabled
  • The intake gateway has only the one flow endpoint
  • On-call engineers have a conversation with the Bot

4. Operate

ActivityWhereHow often
Watch costThe Solution's Usage viewMonthly
Review conversations and feedbackThe Agent's Analytics and SessionsWeekly during the pilot, then monthly
Check automation healthEach Flow's Runs and AnalyticsWeekly; the nightly summary email flags problems daily
Check Teams deliveryThe Bot's Deliveries viewAfter any P1
Rotate credentialsThe Connection, the API key Identity, the Secret VariableOn your security team's schedule
Review accessThe Solution's People view; the Identity's MembersQuarterly
A conversation in the Service desk agent's Sessions tab: asked through the API where to borrow a laptop while one is being repaired, the agent answers from the laptops and devices article, with its document search step expanded and the article listed under Sources
Notice the version the conversation is pinned to, v2, the search the Agent ran, and the source it cited.

Changing it safely

  • Ask the Builder for changes. A dashboard change waits in the app's draft until someone deploys it. Flow and Agent changes wait in their drafts until they are published, which the Builder can also do, for example when a button it built needs a published Flow.
  • A new Fact Base column is a schema change. The Builder works out the plan first and is told to describe it in the chat, then applies exactly that plan in one transaction; it does not wait for an approval.
  • Every version is in the resource's Versions view, and the Builder's and other AI work is in History. Who changed a resource is in the workspace's audit trail, which admins read through the platform's API.
  • To give another region the same Copilot, publish it as a Template: the copy arrives with credentials blank and Flows and the Agent unpublished.

When something goes wrong

SymptomLikely causeWhere to look
Dashboard shows old dataPushes failingServiceNow's outbound log; the Ingest incident Flow's Runs; the nightly summary
"Missing API key" from the intake gatewayThe header is missing or misnamed in ServiceNow (a wrong key gets "invalid API key" instead)The outbound REST message's headers
Raise incident fails with a named ServiceNow reasonA mandatory field or permission in ServiceNowThe Flow run's step trail
A Create ticket step stopped "in doubt"The call was cut off and could not be checkedServiceNow, for the ticket; add a duplicate-prevention field if missing
An engineer did not get a P1 messageThey sent STOP, have no conversation, or the hourly allowance was usedThe Bot's Conversations and Deliveries
Dashboard sign-in refused with a rule nameThe person's email domain, or a claim or scope the Identity requires, does not match its rulesCheck a credential on the Identity