> ## Documentation Index > Fetch the complete documentation index at: https://docs.useparagon.com/llms.txt > Use this file to discover all available pages before exploring further. # Workflow runs twice from one App Event or integration trigger > Multi-Configuration runs a workflow once per configuration that has it enabled. How to target a single one. Breadcrumb If one App Event or integration event produces two (or N) workflow executions with identical payloads, this article explains why and how to stop it. The usual cause is [Multi-Configuration](https://docs.useparagon.com/apis/api-reference/multi-configuration.md): Paragon runs the workflow once for every configuration that has it enabled. Jump to [Fix](#fix). ## Symptoms * Task History shows two or more executions of the same workflow a few seconds apart. * The payloads are identical, including any primary key or record id your app sent. * Your application logs show a single `POST` to the App Event endpoint, or a single event from the integration. * The Connected User has more than one configuration (or more than one connected account) for that integration, and the workflow is enabled on more than one of them. You will not see an error. Each extra run succeeds. ## Cause App Events are one-to-many. One event can start every matching workflow for that Connected User. With Multi-Configuration, "matching" includes every configuration on the credential that has the workflow enabled. So if a user has three configurations, and two of them have "Create issue" enabled, one App Event produces two executions. The payloads look the same because they are the same event, applied to two configurations. The same fan-out applies to **Integration Triggers**. An "Issue Updated" (or similar) event from the provider is delivered to every configuration that has that workflow enabled. You cannot attach targeting headers to an inbound provider webhook. This is expected platform behavior. It is not a retry and not a duplicate `POST` from your app. | Trigger | Untargeted behavior | Can you target one configuration on the request? | | - | - | - | | App Event | Runs once per configuration (and credential) that has a matching workflow enabled | Yes. Send `X-Paragon-Credential` and `X-Paragon-Configuration-Id` (see [How to send an App Event to a single configuration](https://docs.useparagon.com/knowledge-base/app-event-single-configuration.md)). | | Integration Trigger | Runs once per configuration that has the workflow enabled | No. Filter inside the workflow, or enable the workflow on only one configuration. | | Request Trigger | Addresses one workflow | Use `X-Paragon-Credential` / `selectedCredentialId` when the user has multiple accounts. | ## Fix ### App Events: target one configuration Send the event to a single configuration. Pass both headers on `POST /projects//sdk/events/trigger`: * `X-Paragon-Credential`: the connected-account UUID * `X-Paragon-Configuration-Id`: the configuration UUID, or `ext:` plus the external ID you assigned when creating the configuration A successful targeted event returns `201`. Sending only `X-Paragon-Configuration-Id` can return `400 Bad Request`. Full steps, including how to read both IDs from `GET /sdk/me` or `paragon.getUser()`, are in [How to send an App Event to a single configuration](https://docs.useparagon.com/knowledge-base/app-event-single-configuration.md). ### Integration Triggers: you cannot target the inbound event The provider calls Paragon. There is no place to set `X-Paragon-Configuration-Id`. Use one of the following, or combine them. **Enable the workflow on only one configuration.** Leave it disabled on the others. You can do this in the Connect Portal for that configuration, or with `paragon.enableWorkflow` / `paragon.disableWorkflow` and `selectedConfigurationId` ([Multi-Configuration](https://docs.useparagon.com/apis/api-reference/multi-configuration.md)). **Give each configuration a required User Setting that uniquely identifies it**, then use that setting in the workflow so only the matching configuration proceeds. Examples: a project key, issue type, folder, or assignee. Add the setting under **Customize Connect Portal > Configuration**, mark it required, and reference it from a Conditional step or from the trigger's own filters (for example a JQL query that includes `{{settings.project}}`). See [User Settings](https://docs.useparagon.com/connect-portal/workflow-user-settings). **Make the workflow idempotent.** Before creating or updating a record in your app, check whether that provider record was already synced. Extra executions then become no-ops. Untargeted duplication is the default. Multi-Configuration is for cases where each configuration *should* run with its own settings (different folders, projects, or teams), or where you have already constrained the trigger so each configuration only matches its own events. ## Prevention * When you send App Events, always include both targeting headers if the user can have more than one configuration. * Do not enable the same unfiltered Integration Trigger workflow on every configuration unless you want one execution per configuration. * Prefer User Settings that make each configuration's trigger unique (project, issue type, folder, channel) over relying on users to avoid "duplicate" configurations. * If you also use [Multi-Account Authorization](https://docs.useparagon.com/apis/api-reference/multi-account-authorization.md), one event can run once per connected account as well. Pass `X-Paragon-Credential` (and a configuration ID when you use Multi-Configuration) instead of leaving the event untargeted. ## Still having issues? Send support: * The workflow Task History IDs for the duplicate runs, and the time gap between them * Whether the trigger is an App Event or an Integration Trigger * How many configurations (and connected accounts) the user has, and which of them have the workflow enabled * For App Events: the request URL, whether you sent `X-Paragon-Credential` and `X-Paragon-Configuration-Id`, and the exact header values (configuration UUID vs `ext:` + external ID) * For `400` on the App Event endpoint: the response body, and whether the same request succeeds with those headers removed ## Related articles * [How to send an App Event to a single configuration](https://docs.useparagon.com/knowledge-base/app-event-single-configuration.md) * [Multi-Configuration](https://docs.useparagon.com/apis/api-reference/multi-configuration.md) * [App Events](https://docs.useparagon.com/workflows/triggers/app-events.md) * [Integration Triggers](https://docs.useparagon.com/workflows/triggers/integration-trigger.md) * [User Settings](https://docs.useparagon.com/connect-portal/workflow-user-settings) * [Multi-Account Authorization](https://docs.useparagon.com/apis/api-reference/multi-account-authorization.md)