Campaign Quality GateAutomation Architecture
A three-layer automated intelligence system embedded into the existing Jira campaign pipeline, designed to eliminate the structural conditions that allow campaign errors to reach customers.
What this architecture actually solves
This is not an incremental improvement to the existing QA process. It is a structural intervention that relocates the point of error detection from after send to before build begins, eliminating the conditions that allow errors to reach the pipeline at all.
Errors are not discovered late because QA is inadequate. They originate at brief ambiguity and segment misconfiguration, upstream of where current controls operate. This architecture intervenes at origin.
Every gate triggers from Jira status transitions your team already performs. There are no new tools, no new steps, no training requirements. The intelligence is embedded invisibly into the existing workflow.
The 75-point checklist was a human judgment exercise. These gates convert that judgment into deterministic machine verification, applied consistently at every campaign, regardless of operator experience or workload pressure.
The operational environmentthat created the problem
Understanding why a 30-person team with a 75-point checklist and dedicated QA resources still operates at a 30% error rate requires looking at the structural dynamics, not the individual performance.
Campaign briefs enter as Jira tickets. Builders interpret them. Builds are reviewed against a 75-point manual checklist. QA approvers validate. Campaigns send. Errors surface post-send, from customers, stakeholders, or compliance teams.
The instinct to add more QA resource is logical but misapplied. Three structural dynamics explain why:
Based on the diagnostic conducted across this team's campaign operations, three error origin categories account for the majority of post-send failures:
Review Operational Architecture
Walk through the current-state pipeline, bottleneck mapping, and structural diagnosis with a transformation strategist.
Three intelligent quality gatesembedded in your Jira pipeline
Each gate is an n8n AI agent workflow triggered by a Jira status transition. The agent reads the issue context, performs its validation using connected APIs, and takes autonomous action, updating Jira, notifying the relevant team in Slack, and blocking or approving progression.
Fires when a campaign brief is submitted. Validates all 12 required fields before any builder sees the ticket. Eliminates the root cause of misinterpretation errors.
Fires when a campaign build is marked complete. Calls SFMC and SAS APIs to validate actual audience count against the expected range declared in the brief. Catches wrong-audience errors before QA.
Fires after QA approval. Validates the live SFMC build against the approved brief, content IDs, personalisation tokens, send configuration, compliance elements. Last automated barrier before send.
Explore Deployment Feasibility
Understand the infrastructure requirements, credential setup, and estimated deployment timeline for your environment.
What each agent validatesand exactly how it decides
Each gate operates on a defined decision ruleset embedded in its AI agent system prompt. The logic is deterministic, specific criteria must be satisfied for a pass outcome. There is no subjective interpretation.
The agent reads the entire Jira issue, all fields, description, and custom brief fields. It evaluates each of the 12 required brief elements against defined acceptance criteria. A partial pass is a full fail, all 12 must satisfy the criteria before the brief is approved to build.
Re-setting status to "Brief Submitted" after correction re-triggers Gate 1 automatically. The loop closes cleanly.
The agent reads the approved brief's expected audience range, then makes live API calls to SFMC or SAS to retrieve the actual segment count. It compares actual vs expected and flags anomalies that would not be visible from a visual review of the build.
The final gate. The agent retrieves the live SFMC content asset and send definition, then cross-references them against the approved brief. 16+ checks across content, audience configuration, and compliance.
API failure (unable to retrieve live content) auto-triggers a fail with escalation note. The campaign cannot proceed without validated content.
Review Validation Logic
The 12-field brief criteria and 16-point pre-send checklist can be customised to match your specific brief schema and regulatory obligations.
How data and decisionsmove through the architecture
Each workflow follows an identical structural pattern: Jira webhook trigger → status filter → AI agent with tool access → dual output path (success / error recovery). This consistency makes the system predictable, auditable, and maintainable.
| Node | Type | Function |
|---|---|---|
| Jira Trigger | jiraTrigger | Webhook, fires on any Jira issue update |
| Status Filter | if (v2.2) | Passes only if status = "Brief Submitted" |
| Brief Validation Agent | langchain.agent | Claude Sonnet · 12-field validation logic |
| Add Jira Comment | jiraTool | Posts validation result to issue |
| Transition Jira Issue | jiraTool | Moves to pass or fail status |
| Slack Notify Team | slackTool | Alerts builder or requester |
| Response / Error | set (x2) | Output + error recovery nodes |
| Node | Type | Function |
|---|---|---|
| Jira Trigger | jiraTrigger | Webhook, fires on any issue update |
| Status Filter | if (v2.2) | Passes only if status = "QA Approved" |
| Pre-Send QA Agent | langchain.agent | Claude Sonnet · 16-point validation |
| SFMC Content API | toolHttpRequest | Retrieves live email content asset |
| SFMC Send Definition | toolHttpRequest | Retrieves send config and audience |
| Add Jira Comment | jiraTool | Posts full QA report to issue |
| Transition Jira Issue | jiraTool | Approves or blocks campaign |
| Slack Alert | slackTool | Urgent alert on fail, confirmation on pass |
| Send QA Email | gmailTool | Full report to campaign owner |
The before and afterof campaign operations
This architecture does not change how your team works. It changes the structural conditions under which errors can propagate, by converting human-dependent judgment points into machine-verified checkpoints.
Evaluate Workflow Integration
Understand how this architecture maps to your current Jira project structure, status workflow, and team operating model.
Who this affectsand how their working experience changes
Every role in the campaign operations chain is impacted, but in most cases, the change is invisible from a workflow perspective. The intelligence is embedded; the team simply operates in a validated environment.
Explore Department Impact Mapping
A detailed stakeholder impact assessment can be produced for your specific org structure before deployment begins.
Platform relationshipsand data movement
This architecture sits between your existing platforms as an intelligence orchestration layer. It reads from them, validates against them, and writes back decisions, without requiring changes to any platform configuration.
| Data Type | From | To | Used For | Gate |
|---|---|---|---|---|
| Jira issue payload | Jira webhook | n8n → AI Agent | Context for all validation decisions | All |
| Brief field values | Jira custom fields | AI Agent working memory | Validation source of truth | G1, G2, G3 |
| Validation decision | AI Agent output | Jira Comment | Audit trail and team communication | All |
| Status transition command | AI Agent | Jira API (Transition) | Pipeline progression or blockage | All |
| SFMC audience count | SFMC REST API | AI Agent | Segment size validation | G2 |
| SAS audience count | SAS API | AI Agent | Segment size validation (SAS campaigns) | G2 |
| SFMC content asset | SFMC Content Builder API | AI Agent | Subject, tokens, links, content ID check | G3 |
| SFMC send definition | SFMC Send Definition API | AI Agent | Audience, timing, suppression check | G3 |
| QA report | AI Agent output | Gmail → Campaign Owner | Audit trail, ownership confirmation | G3 |
| Slack alert | AI Agent | Slack channel | Human notification, escalation trigger | All |
Review Operational Architecture
A technical architecture review can validate the integration approach against your specific platform versions, API permissions, and data governance requirements.
Translating automation into commercial value
The metrics that matter to leadership are not technical, they are operational, financial, and reputational. Here is how the architecture translates into the measures that appear in executive reporting.
Each prevented error eliminates a chain of downstream costs: the rework labour, the delayed campaign window, the customer compensation event, the stakeholder escalation, the compliance reporting obligation if applicable, and the reputational impact on the team's credibility with the broader business. At 100–200 campaigns per month with a 30% error rate, the operational drag from this chain is substantial, and it compounds with volume. This architecture removes that compounding drag at its structural origin.
From download tooperational quality gates
This architecture is deployable without infrastructure changes, platform migrations, or team training. The implementation sequence below takes you from credential setup to live gate activation in a structured, low-risk progression.
- Download all 3 workflow JSON files and setup guide
- Provision n8n instance (v1.40+)
- Configure Anthropic API credential in n8n
- Configure Jira Software Cloud credential
- Configure Slack OAuth2 credential
- Configure Gmail OAuth2 credential
- Import all 3 workflow JSON files into n8n
- Verify/create required Jira statuses (9 statuses)
- Update IF node status values to match your Jira statuses
- Configure SFMC Installed Package (Client ID + Secret)
- Set SFMC subdomain placeholder in Gate 2 + Gate 3
- Map Jira custom field IDs to Gate 1 validation criteria
- Activate all 3 workflows + copy webhook URLs
- Configure 3 Jira webhooks (one per workflow)
- Configure Slack channel routing in each workflow
- Run Gate 1 test, fail case (incomplete brief)
- Run Gate 1 test, pass case (complete brief)
- Run Gate 2 test, count anomaly case
- Run Gate 3 test, send block case
- Communicate activation to campaign team
Schedule Transformation Consultation
A guided implementation session can take you from credential setup to live gate activation in a structured half-day engagement.
Ready-to-useconfiguration references
Key configuration references from the generated workflow package. These are production-ready, the validation criteria, API endpoint patterns, and Jira status mappings used directly in the workflow JSON files.
// Required Jira statuses, create these in your Jira project // Project Settings → Workflows → Edit → Add Status "pipeline_statuses": [ { "name": "Brief Submitted", "triggers": "Gate 1" }, { "name": "Brief Required", "type": "Gate 1 fail destination" }, { "name": "Ready for Build", "type": "Gate 1 pass destination" }, { "name": "Build Complete", "triggers": "Gate 2" }, { "name": "Build Required", "type": "Gate 2 fail destination" }, { "name": "Ready for QA", "type": "Gate 2 pass destination" }, { "name": "QA Approved", "triggers": "Gate 3" }, { "name": "QA Failed, Rework Required", "type": "Gate 3 fail destination" }, { "name": "Approved to Send", "type": "Gate 3 pass destination" } ]
// Gate 2, Audience Count (Data Extension) GET https://{sfmcSubdomain}.rest.marketingcloudapis.com/data/v1/customobjectdata/key/{dataExtensionKey}/rowset?$pageSize=1 // Gate 2, SAS Campaign Audience Count GET https://{sasHost}/SASCampaign/rest/v1/campaigns/{campaignId}/communications/{communicationId}/audienceCount // Gate 3, Content Asset Validation GET https://{sfmcSubdomain}.rest.marketingcloudapis.com/asset/v1/content/assets/{assetId} // Gate 3, Send Definition Check GET https://{sfmcSubdomain}.rest.marketingcloudapis.com/email/v1/definitions/{sendDefinitionId} // SFMC OAuth2 Token (run before API calls) POST https://{sfmcSubdomain}.auth.marketingcloudapis.com/v2/token Body: { "grant_type": "client_credentials", "client_id": "{clientId}", "client_secret": "{clientSecret}" }
BRIEF VALIDATION FAILED, 2024-03-15 09:42 AEST 3 fields require correction before build can begin: Target Segment Criteria: Found: "active customers who have purchased recently" Required: Specific, filterable criteria, e.g. "opted-in email subscribers with a purchase in the last 90 days, excluding lapsed segment" Suppression Groups Required: Found: "standard suppression" Required: Named suppression lists, e.g. "Unsubscribes_Master, Complaints_2024, DNC_Financial" Stakeholder Approval: Found: "approved by marketing team" Required: Named approver and approval date, e.g. "Approved by Sarah Chen, 2024-03-14" Once corrected, change status back to 'Brief Submitted' to re-trigger validation. Do not ask the build team to start work until this is resolved.
// Call this to retrieve all custom field IDs in your Jira instance // Replace {domain} with your Jira domain (e.g. your-company.atlassian.net) GET https://{domain}/rest/api/3/field Authorization: Basic {base64(email:api_token)} Accept: application/json // Response, look for entries where "id" starts with "customfield_" // Map these IDs to your brief field names in the Gate 1 system prompt { "id": "customfield_10001", "name": "Expected Audience Min", "type": "number" }
Four files have been generated and are ready for download and deployment:
Import each JSON file via n8n → Workflows → Import. Follow the setup guide for the complete credential and configuration sequence.
Begin Implementation
All workflow files are ready. The setup guide walks through every configuration step. A guided deployment session is available if preferred.