I designed a Salesforce-native system with three custom objects, three record-triggered Flows, and a Lightning Record Page that guides campaigns from briefing to launch. Phase 1 uses Flows for automation. Phase 2 will integrate Agentforce agents for intelligent assignment and QA validation.
The PoC is built on principles that prioritize operational clarity, audit trails, and human control. These principles guide all decisions from data model to UX to automation.
Everything lives in Salesforce. One data model (Campaign Intake), one record page, one status flow. No Excel tracking, no external systems, no data sync headaches. Enables audit trails and compliance.
Every campaign has a clear status (Submitted, Not Ready, Ready for Assignment, Assigned – In Build, In QA, Ready to Launch, Launched) with entry/exit criteria visible to users. Path component shows progress. No hidden states.
Flows automate intake validation, assignment, and SLA tracking. Users see what the system did in the activity timeline. Phase 2 will add Agentforce agents for smarter decisions, but always with transparent reasoning shown to humans.
One Campaign Intake object. Different list views, Kanban boards, and dashboards for different roles (Ops lead sees SLA risk, builders see assignments, BU sees tracker). Same underlying data, different perspectives.
Master-detail relationships for QA Items, record-triggered Flows log changes, activity timeline captures human and system actions. Compliance ready from day one. No need to retrofit audit trails later.
The PoC is built on three tightly integrated custom objects. This design decouples the briefing system from the user directory, supports lifecycle tracking, and enables audit trails for compliance.
| Object | Fields | Purpose |
|---|---|---|
| Campaign Intake | 26 fields: Name (auto-number CI-00001), Status, Path Stage, Campaign Type, Channels (multi-select), Launch Date, Budget, BU Owner, Builder Lookup, Rerun Change Type, Complexity Score, SLA Days, SLA Expires At, Created/Last Updated By/DateTime, Parent Campaign (if rerun), and read-only system fields (Assigned Builder, QA Status, Total QA Items Completed) | Single record per campaign. BU-facing intake form + system-owned lifecycle tracking. Master object for campaign workflow. |
| Campaign Builder | 4 fields: Builder Name (User lookup), Builder Type (picklist: Content / Journey), Active (checkbox), On Leave (checkbox) | Decouples builder directory from user records. Supports availability tracking for auto-assignment. Separate table allows admins to manage capacity independently of user records. |
| Campaign QA Item | 6 fields: Campaign Intake (master-detail), QA Stage (picklist), Result (picklist: Pass / Fail / Review), Comments (textarea), Completed By (User), Completed DateTime | Child records of Campaign Intake. Audit trail for QA process. Cascade delete ensures clean data. Roll-up summaries possible (total items completed, last result). |
| Campaign Work Stage | Designed but optional: Master-detail to Campaign Intake, Work Stage (picklist: In Progress / Blocked / Complete), Builder Assigned, Started Date, Expected Completion Date, Notes | Future execution tracking. Enables detailed progress granularity. Deferred from Phase 1 PoC but ready for Phase 2 if work is sub-divided by team. |
The Status field on Campaign Intake drives the entire workflow. Each status represents a distinct phase with clear entry/exit criteria:
The Record Page displays a Path component showing the campaign's journey through 4 execution stages:
The Path is driven by the Status field and provides visual clarity. Users see which stage they're on and what's needed to progress. This is distinct from the 8-status lifecycle and serves as a progress tracker for stakeholders.
The core interface is a single Lightning Record Page for Campaign Intake with Dynamic Forms, conditional visibility, and a Path component. This keeps complexity low and adoption high—users work within Salesforce's familiar UX.
Beyond the record page, users navigate campaigns via:
The PoC uses 3 record-triggered Flows to orchestrate the entire lifecycle. Flows were chosen over Apex for maintainability — admins can modify business logic without code deployment. Phase 1 is built entirely with Flows. Phase 2 may explore Agentforce agents for more complex decision-making if needed.
| Flow Name | Type | Trigger | What It Does |
|---|---|---|---|
| 1. Briefing – Calculate Readiness and SLA | Record-Triggered, Before Save | Fires on Campaign Intake save when Stage = 1 – Briefing | Validates BU fields (Campaign Type, Channels, Consent Type, Data Ready). Sets Briefing_Ready = true/false. Calculates Complexity Level (Low/Medium/High). Derives SLA Days (2-7). Sets SLA Start DateTime, SLA Target DateTime. |
| 2. SLA Pause/Resume | Record-Triggered | Fires when Status changes to/from "Not Ready – BU Action Required" | Pauses: sets SLA_Paused = true, records SLA_Pause_Start. Resumes: calculates paused minutes, extends SLA Target proportionally, clears pause fields. |
| 3. Initial Assignment Routing | Record-Triggered | Fires when Briefing_Ready becomes true and Initial_Assignment_Done = false | Queries Campaign Builder records for eligible builders (Active = true, On Leave = false). Selects builder with lowest complexity-weighted in-flight workload. Updates Assigned Journey Builder / Content Builder. Sets Status = "Assigned – In Build". |
The flows form a pipeline:
The Ops lead's daily question: "What's at risk? Who needs support? What's the team's utilization?" This dashboard shows:
The BU's daily question: "Where's my campaign? What do I need to do next?" Card-based view showing:
Content builder's daily question: "What's assigned to me? What's blocking?" Kanban board with swimlanes:
The QA checklist is standardized and lives in Salesforce (not Excel). Phase 2 could add an Agentforce QA Agent to assist reviewers:
Executive's daily question: "How efficient is this process? Is the system working?" Key metrics:
Phase 1 PoC is designed with Flows. Phase 2 will migrate key Flows to Agentforce agents. This phased approach lets the team prove value with no-code before investing in AI agent tuning.
These Flows are best-suited for Agentforce replacement (higher complexity, recommendation logic):
In Phase 2, Flows become orchestration shells; Agentforce agents become the decision engines. Humans still override and approve all recommendations—AI surfaces intelligence, humans make final calls.
When Agentforce agents are deployed in Phase 2, they will integrate into Salesforce as inline recommendations, notifications, and action panels. The pattern is always: show the recommendation, show the reasoning, allow override.
Every campaign has an activity timeline visible on the record. Agentforce actions are logged alongside human actions:
Agentforce sends notifications via Salesforce standard channels (in-app + email digest option):
Every campaign gets a complexity score that determines its SLA (Service Level Agreement). This is transparent and shown at briefing so BU knows their campaign's priority.
| Factor | Options | Weight |
|---|---|---|
| Campaign Type | New Campaign = 3 | Rerun = 1 | Modification = 2 | Base weight |
| Channel Count | 1 channel = ×1 | 2 channels = ×1.5 | 3+ channels = ×2 | Multiplier |
| Change Types | Content only = ×1 | Content + Logic = ×1.5 | Content + Logic + Audience = ×2 | Multiplier |
| Final Score | Type Weight × Channel Multiplier × Change Multiplier | |
| Complexity Score Range | SLA Days | Example |
|---|---|---|
| 1–3 | 3 days | Rerun, 1 channel, content only (1 × 1 × 1 = 1) |
| 4–6 | 5 days | New campaign, 2 channels, content + logic (3 × 1.5 × 1 = 4.5) |
| 7–9 | 8 days | New campaign, 3 channels, content + logic (3 × 2 × 1.5 = 9) |
| 10+ | 12 days | New campaign, 3 channels, content + logic + audience (3 × 2 × 2 = 12) |
Transparency: The Briefing Flow calculates this score automatically when a campaign is submitted and displays it on the campaign record. BU sees "Your campaign has a complexity score of 6 (5-day SLA). Expected completion: Feb 22." No surprises.
Chose: Auto Number instead of natural campaign names. Why: Human-readable (easy to reference in Outlook, email, tasks), guaranteed unique, works well in notifications and subject lines. Trade-off: Less friendly than "Email Nurture Q1", but operationally essential for identification and task tracking. Users see the auto number + campaign name together in lists.
Chose: Multi-select over individual checkboxes. Why: Explicit selection (user must pick channels; no defaults), compact UI, allows counting for complexity scoring (1 channel = ×1, 2 = ×1.5, 3+ = ×2). A derived field "Is Multi-Channel" = CHANNELS count > 1, used for routing and metrics.
Chose: Separate Campaign Builder object (not using User records). Why: Decouples builder directory from Salesforce user management, supports Active/On Leave tracking for auto-assignment, allows multiple builders per person (content + journey), and avoids modifying user records. Admins manage builder capacity independently.
Chose: Master-detail (not Lookup) for Campaign QA Item → Campaign Intake. Why: Cascade delete ensures clean data when campaign deleted, enables roll-up summaries (total QA items, completion count), provides strong audit trail, and prevents orphaned QA records. Trade-off: Tighter coupling, but appropriate for a child checklist model.
Chose: Flows for all automation (Intake Validator, Auto Assign, SLA Pause/Resume, etc.). Why: No-code, maintainable by admins without deployment, version-controlled, appropriate complexity for PoC. Trade-off: Flows have limits (slower at massive scale, harder to debug complex logic), but Phase 1 doesn't need Apex. Phase 2 can move to Agentforce agents or Apex if needed.
Chose: Validation rules for conditional enforcement (e.g., "Rerun Change Type required only if Campaign Type = Rerun"). Why: Dynamic Forms + validation rules give flexibility. Required fields are static; validation rules adapt to status/type. Conditional visibility + validation rules together create a guided experience without hard blocks.
| Artefact | What It Defines |
|---|---|
| Three Custom Objects | Campaign Intake (26 fields: briefing + lifecycle), Campaign Builder (4 fields: directory + capacity), Campaign QA Item (6 fields: child checklist). Schema built for audit, assignment, and QA workflow. |
| Eight Status Lifecycle | Submitted → Not Ready – BU Action Required → Ready for Assignment → Assigned – In Build → In QA → Ready to Launch → Launched. Clear state machine with entry/exit criteria. |
| Four-Stage Path Component | Briefing → Build → QA → Activated. Visual tracker for stakeholders showing progress through execution phases. |
| Lightning Record Page Architecture | Dynamic Forms with conditional visibility, Path component, "BU Request" user-facing section, "System (Read-only)" ops section. Single source of truth for campaigns. |
| Three Record-Triggered Flows | 1. Briefing – Calculate Readiness and SLA (validates BU fields, sets Briefing_Ready, calculates Complexity Level, derives SLA Days). 2. SLA Pause/Resume (pauses/resumes SLA countdown based on Status changes). 3. Initial Assignment Routing (selects builder with lowest complexity-weighted workload, sets Status to "Assigned – In Build"). Orchestrates entire lifecycle. |
| List Views & Kanban Board | Status-based Kanban, Ops SLA View (at-risk), My Content Builds, My Journey Builds. Role-based access patterns built into list views. |
| Phase 1 → Phase 2 Roadmap | Phase 1: Flows drive automation. Phase 2: Agentforce agents replace key Flows (assignment, QA intelligence, SLA optimization). Humans always in control. |
| Six Design Decisions | Auto Number naming, multi-select channels, separate builder object, master-detail QA, Flows over Apex, validation rules over required fields. Each choice justified for PoC context. |