pl8ypus
Systems / Campaign Copilot

Build 03 / Governed Campaign Orchestration

Campaign Copilot

A governed campaign intake and orchestration layer for enterprise marketing operations. It turns fragmented requests into structured decisions, SFDC campaign creation, Clarevine tracking, DAM image destination URLs, Workfront tickets, design briefs, and VS Code / GitHub Copilot build prompts for the existing Eloqua pipeline.

AI governance review Naming convention Workfront queue DAM handoff Clarevine tracking Build pipeline

Greg's take

I decided to attack myself.

Not the client. Not the tools. I looked at the delivery chain and admitted the weak link was the way marketing work entered the system: loose briefs, inconsistent naming, guessed tracking, and build teams forced to infer intent.

A rushed intake becomes an unclear brief. An unclear brief becomes a bad asset name. A bad asset name becomes a broken report. Then the developer gets blamed for a system that was already unstable.

So I attacked the system from inside. Every failure point becomes a question, a dropdown, a required decision, a generated name, a tracking link, a DAM destination URL, a build prompt, a QA gate, or an evidence trail.

The idea is simple: remove the places where campaign delivery fails before the campaign reaches production, and protect the people who have been carrying the failure manually.

Solution architecture

A governed orchestration layer between intake and delivery.

Campaign Copilot captures the marketer's campaign requirements, creates the SFDC campaign, generates Clarevine tracking, reserves DAM image destination URLs, packages the design and build instructions, and opens the Workfront ticket. The separate VS Code / GitHub / Eloqua build pipeline still handles Eloqua asset creation, testing, and approval.

Campaign Copilot solution architecture showing governed intake, Salesforce, Clarevine, DAM, Workfront, design agency handoff, and the separate VS Code GitHub Eloqua build pipeline
Campaign Copilot acts as the governed intake and orchestration layer. It prepares the campaign package and build prompt, while Eloqua asset creation remains inside the existing VS Code, GitHub, and Eloqua delivery workflow.

Build milestones

Product maturity checkpoints.

01 Achieved

Campaign Intake Structure

The intake flow turns fragmented campaign requests into structured decisions.

02 Achieved

Asset Naming Logic

Naming rules now generate consistent downstream asset instructions.

03 Active

Playwright QA Path

The active path is browser-level verification of campaign build flows.

04 Next

In-Flight Change Control

The next layer controls revisions when campaign details move mid-build.

05 Future

Client-Specific Delivery Profiles

Future profiles will adapt intake, naming, and handoff rules per client.

The problem

Some campaign delivery environments are fragmented by design.

Requests arrive in pieces

Landing page needs, form type, copy, image direction, email selection, tracking, deadlines, and stakeholder notes arrive across calls, documents, chats, and agency briefs.

Naming conventions are fragile

Asset names depend on humans remembering the right structure. One missed market, campaign code, date, offer type, or channel value creates downstream confusion.

Creative and MA handoff split apart

The design agency needs clear image instructions and upload locations. The MA developer needs build instructions, template choices, tracking links, and final asset names.

Tracking is too manual

Links need Clarevine tracking appended consistently across email and landing page journeys. Manual append work creates avoidable mistakes close to launch.

What it does / system view

A guided intake layer that becomes a governed build package.

Campaign Copilot forces the campaign request into a governed path. The marketer logs in, selects naming convention values, chooses email templates, enters copy, subject line, sender details, image descriptions, landing page modules, landing page copy, the existing Eloqua form, and the desired vanity URL.

The system then sits between the marketer request, Salesforce, Clarevine, DAM, Workfront, the design agency, and the existing VS Code / GitHub / Eloqua build pipeline. It controls the order of operations and turns every selection into a downstream build artifact for human-reviewed delivery.

Guided dropdown intake

Client-specific dropdowns capture region, business unit, campaign type, product family, audience, language, channel, offer, form choice, landing page modules, and email selection.

Naming convention engine

Selected values create approved names for landing pages, emails, image folders, Workfront requests, DAM destinations, and the downstream Eloqua build package.

Content and module capture

The marketer supplies landing page copy, email copy, subject line, sender details, CTA, image direction, link destinations, and the desired vanity URL.

Agency and DAM handoff

DAM image destination URLs are created or reserved and included in the agency brief and build instructions so creative files land in the correct destination.

SFDC and Clarevine setup

The Salesforce campaign is created, the Campaign ID comes back, and Clarevine tracking links are generated with the campaign context.

Workfront and build prompt

The Workfront ticket carries the campaign documents, design brief, DAM URLs, and VS Code / GitHub Copilot prompt into the existing Eloqua build workflow.

01 Intake

Dropdown decisions

Structured questions replace open-ended briefing chaos.

02 Name

Asset names

All names are created under the agreed convention.

03 Campaign

SFDC ID

The Salesforce API creates the campaign and returns the Campaign ID.

04 Track

Clarevine links

Tracking links are generated with the campaign context.

05 Handoff

DAM and briefs

DAM URLs, creative instructions, and build details are packaged.

06 Build

Workfront prompt

The ticket carries the Copilot prompt into the existing build pipeline.

Design workflow

The design agency gets a complete creative request, not a vague brief.

Campaign Copilot captures the same instructions the marketer would normally send to the design agency, but forces them into a usable format before the request leaves the system.

Landing page design brief

The marketer chooses landing page modules from approved options, enters the vanity URL, title, meta description, page copy, CTA, and the image direction required for the selected layout.

Email design brief

The marketer selects which email templates are needed, enters subject line, sender details, copy, and link destinations, then provides image instructions for each email module instead of sending loose notes later.

Image instruction capture

Hero image, body image, thumbnail, banner, product visual, and social crop instructions are captured against the exact asset and module they belong to.

