Skip to main content
Flow ticketing integrations sync incidents and service requests with external systems through explicit ticket links: Flow does not silently mirror an entire external queue. Each sync source binds a team inbox to a provider scope, such as a Jira service desk and request type or a ServiceNow table and query pair. Ticket state in Flow is the source of truth for linked records. Provider APIs supply supporting evidence for sync.

​
Capabilities

  • Org-level connected accounts with team-scoped source scopes
  • Polling-based import with per-source schedules
  • Outbound create when Flow originates the ticket
  • Field mapping for provider-required outbound fields
  • Separate Opened by and Requester identity where the provider models both
  • Ordered text cleanup on Subject and Description
  • Status and priority translation with per-value outbound defaults
  • Read-only imported request form on tickets that came from a provider request form
  • Conflict policies for concurrent edits
  • Provider throttle pause tracking
  • Provider context on operator ticket detail when a provider exposes safe, source-scoped references

​
Configuration

Ticketing is configured per team under Integrations, filtered to Ticketing. No global setup variables are required.

​
Set up Ticket Sync

1

Connect Jira or ServiceNow from Integrations at the org level.

2

Create a source scope with a service desk and request type, or a table and query scope.

3

Map identity, text cleanup, status, and priority on the source tabs.

4

Enable polling and verify the readiness panel.

​
Source tabs

A source has the same tabs on both providers. Setup and later edits use the same editors, so nothing you configure during setup moves somewhere else afterwards.

​
Who filed it and who it is for

Flow keeps two people on a ticket when the provider models both:
  • Opened by is the person who filed the request.
  • Requester is the person the request is for.
For example, an office manager files a monitor request for a new hire. On a Jira source or a ServiceNow request-item source, Flow shows the office manager under Opened by and the new hire under Requester. On a ServiceNow incident, a service-desk agent who opens a virtual private network (VPN) outage for an employee stays under Opened by, and the employee stays under Requester. The destination Flow type of a source (incident or request) only chooses the Flow ticket type. It does not add or remove identity rows.

​
Imported request form

When a provider record came from a request form, Flow copies the answers onto the ticket as a read-only Imported request form. The copy keeps fields, nested sections, and multi-row table answers in their original shape. ServiceNow request items and Jira customer requests both fill it. Flow displays the copy and refreshes it while polling. It does not create a Flow catalog item from the import, and it does not write answers back to the provider.

​
Status and priority translation

Both providers use the same two mapping tabs.
  • Incoming tickets accept every provider value you list under a Flow state or priority.
  • When one Flow value lists more than one provider value, one of them is the outbound default that Flow writes back.
  • On an existing linked ticket, a provider value you never listed keeps the current Flow priority. A first-time import with an unlisted priority starts at Normal. Later syncs do not treat that create default as a mapped translation.
ServiceNow uses numeric codes for both state and priority. Jira uses status and priority names.

​
Scopes and permissions

See Jira Service Management and ServiceNow ticketing for provider-specific access and instance ACLs. Provider scopes should be narrow enough for a team inbox. ServiceNow sources can target incidents, request items, or approved custom task tables, but related records and ServiceNow context are display-only support data. Request-item catalog answers are copied onto the Flow ticket as a read-only form. Flow does not run full CMDB, catalog authoring, or whole-instance ServiceNow synchronization through ticketing. Provider context is visible to operators and team members on linked ticket detail when available. Requester-safe views redact provider URLs, related provider identifiers, diagnostics, and provider context. Polling progress, retries, and throttling are source-scoped. If a provider returns a throttle response, Flow records a provider pause and resumes after the retry window instead of continuing to call that provider immediately.