> ## Documentation Index > Fetch the complete documentation index at: https://docs.letsflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # Ticketing overview > External ticket sync model, identity on imported requests, and the mapping tabs shared by Jira and ServiceNow. 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. | UI step | Required | Purpose | | - | - | - | | Provider connect | Yes | Jira or ServiceNow authorization: see provider pages | | Source scope | Per team/source | Provider scope, direction, polling schedule, field mappings | | Ticket link | Per ticket | Explicit link between Flow ticket and external record | ## Set up Ticket Sync ## 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. | Tab | What you set | | - | - | | **Sync settings** | Team inbox, sync direction, conflict ownership, default create target | | **Condition filters** | An inbound filter that narrows which provider records are eligible | | **Field mappings** | Subject, Description, Priority, Status, Requester, Opened by, Assignment team, and text cleanup | | **Status mappings** | Provider status values grouped under the six Flow states | | **Priority mappings** | Provider priority values grouped under Urgent, High, Normal, and Low | | **Mapping preview** | A sample provider Title, Status, and Priority run through the saved mapping | ## 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. | Source | Identity rows | Notes | | - | - | - | | Jira customer request | Opened by and Requester | Defaults are creator for Opened by and reporter for Requester. Jira rewrites the reporter to the beneficiary on a raise-on-behalf-of create, so the creator stays the filer | | ServiceNow request item | Opened by and Requester | Defaults are `opened_by` and `requested_for` | | ServiceNow incident | Opened by and Requester | Defaults are `opened_by` and `caller_id` | 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](/integrations/ticketing/jira-service-management) and [ServiceNow ticketing](/integrations/ticketing/servicenow) 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. ## Related topics * [Jira Service Management](/integrations/ticketing/jira-service-management) * [ServiceNow ticketing](/integrations/ticketing/servicenow) * [Help desk](/setup/help-desk) * [Troubleshoot connections and sync](/setup/troubleshooting/connections-and-sync) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.