DAM upload destinations

The system creates or reserves DAM image destination URLs and gives the agency a clean upload map: which graphic goes where, under what name, and which email or landing page module will consume it.

Agency request package

On submit, the design agency receives one structured request containing asset names, template choices, image requirements, copy context, deadlines, and DAM upload links.

Build-ready destinations

The MA build can start with known image destinations because the DAM URLs are included in both the agency brief and the email and landing page build instructions.

Campaign process flow

Submission becomes a complete delivery package.

On submit, Campaign Copilot creates the SFDC campaign through the Salesforce API, receives the SFDC Campaign ID, creates Clarevine tracking links, creates or reserves DAM image destination URLs, attaches the design brief and campaign build details document to Workfront, assigns the ticket to the right delivery team, and generates the VS Code / GitHub Copilot prompt used by the existing build workflow.

Campaign process flow from governed marketer intake through Salesforce Campaign ID, Clarevine tracking, DAM destination URLs, Workfront ticketing, design brief, and build prompt generation
The flow shows the operational handoffs Campaign Copilot prepares before the existing human-reviewed build, test, and approval process continues.

How it works

The guided request becomes the build instruction.

1

Answer structured campaign questions

The marketer logs in and chooses controlled naming values instead of writing a vague brief. Required fields force decisions before the request can be submitted.

2

Capture content and build choices

The marketer chooses email templates, enters email copy, subject line, sender details, image descriptions, landing page modules, landing page copy, the existing Eloqua form, and the desired vanity URL.

3

Create the SFDC campaign

Campaign Copilot creates the campaign through the Salesforce API and receives the SFDC Campaign ID used by the downstream package.

4

Generate tracking and DAM destinations

The Clarevine API creates tracking links, and Campaign Copilot creates or reserves DAM image destination URLs for agency upload and MA build instructions.

5

Create the Workfront ticket

The system attaches the design brief and campaign build details document, includes the DAM URLs where needed, and assigns the ticket to the correct delivery team.

6

Generate the build prompt

Campaign Copilot creates the VS Code / GitHub Copilot prompt that feeds the established build workflow rather than bypassing it.

7

Review, build, test, approve

Eloqua asset creation remains in the separate VS Code / GitHub / Eloqua pipeline, with human review and the existing build, test, and approval process still in place.

Integration model

Campaign Copilot does not replace the stack. It controls it.

The value is not another disconnected AI tool. The value is a control layer that knows how the client already delivers campaigns and turns that messy process into a repeatable workflow.

Salesforce

Campaign creation

The Salesforce API creates the SFDC campaign and returns the Campaign ID for tracking, briefs, and build context.

DAM

Image destination URLs

The design agency receives the creative request with the exact created or reserved upload destinations for landing page and email graphics.

Clarevine

Tracking link generation

The API creates required tracking links using the campaign context before the build reaches the MA developer.

Workfront

Ticket and team routing

The ticket receives the design brief, build details document, and VS Code / GitHub Copilot prompt, then routes to the correct delivery team.

Governance boundary

Campaign Copilot prepares the work. It does not publish the campaign.

The control model is deliberately bounded. Campaign Copilot does not autonomously send emails, publish campaigns, or directly create Eloqua assets. Eloqua asset creation remains part of the separate VS Code / GitHub / Eloqua build pipeline, and human review stays inside the existing build, test, and approval process.

No autonomous sends

Campaign Copilot produces the governed package, not the final campaign send.

No direct Eloqua asset creation

The Eloqua build remains in the established developer-controlled pipeline.

Human review remains

Existing build, test, approval, and launch governance continue to apply.

AI and data boundary diagram showing Campaign Copilot as an intake and orchestration layer with human review and separate Eloqua build and approval controls
The AI/data boundary separates governed orchestration from production execution: Campaign Copilot prepares the package, while the existing human-reviewed build pipeline controls Eloqua assets, testing, approvals, publishing, and sends.

Evidence / Governance

The system removes the places where campaign delivery fails.

This is not AI content generation dressed up as automation. It is campaign operations surgery. Every repeatable decision becomes structured. Every naming rule becomes generated. Every handoff becomes a packet. Every link becomes tracked. Every build instruction enters the existing delivery workflow with review still intact.

Less interpretation

The MA developer receives a complete build prompt instead of a pile of partial notes.

Cleaner creative handoff

The agency gets the image brief and the correct DAM upload destinations at the same time.

Fewer tracking mistakes

Clarevine tracking is generated with the SFDC Campaign ID before the email build reaches QA.

More controlled automation

The build prompt can accelerate template work, but approval stays with the MA developer before the existing Eloqua pipeline creates assets.

Next evolution

Capabilities shown by this build.

Campaign operations

  • Client-specific intake design for fragmented delivery environments
  • Asset naming convention automation
  • Landing page module, existing form, email, and creative handoff orchestration

Integration thinking

  • SFDC campaign creation and Campaign ID capture
  • DAM image destination URLs for agency uploads
  • Clarevine tracking link generation with campaign context

Build workflow support

  • Workfront ticket creation and delivery team routing
  • Design brief and campaign build details attached to the ticket
  • VS Code / GitHub Copilot prompt generation for the existing Eloqua pipeline

Control model

  • AI-assisted, not blind autonomous delivery
  • No autonomous email sends, campaign publishing, or direct Eloqua asset creation
  • Evidence trail from request to reviewed build package

Want to remove the weak points from campaign delivery?

Campaign Copilot is designed for enterprise marketing teams that need cleaner intake, naming discipline, creative handoff, tracking control, and build prompt generation without surrendering human approval or bypassing the existing Eloqua pipeline.

View all systems