Service desks: ServiceNow, Zendesk and Jira

How to connect ServiceNow, Zendesk and Jira Cloud. People read with their own logins and, if an admin turns it on, make single-record changes after confirming them.

Status: in testing. All three are built against each vendor's published API and covered by automated tests against simulated systems; none has been used with a customer's live instance yet. Menu names move between releases: if a step doesn't match what you see, look for the nearest equivalent.

Each person signs in with their own login, so ServiceNow, Zendesk and Jira only show and allow what that person could see and do there anyway. SourceLace never uses a shared admin account.

The redirect URL for all three is:

https://sourcelace.onrender.com/connect/callback

ServiceNow

ServiceNow lives at your own address (such as corvanta.service-now.com), so your ServiceNow admin registers SourceLace once in your instance, which gives a Client ID. That ID is not a secret. SourceLace registers as a public client that proves each sign-in with PKCE, so no client secret is created, sent or stored.

Register SourceLace (ServiceNow admin)

1. Open All (top left), type Application Registry, and open System OAuth → Application Registry.
2. Click New, then Create an OAuth API endpoint for external clients.
3. Fill in:
   • Name: SourceLace.
   • Redirect URL: the redirect URL above.
   • Public Client: tick it. This means "no client secret"; ServiceNow then requires PKCE, which SourceLace always uses. If your release has no Public Client box, this connector cannot be used on it yet; tell support the release name.
   • PKCE Required: tick it if the box is there.
   • Leave Access Token Lifespan (30 minutes) and Refresh Token Lifespan (100 days) as they are. People connect again when the refresh token runs out.
4. Click Submit, open the new entry again, and copy the Client ID.

Add the source (SourceLace admin)

Kind: ServiceNow (servicenow).

To allow changes, turn on Allow changes and list the tables, such as incident, change_request.

What people need in ServiceNow

• Read access to the tables they ask about (for example the itil role for incidents). ServiceNow's ACLs decide everything.
• Listing fields uses the data dictionary (sys_db_object, sys_dictionary, sys_choice). If someone cannot read those, SourceLace falls back to the fields of one record they can see.

Queries

query (language servicenow_query) takes one JSON object with table, query, fields, display_value and limit:

{"table": "incident", "query": "active=true^priority=1^ORDERBYDESCopened_at",
 "fields": ["number", "short_description", "state", "assigned_to"], "limit": 50}

query is ServiceNow's own encoded query, the same text a list's filter gives with Copy query. SourceLace refuses tables that hold the instance's own credentials (such as oauth_credential, or anything ending in _credentials), and refuses javascript: in queries, because it would run script on the instance.

Zendesk

Zendesk also lives at your own address (such as corvanta.zendesk.com), so your Zendesk admin creates an OAuth client for SourceLace. It is a public client: no secret, PKCE on every sign-in.

Create the OAuth client (Zendesk admin)

1. Open Admin Center (the four-squares menu → Admin Center).
2. Go to Apps and integrations → APIs → OAuth Clients (on some accounts: Zendesk API → OAuth Clients) and click Add OAuth client.
3. Fill in:
   • Name: SourceLace. Description: "Read and update tickets as the signed-in person".
   • Client kind: Public.
   • Redirect URLs: the redirect URL above.
   • Identifier: keep the suggested one or type sourcelace. Copy it.
4. Click Save. If Zendesk shows a secret anyway, you don't need it; don't paste it anywhere.

Add the source (SourceLace admin)

Kind: Zendesk (zendesk).

Sign-in asks for the scope read, plus tickets:write when an admin has made tickets writable. After turning changes on or off, people connect Zendesk again so their sign-in matches.

Queries and changes

• query (language zendesk_search) takes Zendesk's own search text, such as type:ticket status:open priority:urgent order_by:created sort:desc. Start with type:ticket, type:user or type:organization so every row has the same columns. One line, at most 1,000 characters. Zendesk returns at most 1,000 results per search, and new tickets can take a minute to appear in search.
• get_record on a ticket can add its comments.
• With tickets writable, changes can set subject, status, priority, type, assignee_id, group_id, requester_id, organization_id, tags, due_at, external_id and custom_field_<id>, and add either a public reply (comment) or a private note (internal_note). Updates use Zendesk's "safe update", so they are refused if someone else changed the ticket since the preview.

Jira Cloud

Jira Cloud sign-in goes through Atlassian's central login, so SourceLace has one Atlassian app. After someone signs in, SourceLace asks Atlassian which Jira sites their sign-in reaches and uses the one named in the source's site option. Your Jira admin has nothing to register, unless your Atlassian organization restricts which apps people may approve.

Permissions SourceLace asks for: read:jira-work (read projects and issues), read:jira-user (read people's names) and offline_access (stay connected), plus write:jira-work (create and edit issues and comments) only on sources where an admin made issue writable.

Add the source (SourceLace admin)

Kind: Jira Cloud (jira).

To allow changes, turn on Allow changes with the object issue. After turning changes on or off, people connect Jira again.

Each person clicks Connect, signs in with their Atlassian account, and approves the site on Atlassian's consent page.

Queries and changes

• query (language jql) takes plain JQL, such as project = CORV AND statusCategory != Done ORDER BY updated DESC, or JSON to choose the columns: {"jql": "project = CORV", "fields": ["summary", "status", "customfield_10010"]}. Jira needs at least one condition before ORDER BY.
• get_record on an issue can add comments and changelog.
• With issue writable: create an issue, update its fields, or add a comment. Descriptions and comments are sent as Jira's rich text, built from plain lines. Status changes and deletes are not offered.

When something goes wrong