Skip to main content

How to Combine Connector Projects

What has to match (Organizational Unit, CI tag, source language) for multiple connector pulls to land in the same continuous project instead of creating a new one, and how each connector's CI tag is set.

A continuous (connector) project in wxrks is one that's fed by an integration — Eloqua, WordPress, GitHub, or Pendo — instead of a one-time file upload. This article explains how multiple pulls from the same connector end up combined into a single wxrks project instead of creating a new one every time, what has to match for that to happen, and where each connector's identifying tag comes from.

💡 Who is this for? This guide is for Account Admin, the role that configures connectors and reviews continuous project setup in wxrks.


This article assumes you already know how to create a connector project. See Using the wxrks Connectors Interface for that walkthrough first.


How combining actually works

Every connector pull is identified by a CI tag — a single text identifier tied to one Organizational Unit. When wxrks receives a new pull request, it looks for an existing continuous project in that same Organizational Unit with that same CI tag. If one exists, the new files and languages are added into it. If none exists, a brand-new project is created and that CI tag becomes its identifier going forward.

Two things also have to match for that reuse to happen: the project's source language (a mismatched source language fails the request outright), and the file itself — if the exact same file content was already pulled for a given target language, it's skipped rather than re-sent.

There's one more wrinkle worth knowing about: depending on how your Organizational Unit is configured, a newly created continuous project can start life in one of two states:

  • Most Organizational Units create new continuous projects already sealed — later pulls with the same CI tag reconcile directly into the existing project's files.

  • Some older Organizational Units still use the previous behavior, where a new continuous project starts in Draft status and only seals once it moves past Draft. Further pulls with the same CI tag land in that Draft project as long as it stays in Draft.

Either way, the combining logic is the same — same Organizational Unit, same CI tag, same source language. The Draft window described in the rest of this article applies specifically to Organizational Units still on that older behavior.

Projects list showing a project with DRAFT status alongside PENDING and APPROVED projects

Requirements to combine into the same project

For a new pull to land in an existing continuous project instead of creating a new one, it needs to match on all of the following:

  • Same connector and same CI tag — this is the actual matching key. Two pulls with different CI tags will always create two separate projects, even if everything else about them is identical.

  • Same Organizational Unit — a CI tag is only unique within one Organizational Unit, not across your whole account.

  • Same source language — a pull with a different source language than the existing project's is rejected, not merged.

  • Only one file or ID per target language per pull — you can't submit the same file and target language combination twice in one request. A file that's genuinely unchanged since the last pull is skipped automatically; a file with new target languages added gets new work for just those languages.

Beyond the CI tag, you can also attach ordinary descriptive tags to a project (visible in the connector's Entries view). These are informational labels, not part of the matching logic — new tags from later pulls are simply added to whatever tags the project already has.


Where each connector's tag comes from

Because the CI tag is what actually drives combining, how it's set differs by connector — and it's worth understanding before assuming two pulls will land in the same project:

  • GitHub — the CI tag is set once on the Repository Configuration itself and stays fixed. Every manual sync run against that same Repository Configuration reuses the same tag, so it combines automatically with no extra setup. See wxrks - GitHub Connector for where that field lives.

  • Pendo — defaults to the fixed tag pendo. Pulls combine automatically unless you deliberately set a different ciTag on a request. See wxrks - Pendo Connector for the full setup.

  • Eloqua and WordPress — if you don't supply a ciTag explicitly, wxrks generates one for you that includes a timestamp, which makes it unique to that one call. In practice this means two separate sync requests won't land in the same project unless you (or whoever is calling the API) explicitly pass the same ciTag value on both. If you're combining Eloqua or WordPress pulls, treat the CI tag as something you set deliberately, not something that "just works" by pulling around the same time.

See wxrks - Eloqua Connector and wxrks - WordPress Connector for the full parameter list, including ciTag.

Connector Entries tab showing the Tag and Entry Status filter fields

[SCREENSHOT PLACEHOLDER: an Entries table row with a completed/DONE-status entry sharing a Tag with other combined rows] — the devops sandbox account used for this rebuild had no completed connector entries at capture time to show a populated example.


Creating a combined pull

There's no separate "combine" action in wxrks — you create a connector pull exactly the way you normally would, and it either joins an existing project or starts a new one based on the CI tag rules above. For the actual creation steps:


Related articles

Did this answer your question?